GHSA-fj2x-735w-74vq: Github.com/consensys/gnark crypto Gnark-crypto Allows Unchecked Memory Allocation Vulnerability
HIGHGHSA-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
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).
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.
Upgrade github.com/consensys/gnark-crypto to 0.18.1
Upgrade github.com/consensys/gnark-crypto to 0.19.2
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
GHSA-fj2x-735w-74vq Affected Github.com/consensys/gnark crypto Versions
2 component(s)| 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?
Which Github.com/consensys/gnark crypto versions are affected?
What version fixes GHSA-fj2x-735w-74vq?
Is github.com/consensys/gnark-crypto affected?
What is the CVSS score of GHSA-fj2x-735w-74vq?
What CWE is associated with GHSA-fj2x-735w-74vq?
How can I check Go dependencies for GHSA-fj2x-735w-74vq?
Machine-readable OSV JSON
OSV v1.5 Schema
{
"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
}
}