CVE-2026-32322

Security Advisory: Incorrect Equality for Fr Scalar Field Types (BN254, BLS12-381)

Missing modular reduction in Fr causes incorrect equality comparisons for BN254 and BLS12-381 types in soroban-sdk.

Details

Fr types for both curves are wrappers around U256. The PartialEq implementation compared the raw U256 values directly. However, the constructors (from_u256, from_bytes, From<U256>) accepted arbitrary U256 values without reducing them modulo r. This meant two Fr values representing the same field element (e.g., 1 and r + 1) could have different internal representations and compare as not-equal.

This issue was compounded by an asymmetry: all host-side arithmetic operations (fr_add, fr_sub, fr_mul, fr_pow, fr_inv) always return canonically reduced results in [0, r), while user-constructed Fr values could hold unreduced representations. Comparing a user-supplied Fr against a host-computed Fr would therefore produce incorrect results even when the underlying field elements were identical.

Example

let r = /* BN254 scalar field modulus */;
let a = Fr::from_u256(r + 1); // unreduced, stores r+1
let b = Fr::from_u256(1);     // reduced, stores 1

// a and b represent the same field element (1), but compared as NOT equal
assert_eq!(a, b); // FAILED before the fix

Workarounds

If upgrading is not immediately possible:

• Manually reduce the underlying U256 via rem_euclid by the field modulus r before constructing Fr, or round-trip through host Fr arithmetic (e.g., fr_add(val, zero)) which always returns reduced results. Note: BN254 does not expose dedicated Fr host functions, so rem_euclid is the only option there.

Recommendations

• Upgrade to the patched version of soroban-sdk.
• Review any deployed contracts that accept Fr values as input, and compare those values using ==, !=, or assert_eq!. These contracts may be vulnerable if an attacker can supply unreduced scalar values to bypass equality checks.

The Fr (scalar field) types for BN254 and BLS12-381 in soroban-sdk compared values using their raw U256 representation without first reducing modulo the field modulus r. This caused mathematically equal field elements to compare as not-equal when one or both values were unreduced (i.e., >= r).

The vulnerability requires an attacker to supply crafted Fr values through contract inputs, and compare them directly without going through host-side arithmetic operations.

Smart contracts that rely on Fr equality checks for security-critical logic could produce incorrect results. The impact depends on how the affected contract uses Fr equality comparisons, but can result in incorrect authorization decisions or validation bypasses in contracts that perform equality checks on user-supplied scalar values.

CVE-2026-32322 has a CVSS score of 5.3 (Medium). 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 (25.3.0, 23.5.3, 22.0.11); upgrading removes the vulnerable code path.

Kodem intelligence

All Fr construction paths now reduce the input modulo r, ensuring a canonical representation in [0, r). This guarantees that equal field elements always have identical internal representations, making the existing PartialEq comparison correct.

Additionally, Fp and Fp2 base field types for both curves now validate that values are strictly less than the field modulus on construction, rejecting out-of-range inputs.

1. What is CVE-2026-32322? CVE-2026-32322 is a medium-severity security vulnerability in soroban-sdk (rust), affecting versions >= 25.0.0, < 25.3.0. It is fixed in 25.3.0, 23.5.3, 22.0.11.
2. How severe is CVE-2026-32322? CVE-2026-32322 has a CVSS score of 5.3 (Medium). 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 soroban-sdk are affected by CVE-2026-32322? soroban-sdk (rust) versions >= 25.0.0, < 25.3.0 is affected.
4. Is there a fix for CVE-2026-32322? Yes. CVE-2026-32322 is fixed in 25.3.0, 23.5.3, 22.0.11. Upgrade to this version or later.
5. Is CVE-2026-32322 exploitable, and should I be worried? Whether CVE-2026-32322 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 CVE-2026-32322 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 CVE-2026-32322?
   • Upgrade soroban-sdk to 25.3.0 or later
   • Upgrade soroban-sdk to 23.5.3 or later
   • Upgrade soroban-sdk to 22.0.11 or later