Skip to content
Patch Next
Sign inAdd to your agent

← Public intelligence

crates.io package

soroban-poseidon

Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.

Open advisories

1 actionable advisory, newest first. Withdrawn advisories and news are excluded. Coverage is partial.

  1. High, CVSS 8.7crates.ioPublished

    Poseidon V1 variable-length input collision via implicit zero-padding

    CVE-2026-32129 · GHSA-g2p6-hh5v-7hfm

    Affected
    • crates.io soroban-poseidon < 25.0.1
    Fixed in
    25.0.1· Vendor fix available
    Issue
    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 poseidonhash 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 = inputlen << 64), making different-length inputs produce distinct states. Patches Fixed by enforcing inputs.len() == RATE in PoseidonSponge::computehash, 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…

    Recommended action: Upgrade to 25.0.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.comSource checked Evidence →