How severe is GHSA-3g92-f9ch-qjcm?

No CVSS score has been assigned to GHSA-3g92-f9ch-qjcm yet. Review the advisory details and affected package list to assess your exposure.

Which packages are affected by GHSA-3g92-f9ch-qjcm?

GHSA-3g92-f9ch-qjcm affects the following packages: p3-symmetric (crates.io). Ecosystems affected: crates.io.

How do I fix GHSA-3g92-f9ch-qjcm?

No patched version of p3-symmetric has shipped for GHSA-3g92-f9ch-qjcm yet. Where your build allows, override or pin the dependency away from the vulnerable range, and apply any maintainer-recommended mitigation.

How do I detect GHSA-3g92-f9ch-qjcm in my crates.io dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for p3-symmetric. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

How do I mitigate GHSA-3g92-f9ch-qjcm if there is no patch (or I can't update yet)?

If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

How does O3 Security protect against GHSA-3g92-f9ch-qjcm?

O3 pinpoints whether GHSA-3g92-f9ch-qjcm is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Is GHSA-3g92-f9ch-qjcm actively exploited in the wild?

No public exploit code has been indexed for GHSA-3g92-f9ch-qjcm yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

When was GHSA-3g92-f9ch-qjcm published, and has it been updated?

GHSA-3g92-f9ch-qjcm was published on April 16, 2026 and was last updated on April 16, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

🦀 crates.io

GHSA-3g92-f9ch-qjcm

Plonky3: The sponge construction used to get a hash function from a cryptographic permutation is not collision resistant for inputs of different lengths

Published

Apr 16, 2026

Updated

Apr 16, 2026

Affected

1 pkg

Patched

None yet

Exploits

None indexed

Blast Radius

1 pkg affected

🦀p3-symmetric

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects crates.io packages — download data is not available via public APIs for these ecosystems.

Description

Vulnerability

Currently, when hashing, if the number of elements to hash is not a multiple of the rate, hash_iter pads by elements of the current state. This means that it is possible to create iterators of different lengths which lead to an identical hashed state.

Given a simple example using a PaddingFreeSponge with width 8 and rate 4. Start with the zero state: [0, 0, 0, 0, 0, 0, 0, 0] Take the first 4 elements to hash and insert into the first 4 elements of the state: [h0, h1, h2, h3, 0, 0, 0, 0] Run the cryptographic permutation on the state: [p00, p10, p20, p30, p40, p50, p60, p70]

Take the next 4 elements to hash and insert into the first 4 elements of the state: [h4, h5, h6, h7, p40, p50, p60, p70] Run the cryptographic permutation: [p01, p11, p21, p31, p41, p51, p61, p71]

Repeat the above two steps until all elements of the iterator have been consumed.

If the number of elements in the iterator is not a multiple of 4 (say there are 10 elements) then, in the final round, the first 2 elements are overwritten and so our final hash would be of: [h8, h9, p21, p31, p41, p51, p61, p71]

This means that the iterators over the elements [h0, h1, h2, h3, h4, h5, h6, h7, h8, h9] and [h0, h1, h2, h3, h4, h5, h6, h7, h8, h9, p21] would lead to the same final state of the hasher.

Impact

The impact of this vulnerability is a little difficult to estimate. It is important to note that, in circumstances where the number of elements to be hashed is known and fixed in advance, (as is the case for most STARKS), the method is collision resistant. This vulnerability only applies if a malicious user is able to manipulate the number of elements to be hashed.

That being said, there are theoretically situations where this could allow for an amortising of grinding costs (if a prover can manipulate things to get the same hasher state across multiple proofs).

Patches

The fix comes in two parts. The documentation on the current struct PaddingFreeSponge has been improved to clarify its intended use case and highlight that it is not collision resistant if an attacker can modify the number of elements being hashed.

In addition we add a new struct Pad10Sponge which is slightly less efficient but safe in all cases. The padding strategy of the new struct is as follows:

If the number of elements in the iterator is not a multiple of the rate, use a 10 padding scheme. If it is a multiple of the rate add 1 to the first secret state element. In the above example, for hashes of length 9, 10, 11, 12, the final state to be permuted would be [h8, 1, 0, 0, p41, p51, p61, p71] [h8, h9, 1, 0, p41, p51, p61, p71] [h8, h9, h10, 1, p41, p51, p61, p71] [h8, h9, h10, h11, p41 + 1, p51, p61, p71]

As can be seen, it is now impossible for iterators of different lengths to produce the same "final state" to be hashed which restores collision resistance. (See the following for more details padding-in-sponge.pdf)

Thanks

Many thanks to Benedikt Wagner, Dmitry Khovratovich and Bart Mennink for reporting this issue.

Affected Packages

1 total

Ecosystem	Package	Vulnerable range	Fix
🦀crates.io	`p3-symmetric`	all versions	No fix

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for p3-symmetric. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Remediation status
No patched version of p3-symmetric has shipped for GHSA-3g92-f9ch-qjcm yet. Where your build allows, override or pin the dependency away from the vulnerable range, and apply any maintainer-recommended mitigation.
Mitigate without a patch
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-3g92-f9ch-qjcm is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-3g92-f9ch-qjcm. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

### Vulnerability Currently, when hashing, if the number of elements to hash is not a multiple of the rate, `hash_iter` pads by elements of the current state. This means that it is possible to create iterators of different lengths which lead to an identical hashed state. Given a simple example using a `PaddingFreeSponge` with width 8 and rate 4. Start with the zero state: [0, 0, 0, 0, 0, 0, 0, 0] Take the first 4 elements to hash and insert into the first 4 elements of the state: [h0, h1, h2, h3, 0, 0, 0, 0] Run the cryptographic permutation on the state: [p00, p10, p20, p30, p40, p50, p60, p

O3 Security · Impact-Aware SCA

Is GHSA-3g92-f9ch-qjcm in your dependencies?

O3 detects GHSA-3g92-f9ch-qjcm across crates.io dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

Scan my dependencies How O3 SCA works