CVE-2026-32129: 
Rust vulnerability analysis and mitigation

CVE-2026-32129 is a hash collision vulnerability in the soroban-poseidon Rust crate (rs-soroban-poseidon), which provides Poseidon and Poseidon2 cryptographic hash functions for Soroban smart contracts on the Stellar network. The flaw exists in Poseidon V1 (PoseidonSponge), which accepts variable-length inputs without injective padding, enabling trivial hash collisions. Only version 25.0.0 of the soroban-poseidon cargo package is affected; version 25.0.1 contains the fix. The vulnerability was published on March 12, 2026, with a CVSS v4 base score of 8.7 (High) (Github Advisory, Stellar Advisory).

The root cause is classified as CWE-328 (Use of Weak Hash): PoseidonSponge::compute_hash does not enforce that the number of inputs equals the sponge rate (RATE = T - 1). When a caller provides fewer inputs than the rate, unused positions are implicitly zero-filled, causing hash([m1, ..., mk]) to equal hash([m1, ..., mk, 0]) because both produce identical pre-permutation states. For example, hashing 1 input with T=3 is trivially collisible with hashing [input, 0] with the same parameters. The fix (PR #10) enforces inputs.len() == RATE in PoseidonSponge::compute_hash, matching the circom reference implementation's invariant where nInputs always equals T - 1. Poseidon2 (Poseidon2Sponge) is unaffected because it encodes input length in the capacity element (IV = input_len << 64), ensuring domain separation (Github Advisory, Fix PR).

Successful exploitation allows an attacker to forge different inputs that produce identical Poseidon V1 hash outputs, undermining any cryptographic verification relying on hash uniqueness. In the context of Soroban smart contracts, this can enable signature forgery, authentication bypass, impersonation of users, validation of fraudulent transactions, and circumvention of access controls. Confidentiality is not directly impacted, but integrity of smart contract logic and on-chain state is at high risk wherever PoseidonSponge or poseidon_hash is used with fewer inputs than T - 1 (Github Advisory, Stellar Advisory).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at this time. The EPSS score is approximately 0.024% (7th percentile), indicating a low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. No threat actor attribution has been reported (Github Advisory).

1. Identify target: Locate a Soroban smart contract that uses PoseidonSponge or poseidon_hash from soroban-poseidon version 25.0.0 for cryptographic verification (e.g., authentication, commitment schemes, or Merkle proofs).
2. Determine sponge parameters: Identify the sponge width T used by the target contract. If the contract hashes fewer than T - 1 inputs (e.g., 1 input with T=3), it is vulnerable.
3. Construct colliding input: Craft an alternative input vector by appending one or more zero field elements to the original input (e.g., [m1, 0] instead of [m1]). Both inputs will produce the same Poseidon V1 hash due to implicit zero-padding.
4. Submit forged input: Submit the colliding input to the smart contract in place of the legitimate input. The contract's hash-based verification will accept the forged input as valid, enabling authentication bypass, signature forgery, or fraudulent transaction approval (Github Advisory, Stellar Advisory).

• Smart Contract Behavior: Unexpected acceptance of inputs with trailing zero field elements in contracts using PoseidonSponge or poseidon_hash; authentication or verification logic passing for inputs that differ only by appended zeros.
• On-Chain Transactions: Transactions on the Stellar/Soroban network invoking contracts that use Poseidon V1 hashing with mismatched input lengths (inputs shorter than T - 1); duplicate hash values appearing for distinct input vectors in contract state or logs.
• Dependency Audit: Presence of soroban-poseidon version 25.0.0 in Cargo.lock or Cargo.toml of deployed smart contract projects.

Upgrade soroban-poseidon to version 25.0.1 or later, which enforces inputs.len() == RATE in PoseidonSponge::compute_hash and eliminates the collision (Stellar Release). If immediate upgrading is not feasible, ensure all callers use T = inputs.len() + 1 (full-rate usage), so the sponge rate is never larger than the number of inputs — this matches the circom reference implementation's behavior. Alternatively, migrate from PoseidonSponge to Poseidon2Sponge, which is not affected by this vulnerability due to its length-encoding initialization vector (Github Advisory).

The advisory was published by leighmcculloch on the Stellar GitHub repository and the fix was contributed by jayz22 via PR #10, merged on March 11, 2026. The vulnerability received coverage from automated CVE tracking feeds and security aggregators shortly after disclosure. No significant broader media coverage or notable researcher commentary beyond the official advisory and fix PR has been identified (Stellar Advisory, Fix PR).