CVE-2026-32322: 
Rust vulnerability analysis and mitigation

CVE-2026-32322 is a scalar field equality comparison flaw in the soroban-sdk Rust library for Soroban smart contracts on the Stellar blockchain. The Fr (scalar field) types for BN254 and BLS12-381 curves compared values using their raw U256 representation without first reducing modulo the field modulus r, causing mathematically equal field elements to compare as unequal when one or both values were unreduced. Affected versions include all releases before 22.0.11, versions 23.0.0 to before 23.5.3, and versions 25.0.0 to before 25.3.0. It carries a CVSS v3.1 base score of 5.3 (Medium) (Github Advisory, Stellar Advisory). The advisory was published on March 12, 2026, and assigned CVE-2026-32322 on March 13, 2026.

The root cause is classified as CWE-697 (Incorrect Comparison). The Fr types for BN254 and BLS12-381 are wrappers around U256, and their PartialEq implementation compared raw U256 values directly. Constructors (from_u256, from_bytes, From) accepted arbitrary U256 values without reducing them modulo r, meaning two Fr values representing the same field element (e.g., 1 and r + 1) could have different internal representations and compare as not-equal. The flaw is compounded by an asymmetry: 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 — so comparing a user-supplied Fr against a host-computed Fr would produce incorrect results even when the underlying field elements were identical (Github Advisory, Stellar Advisory).

Smart contracts that rely on Fr equality checks for security-critical logic could produce incorrect results, potentially leading to incorrect authorization decisions or validation bypasses when an attacker supplies crafted unreduced scalar values as contract inputs. The integrity impact is limited to the logic of affected smart contracts — there is no confidentiality or availability impact. The scope of affected assets is restricted to Soroban smart contracts that accept user-supplied Fr values and compare them directly using ==, !=, or assert_eq! without routing through host-side arithmetic (Github Advisory).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at this time (Feedly). Exploitation requires an attacker to supply crafted Fr values (with unreduced representations, i.e., values >= r) through contract inputs and have those values compared directly without passing through host-side arithmetic. The EPSS score is approximately 0.017% (4th percentile), indicating a very low probability of exploitation in the near term. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog.

1. Identify a vulnerable contract: Locate a deployed Soroban smart contract built with a vulnerable version of soroban-sdk (< 22.0.11, 23.0.0–23.5.2, or 25.0.0–25.2.x) that accepts user-supplied Fr scalar values and performs equality comparisons on them for authorization or validation logic.
2. Determine the field modulus: Identify the scalar field modulus r for the relevant curve (BN254 or BLS12-381). These are well-known public constants.
3. Craft an unreduced Fr value: Construct an Fr input value that is mathematically equivalent to the expected value but represented in unreduced form — for example, supply r + expected_value instead of expected_value.
4. Submit the crafted input: Call the vulnerable contract function with the crafted unreduced Fr value as input. If the contract compares this user-supplied value against a host-computed (canonically reduced) Fr, the comparison will incorrectly return false even though the field elements are equal.
5. Bypass security logic: Depending on the contract's logic, this incorrect comparison result can be used to bypass authorization checks, circumvent validation gates, or manipulate contract state in unintended ways (Stellar Advisory).

Upgrade soroban-sdk to the patched versions: 22.0.11 (for versions below 22.0.11), 23.5.3 (for 23.x versions), or 25.3.0 (for 25.x versions). The fix ensures all Fr construction paths reduce the input modulo r, enforcing canonical representation in [0, r). Additionally, Fp and Fp2 base field types now validate that values are strictly less than the field modulus on construction. If immediate upgrade is not possible, manually reduce U256 values 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 that BN254 does not expose dedicated Fr host functions, so rem_euclid is the only workaround for that curve. Developers should also review any deployed contracts that accept Fr values as input and perform equality comparisons (Github Advisory, Stellar Advisory).

The advisory was authored and published by leighmcculloch, a credited finder and Stellar contributor, on March 12, 2026. The vulnerability received standard automated coverage across CVE tracking platforms and security feeds shortly after disclosure, with no notable broader media coverage or significant community debate identified (Github Advisory).