CVE-2026-32129

soroban-poseidon provides Poseidon and Poseidon2 cryptographic hash functions for Soroban smart contracts. Poseidon V1 (PoseidonSponge) accepts variable-length inputs without injective padding. When a caller provides fewer inputs than the sponge rate (inputs.len() < T - 1), unused rate positions are implicitly zero-filled. This allows trivial hash collisions: for any input vector [m1, ..., mk] hashed with a sponge of rate > k, hash([m1, ..., mk]) equals hash([m1, ..., mk, 0]) because both produce identical pre-permutation states. This affects any use of PoseidonSponge or poseidon_hash where the number of inputs is less than T - 1 (e.g., hashing 1 input with T=3). Poseidon2 (Poseidon2Sponge) is not affected.

soroban-poseidon provides Poseidon and Poseidon2 cryptographic hash functions for Soroban smart contracts. Poseidon V1 (PoseidonSponge) accepts variable-length inputs without injective padding. When a caller provides fewer inputs than the sponge rate (inputs.len() < T - 1), unused rate positions are implicitly zero-filled. This allows trivial hash collisions: for any input vector [m1, ..., mk] hashed with a sponge of rate > k, hash([m1, ..., mk]) equals hash([m1, ..., mk, 0]) because both produce identical pre-permutation states. This affects any use of PoseidonSponge or poseidon_hash where the number of inputs is less than T - 1 (e.g., hashing 1 input with T=3). Poseidon2 (Poseidon2Sponge) is not affected.

## Impact Poseidon V1 (`PoseidonSponge`) accepts variable-length inputs without injective padding. When a caller provides fewer inputs than the sponge rate (`inputs.len() < T - 1`), unused rate positions are implicitly zero-filled. This allows trivial hash collisions: for any input vector `[m1, ..., mk]` hashed with a sponge of rate > k, `hash([m1, ..., mk])` equals `hash([m1, ..., mk, 0])` because both produce identical pre-permutation states. This affects any use of `PoseidonSponge` or `poseidon_hash` where the number of inputs is less than `T - 1` (e.g., hashing 1 input with `T=3`). Poseidon2 (`Poseidon2Sponge`) is **not affected** — it encodes the input length in the capacity element (`IV = input_len << 64`), making different-length inputs produce distinct states. ## Patches Fixed by enforcing `inputs.len() == RATE` in `PoseidonSponge::compute_hash`, matching circom's invariant that `nInputs` always equals `T - 1`. Users should upgrade to the next release containing this fix. ## Workarounds If upgrading is not immediately possible: - Ensure callers **always** use `T = inputs.len() + 1` (full-rate), which is how circom uses Poseidon. For example, to hash 2 inputs, use `T=3`; to hash 1 input, use `T=2`. Never use a sponge with more rate capacity than the number of inputs. - Alternatively, migrate to `Poseidon2Sponge`, which is safe for variable-length inputs due to its length-encoding IV. ## References - [circom Poseidon implementation](https://github.com/iden3/circomlib/blob/master/circuits/poseidon.circom) — reference implementation where `nInputs` determines `T` - [Poseidon paper](https://eprint.iacr.org/2019/458) — Section 4 discusses sponge construction and padding requirements

## Impact Poseidon V1 (`PoseidonSponge`) accepts variable-length inputs without injective padding. When a caller provides fewer inputs than the sponge rate (`inputs.len() < T - 1`), unused rate positions are implicitly zero-filled. This allows trivial hash collisions: for any input vector `[m1, ..., mk]` hashed with a sponge of rate > k, `hash([m1, ..., mk])` equals `hash([m1, ..., mk, 0])` because both produce identical pre-permutation states. This affects any use of `PoseidonSponge` or `poseidon_hash` where the number of inputs is less than `T - 1` (e.g., hashing 1 input with `T=3`). Poseidon2 (`Poseidon2Sponge`) is **not affected** — it encodes the input length in the capacity element (`IV = input_len << 64`), making different-length inputs produce distinct states. ## Patches Fixed by enforcing `inputs.len() == RATE` in `PoseidonSponge::compute_hash`, matching circom's invariant that `nInputs` always equals `T - 1`. Users should upgrade to the next release containing this fix. ## Workarounds If upgrading is not immediately possible: - Ensure callers **always** use `T = inputs.len() + 1` (full-rate), which is how circom uses Poseidon. For example, to hash 2 inputs, use `T=3`; to hash 1 input, use `T=2`. Never use a sponge with more rate capacity than the number of inputs. - Alternatively, migrate to `Poseidon2Sponge`, which is safe for variable-length inputs due to its length-encoding IV. ## References - [circom Poseidon implementation](https://github.com/iden3/circomlib/blob/master/circuits/poseidon.circom) — reference implementation where `nInputs` determines `T` - [Poseidon paper](https://eprint.iacr.org/2019/458) — Section 4 discusses sponge construction and padding requirements

soroban-poseidon proporciona funciones hash criptográficas Poseidon y Poseidon2 para contratos inteligentes de Soroban. Poseidon V1 (PoseidonSponge) acepta entradas de longitud variable sin relleno inyectivo. Cuando un llamador proporciona menos entradas que la tasa de la esponja (inputs.len() &lt; T - 1), las posiciones de tasa no utilizadas se rellenan implícitamente con ceros. Esto permite colisiones hash triviales: para cualquier vector de entrada [m1, ..., mk] hasheado con una esponja de tasa &gt; k, hash([m1, ..., mk]) es igual a hash([m1, ..., mk, 0]) porque ambos producen estados de pre-permutación idénticos. Esto afecta cualquier uso de PoseidonSponge o poseidon_hash donde el número de entradas es menor que T - 1 (p. ej., hashear 1 entrada con T=3). Poseidon2 (Poseidon2Sponge) no se ve afectado.