CVE-2026-32322
Improper Field Comparison in soroban-sdk Causes Authorization Bypass
Publication date: 2026-03-13
Last updated on: 2026-03-19
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| stellar | rs-soroban-sdk | to 22.0.11 (exc) |
| stellar | rs-soroban-sdk | From 23.0.0 (inc) to 23.5.3 (exc) |
| stellar | rs-soroban-sdk | From 25.0.0 (inc) to 25.3.0 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-697 | The product compares two entities in a security-relevant context, but the comparison is incorrect. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability exists in the soroban-sdk Rust package, specifically in how it compares scalar field types (Fr) for BN254 and BLS12-381 curves. The issue is that the equality comparison of these Fr values was done using their raw U256 representations without first reducing them modulo the field modulus r. This means that mathematically equal field elements could be considered not equal if one or both were unreduced (i.e., greater than or equal to r).
An attacker can exploit this by supplying specially crafted Fr values through contract inputs that bypass the usual host-side arithmetic operations which ensure reduction. As a result, smart contracts relying on Fr equality checks for security-critical logic might produce incorrect results, such as incorrect authorization decisions or validation bypasses.
The vulnerability is fixed in soroban-sdk versions 22.0.11, 23.5.3, and 25.3.0 by patching Fr constructors to perform modular reduction on input values, ensuring canonical representations and correct equality comparisons.
How can this vulnerability impact me? :
This vulnerability can impact you if you use smart contracts built with soroban-sdk that rely on Fr equality checks for security-critical logic. An attacker could supply crafted unreduced Fr values that cause these equality checks to fail or behave incorrectly.
The practical impact includes incorrect authorization decisions or validation bypasses within the affected contracts, potentially allowing unauthorized actions or invalid data to be accepted.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability involves incorrect equality comparisons of Fr scalar field types due to unreduced U256 values. Detection involves reviewing smart contracts that accept Fr inputs and perform equality checks to identify if they compare raw U256 values without modular reduction.
Since the issue is in the soroban-sdk Rust package and affects contract logic, detection on a network or system level is not straightforward via standard network commands.
To detect vulnerable code, you can audit contracts for direct equality comparisons of Fr values constructed from user inputs without modular reduction.
If you have access to the Rust environment, you can test for the issue by constructing Fr values with unreduced U256 values and checking if equality comparisons fail unexpectedly. For example, in Rust:
- let r = /* BN254 scalar field modulus */;
- let a = Fr::from_u256(r + 1); // unreduced
- let b = Fr::from_u256(1); // reduced
- assert_eq!(a, b); // This assertion fails before the fix
No specific network or system commands are provided for detection; manual code review and testing in the development environment are recommended.
What immediate steps should I take to mitigate this vulnerability?
The primary mitigation is to upgrade soroban-sdk to a patched version: 22.0.11, 23.5.3, or 25.3.0 or later.
If upgrading is not immediately possible, apply workarounds by ensuring all Fr values are reduced modulo the scalar field modulus r before comparison.
- Manually reduce U256 values modulo r using rem_euclid before constructing Fr values.
- Perform a round-trip through host-side arithmetic operations (e.g., fr_add(val, zero)) which return reduced results.
Note that BN254 does not have dedicated Fr host functions, so manual modular reduction is required for that curve.
Additionally, review smart contracts that rely on Fr equality checks for security-critical logic to ensure they do not compare unreduced values directly.