GHSA-FJ2X-735W-74VQ

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: [email protected]+/ecc/bn254/fr/vector.go:136-144

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.

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.

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).

Crafted input forces the application to consume excessive CPU, memory, or other resources, degrading or denying service. Typical impact: denial of service.

GHSA-FJ2X-735W-74VQ has a CVSS score of 7.5 (High). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (0.18.1, 0.19.2); upgrading removes the vulnerable code path.

Kodem intelligence

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.

1. What is GHSA-FJ2X-735W-74VQ? GHSA-FJ2X-735W-74VQ is a high-severity uncontrolled resource consumption vulnerability in github.com/consensys/gnark-crypto (go), affecting versions >= 0.9.1, < 0.18.1. It is fixed in 0.18.1, 0.19.2. Crafted input forces the application to consume excessive CPU, memory, or other resources, degrading or denying service.
2. How severe is GHSA-FJ2X-735W-74VQ? GHSA-FJ2X-735W-74VQ has a CVSS score of 7.5 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of github.com/consensys/gnark-crypto are affected by GHSA-FJ2X-735W-74VQ? github.com/consensys/gnark-crypto (go) versions >= 0.9.1, < 0.18.1 is affected.
4. Is there a fix for GHSA-FJ2X-735W-74VQ? Yes. GHSA-FJ2X-735W-74VQ is fixed in 0.18.1, 0.19.2. Upgrade to this version or later.
5. Is GHSA-FJ2X-735W-74VQ exploitable, and should I be worried? Whether GHSA-FJ2X-735W-74VQ is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether GHSA-FJ2X-735W-74VQ is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix GHSA-FJ2X-735W-74VQ?
   • Upgrade github.com/consensys/gnark-crypto to 0.18.1 or later
   • Upgrade github.com/consensys/gnark-crypto to 0.19.2 or later