GHSA-fj2x-735w-74vq: Github.com/consensys/gnark crypto Gnark-crypto Allows Unchecked Memory Allocation Vulnerability

HIGH
CVSS 7.5
CWE-400
Published
Advisory Summary

GHSA-fj2x-735w-74vq is a HIGH (CVSS 7.5) gnark-crypto allows unchecked memory allocation vulnerability (CWE-400: Uncontrolled Resource Consumption) affecting Github.com/consensys/gnark crypto libraries in the Go ecosystem. The issue involves gnark-crypto allows unchecked memory allocation during vector deserialization. Remediation is available by upgrading affected packages to version 0.18.1, 0.19.2.

GHSA-fj2x-735w-74vq at a Glance

CVE Identifier N/A
GHSA Identifier GHSA-fj2x-735w-74vq
Severity HIGH
CVSS v3.1 Base Score 7.5
CWE Classification CWE-400: Uncontrolled Resource Consumption
Affected Product Github.com/consensys/gnark crypto
Package Ecosystem Go
Published Date
Last Updated

Security Impact

CVSS: 7.5

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H).

Attack Vector Network (AV:N)
Attack Complexity Low (AC:L)
Privileges Required None (PR:N)
User Interaction None (UI:N)
Scope Unchanged (S:U)
Confidentiality None (C:N)
Integrity None (I:N)
Availability High (A:H)

How to Fix GHSA-fj2x-735w-74vq

To remediate this vulnerability, upgrade all affected Github.com/consensys/gnark crypto dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

github.com/consensys/gnark-crypto fixed: 0.18.1
Upgrade github.com/consensys/gnark-crypto to 0.18.1
github.com/consensys/gnark-crypto fixed: 0.19.2
Upgrade github.com/consensys/gnark-crypto to 0.19.2
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

inspect dependencies for github.com/consensys/gnark-crypto

How to Check if You Are Affected

To determine whether your application is affected by GHSA-fj2x-735w-74vq, inspect your project dependencies for Github.com/consensys/gnark crypto:

inspect dependencies for github.com/consensys/gnark-crypto

Analyze the terminal output to locate any version of Github.com/consensys/gnark crypto in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 0.18.1), your application is affected.

Note: Verify declared build manifests and deployed runtime container environments.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-400: Uncontrolled Resource Consumption, where the product does not properly control the allocation and maintenance of a limited resource. In Github.com/consensys/gnark crypto, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

The issue has been reported by @raefko from @fuzzinglabs. Excerpts from the report: > A critical vulnerability exists in the gnark-crypto library's `Vector.ReadFrom()` function that allows an attacker to trigger arbitrary memory allocation by crafting malicious input data. An attacker can cause the verifier to attempt allocating up to 128 GB of memory with a minimal malicious input, leading to out-of-memory crashes and denial of service. > ### **Root Cause** > > > The vulnerability stems from **unchecked deserialization** of attacker-controlled length fields in the gnark-crypto library's `Vector.ReadFrom()` function. The function reads a 4-byte unsigned integer from untrusted input and directly uses it to allocate memory without any validation or bounds checking. > > ### **Vulnerable Code Path** > > ``` > User Input (Malicious Proof/Data) > ↓ > gnark Proof/Data Deserialization > ↓ > Vector.ReadFrom() (ecc/bn254/fr/vector.go:136-144) > → sliceLen := binary.BigEndian.Uint32(buf[:4]) // ← ATTACKER-CONTROLLED > → (*vector) = make(Vector, sliceLen) // ← UNCHECKED ALLOCATION > ↓ > runtime.makeslice attempts 100+ GB allocation > ↓ > fatal error: runtime: out of memory → SIGABRT > > ``` > > ### **Vulnerable Code** > > **File**: [`gnark-crypto@v0.14.0+/ecc/bn254/fr/vector.go:136-144`](https://github.com/Consensys/gnark-crypto/blob/8310aae2de6104d3fe3610e3370b2bed10c63111/ecc/bn254/fr/vector.go#L136) > > The code reads a 4-byte big-endian unsigned integer (`sliceLen`) directly from the input stream and uses it to allocate a slice without any bounds checking or validation. Each element is 32 bytes (fr.Element for BN254 curve), so an attacker can request up to: > > **Maximum Allocation**: `2^32 elements × 32 bytes = 137,438,953,472 bytes ≈ 128 GB` > > ## **Root Cause Analysis** > > The gnark-crypto library implements a generic serialization format for field element vectors. The format is: > > ``` > [4 bytes: length (n)] [n × 32 bytes: elements] > ``` > > The deserialization code **trusts** the length field implicitly without any validation. This is a classic **integer-to-allocation vulnerability** pattern, similar to issues that have affected many serialization libraries over the years. ### Impact The issue impacts users deserializing vectors directly from untrusted sources. In case of malicious input it would lead to OOM in case the server doesn't have sufficient memory (depending on the field, but could allocate from 32GB to 196GB). ### Patches The issue is patched in https://github.com/Consensys/gnark-crypto/pull/759. It will be backported to gnark-crypto v0.18 and v0.19. ### Workarounds The user could manually peek into the first 4 bytes of the serialized data to estimate if the header would allocate large amounts of memory.

GHSA-fj2x-735w-74vq Affected Github.com/consensys/gnark crypto Versions

2 component(s)
Fixed Versions:
0.18.10.19.2
Product / Package Ecosystem Affected Versions Fixed Version
github.com/consensys/gnark-crypto
Go
≥ 0.9.1
< 0.18.1
0.18.1
github.com/consensys/gnark-crypto
Go
≥ 0.19.0
< 0.19.2
All 1 versions
0.19.0
0.19.2

References

Frequently Asked Questions

What is GHSA-fj2x-735w-74vq?
GHSA-fj2x-735w-74vq is a security vulnerability in Github.com/consensys/gnark crypto involving gnark-crypto allows unchecked memory allocation during vector deserialization under CWE-400: Uncontrolled Resource Consumption.
Which Github.com/consensys/gnark crypto versions are affected?
Affected versions include releases prior to 0.18.1, 0.19.2 across affected packages: github.com/consensys/gnark-crypto.
What version fixes GHSA-fj2x-735w-74vq?
Upgrading to 0.18.1, 0.19.2 (or the latest patched release for your respective branch) resolves the vulnerability.
Is github.com/consensys/gnark-crypto affected?
Yes, github.com/consensys/gnark-crypto is affected in releases prior to 0.18.1, 0.19.2. Upgrade your dependency to 0.18.1, 0.19.2 or later.
What is the CVSS score of GHSA-fj2x-735w-74vq?
GHSA-fj2x-735w-74vq has a CVSS v3.1 base score of 7.5 (HIGH) with vector string CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H.
What CWE is associated with GHSA-fj2x-735w-74vq?
GHSA-fj2x-735w-74vq is classified under CWE-400: Uncontrolled Resource Consumption (The product does not properly control the allocation and maintenance of a limited resource.).
How can I check Go dependencies for GHSA-fj2x-735w-74vq?
Run the dependency tree command: 'inspect dependencies for github.com/consensys/gnark-crypto'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-fj2x-735w-74vq",
  "modified" : "2025-11-05T22:15:15Z",
  "published" : "2025-10-30T17:10:40Z",
  "aliases" : [ ],
  "summary" : "gnark-crypto allows unchecked memory allocation during vector deserialization",
  "details" : "The issue has been reported by @raefko from @fuzzinglabs. Excerpts from the report:\n> A critical vulnerability exists in the gnark-crypto library's `Vector.ReadFrom()` function that allows an attacker to trigger arbitrary memory allocation by crafting malicious input data. An attacker can cause the verifier to attempt allocating up to 128 GB of memory with a minimal malicious input, leading to out-of-memory crashes and denial of service.\n> ### **Root Cause**\n> \n> \n> The vulnerability stems from **unchecked deserialization** of attacker-controlled length fields in the gnark-crypto library's `Vector.ReadFrom()` function. The function reads a 4-byte unsigned integer from untrusted input and directly uses it to allocate memory without any validation or bounds checking.\n> \n> ### **Vulnerable Code Path**\n> \n> ```\n> User Input (Malicious Proof/Data)\n>          ↓\n> gnark Proof/Data Deserialization\n>          ↓\n> Vector.ReadFrom() (ecc/bn254/fr/vector.go:136-144)\n>   → sliceLen := binary.BigEndian.Uint32(buf[:4])   // ← ATTACKER-CONTROLLED\n>   → (*vector) = make(Vector, sliceLen)             // ← UNCHECKED ALLOCATION\n>          ↓\n> runtime.makeslice attempts 100+ GB allocation\n>          ↓\n> fatal error: runtime: out of memory → SIGABRT\n> \n> ```\n>\n> ### **Vulnerable Code**\n> \n> **File**: [`gnark-crypto@v0.14.0+/ecc/bn254/fr/vector.go:136-144`](https://github.com/Consensys/gnark-crypto/blob/8310aae2de6104d3fe3610e3370b2bed10c63111/ecc/bn254/fr/vector.go#L136)\n> \n> The code reads a 4-byte big-endian unsigned integer (`sliceLen`) directly from the input stream and uses it to allocate a slice without any bounds checking or validation. Each element is 32 bytes (fr.Element for BN254 curve), so an attacker can request up to:\n> \n> **Maximum Allocation**: `2^32 elements × 32 bytes = 137,438,953,472 bytes ≈ 128 GB`\n> \n> ## **Root Cause Analysis**\n> \n> The gnark-crypto library implements a generic serialization format for field element vectors. The format is:\n> \n> ```\n> [4 bytes: length (n)] [n × 32 bytes: elements]\n> ```\n> \n> The deserialization code **trusts** the length field implicitly without any validation. This is a classic **integer-to-allocation vulnerability** pattern, similar to issues that have affected many serialization libraries over the years.\n\n### Impact\n\nThe issue impacts users deserializing vectors directly from untrusted sources. In case of malicious input it would lead to OOM in case the server doesn't have sufficient memory (depending on the field, but could allocate from 32GB to 196GB).\n\n### Patches\n\nThe issue is patched in https://github.com/Consensys/gnark-crypto/pull/759. It will be backported to gnark-crypto v0.18 and v0.19.\n\n### Workarounds\n\nThe user could manually peek into the first 4 bytes of the serialized data to estimate if the header would allocate large amounts of memory.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "Go",
      "name" : "github.com/consensys/gnark-crypto"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0.9.1"
      }, {
        "fixed" : "0.18.1"
      } ]
    } ]
  }, {
    "package" : {
      "ecosystem" : "Go",
      "name" : "github.com/consensys/gnark-crypto"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0.19.0"
      }, {
        "fixed" : "0.19.2"
      } ]
    } ],
    "versions" : [ "0.19.0" ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/Consensys/gnark-crypto/security/advisories/GHSA-fj2x-735w-74vq"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/Consensys/gnark-crypto/pull/759"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/Consensys/gnark-crypto/commit/2e7bf9190a0aac896eeec3876c87c77a35661be7"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/Consensys/gnark-crypto"
  }, {
    "type" : "WEB",
    "url" : "https://pkg.go.dev/vuln/GO-2025-4087"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-400" ],
    "severity" : "HIGH",
    "github_reviewed" : true,
    "github_reviewed_at" : "2025-10-30T17:10:40Z",
    "nvd_published_at" : null
  }
}