CVE-2026-32129
Hash Collision Vulnerability in soroban-poseidon PoseidonSponge
Publication date: 2026-03-12
Last updated on: 2026-03-12
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| soroban-poseidon | poseidon | From 2.0 (exc) |
| stellar | rs-soroban-poseidon | to 25.0.1 (exc) |
| stellar | rs-soroban-poseidon | From 25.0.1 (inc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-328 | The product uses an algorithm that produces a digest (output value) that does not meet security expectations for a hash function that allows an adversary to reasonably determine the original input (preimage attack), find another input that can produce the same hash (2nd preimage attack), or find multiple inputs that evaluate to the same hash (birthday attack). |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
The vulnerability in CVE-2026-32129 affects the Poseidon V1 hash function implementation (PoseidonSponge) in the soroban-poseidon library. Poseidon V1 accepts variable-length inputs without proper injective padding, implicitly zero-filling unused rate positions when the number of inputs is less than the sponge rate (inputs.len() < T - 1). This causes trivial hash collisions because the hash of an input vector [m1, ..., mk] is identical to the hash of [m1, ..., mk, 0], as both produce the same pre-permutation sponge state. Essentially, appending zeros to the input does not change the hash output, breaking collision resistance.
The vulnerability does not affect Poseidon2 (Poseidon2Sponge) because it encodes the input length into the sponge state, preventing collisions from variable-length inputs.
The issue was fixed by enforcing that the input length must exactly equal the sponge rate (full-rate absorption), rejecting partial-rate and empty inputs, thereby preventing suffix-zero collisions.
How can this vulnerability impact me? :
This vulnerability can lead to trivial hash collisions in applications using the Poseidon V1 hash function with inputs shorter than the sponge rate. Such collisions undermine the collision resistance property of the hash function, potentially allowing attackers to produce different inputs that yield the same hash output.
In practical terms, this can compromise the integrity and security of systems relying on Poseidon V1 for cryptographic hashing, such as Soroban smart contracts, by enabling hash collision attacks that may affect data validation, authentication, or other cryptographic protocols.
Users unable to upgrade immediately can mitigate the risk by always setting the sponge rate T to inputs.len() + 1 (full-rate usage), avoiding sponge rates larger than the number of inputs, or migrating to the unaffected Poseidon2Sponge implementation.
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 arises from the use of the Poseidon V1 hash function with input lengths less than the sponge rate (inputs.len() < T - 1), causing trivial hash collisions due to implicit zero-padding.
To detect if your system is affected, you should check if the soroban-poseidon library version is 25.0.0 or earlier and if Poseidon V1 is used with variable-length inputs without enforcing full-rate input absorption.
There are no specific network or system commands provided in the resources to detect this vulnerability automatically.
However, you can perform tests by hashing inputs of different lengths and checking for collisions, for example by comparing hash([x]) and hash([x, 0]) outputs using the Poseidon V1 implementation.
What immediate steps should I take to mitigate this vulnerability?
The primary mitigation is to upgrade the rs-soroban-poseidon library to version 25.0.1 or later, where the vulnerability is fixed by enforcing that the input length exactly equals the sponge rate (full-rate absorption).
- Upgrade soroban-poseidon to version 25.0.1 or newer.
- Ensure that Poseidon V1 is only used with inputs where inputs.len() == RATE (full-rate input), rejecting partial-rate or empty inputs.
- If immediate upgrade is not possible, configure the sponge rate T to always be inputs.len() + 1 to avoid partial-rate absorption.
- Consider migrating to Poseidon2Sponge, which is not affected by this vulnerability due to its input length encoding in the sponge state.