fix(deps): update module github.com/consensys/gnark-crypto to v0.18.1 [security]

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
github.com/consensys/gnark-crypto	v0.18.0 → v0.18.1

---

Warning

Some dependencies could not be looked up. Check the Dependency Dashboard for more information.

GitHub Vulnerability Alerts

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: gnark-crypto@v0.14.0+/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.

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.

---

gnark-crypto allows unchecked memory allocation during vector deserialization

GHSA-fj2x-735w-74vq / GO-2025-4087

More information

Details

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

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.

Severity

• CVSS Score: 7.5 / 10 (High)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

• https://github.com/Consensys/gnark-crypto/security/advisories/GHSA-fj2x-735w-74vq
• https://github.com/Consensys/gnark-crypto/pull/759
• https://github.com/Consensys/gnark-crypto/commit/2e7bf9190a0aac896eeec3876c87c77a35661be7
• https://github.com/Consensys/gnark-crypto
• https://pkg.go.dev/vuln/GO-2025-4087

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

---

Unchecked memory allocation during vector deserialization in github.com/consensys/gnark-crypto

GHSA-fj2x-735w-74vq / GO-2025-4087

More information

Details

Unchecked memory allocation during vector deserialization in github.com/consensys/gnark-crypto

Severity

Unknown

References

• https://github.com/Consensys/gnark-crypto/security/advisories/GHSA-fj2x-735w-74vq
• https://github.com/Consensys/gnark-crypto/commit/2e7bf9190a0aac896eeec3876c87c77a35661be7
• https://github.com/Consensys/gnark-crypto/pull/759

This data is provided by OSV and the Go Vulnerability Database (CC-BY 4.0).

---

Release Notes

consensys/gnark-crypto (github.com/consensys/gnark-crypto)

v0.18.1

Compare Source

Docs

• add CHANGELOG for 0.18.1

Perf

• limit memory allocation during Vector deserialization (#​759)

---

Configuration

📅 Schedule: Branch creation - "" (UTC), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[renovate]

ℹ Artifact update notice

File name: go.mod

In order to perform the update(s) described in the table above, Renovate ran the go get command, which resulted in the following additional change(s):

• 1 additional dependency was updated

Details:

Package	Change
github.com/consensys/bavard	v0.1.27 -> v0.1.31-0.20250406004941-2db259e4b582

[renovate]

Renovate Ignore Notification

Because you closed this PR without merging, Renovate will ignore this update (v0.18.1). You will get a PR once a newer version is released. To ignore this dependency forever, add it to the ignoreDeps array of your Renovate config.

If you accidentally closed this PR, or if you changed your mind: rename this PR to get a fresh replacement PR.