# GHSA-fj2x-735w-74vq: gnark-crypto allows unchecked memory allocation during vector deserialization

> Attackers can cause denial of service in applications using gnark-crypto by sending malicious data that triggers excessive memory allocation during deserialization.

- **Severity:** Not scored
- **Exploited in the wild:** Not known
- **Login needed:** Not needed
- **Attackable:** Over the internet
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 30 Oct 2025
- **Also known as:** GO-2025-4087

## What is GHSA-fj2x-735w-74vq?

GHSA-fj2x-735w-74vq is a denial of service vulnerability in github.com/consensys/gnark-crypto, published on 30 Oct 2025. An attacker can exploit it over the internet without logging in, with no action from the victim.

### Official description

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.

## Which versions are affected by GHSA-fj2x-735w-74vq?

5 open source packages ship an affected version, including github.com/consensys/gnark-crypto.


| Package | Ecosystem | Affected | Fixed in |
| --- | --- | --- | --- |
| `github.com/consensys/gnark-crypto` | Go | From 0.19.0 | 0.19.2 |
| `github.com/consensys/gnark-crypto` | Go | From 0.19.0 | 0.19.2 |
| `github.com/consensys/gnark-crypto` | Go | From 0.9.1 | 0.18.1, 0.19.2 |
| `github.com/consensys/gnark-crypto` | Go | From 0.9.1 | 0.18.1 |
| `github.com/consensys/gnark-crypto` | Go | From 0.9.1 | 0.18.1 |

## How do I fix GHSA-fj2x-735w-74vq?

Upgrade github.com/consensys/gnark-crypto to a fixed version for your release line: 0.19.2 or 0.18.1.

## Is GHSA-fj2x-735w-74vq being exploited?

There is no known exploitation of GHSA-fj2x-735w-74vq in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for GHSA-fj2x-735w-74vq and fix it if it is affected.

What it is: GHSA-fj2x-735w-74vq is a denial of service vulnerability in github.com/consensys/gnark-crypto, published on 30 Oct 2025. An attacker can exploit it over the internet without logging in, with no action from the victim.
Exploitation: There is no known exploitation of GHSA-fj2x-735w-74vq in the wild and no public exploit code.

Affected packages and fixed versions:
- github.com/consensys/gnark-crypto (Go): affected from 0.19.0; fixed in 0.19.2
- github.com/consensys/gnark-crypto (Go): affected from 0.19.0; fixed in 0.19.2
- github.com/consensys/gnark-crypto (Go): affected from 0.9.1; fixed in 0.18.1, 0.19.2
- github.com/consensys/gnark-crypto (Go): affected from 0.9.1; fixed in 0.18.1
- github.com/consensys/gnark-crypto (Go): affected from 0.9.1; fixed in 0.18.1

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/GHSA-fj2x-735w-74vq/ (Markdown: https://insights.sbomify.com/GHSA-fj2x-735w-74vq/index.md)
```

## Sources

- OSV: https://osv.dev/vulnerability/GHSA-fj2x-735w-74vq

---
From sbomify Insights: https://insights.sbomify.com/GHSA-fj2x-735w-74vq/
Summaries are generated and may contain mistakes; the official description above is the record.