GHSA-h9f2-fgp8-vc4h json
Low-level GCM ignores the operation nonce
published 3mo ago modified last mo. also RUSTSEC-2026-0238
- cvss
- —
- not scored
- cisa kev
- Not listed
- not in CISA's catalog
- epss
- —
- no score, EPSS covers CVEs only
- public exploits
- 0
- none known
Summary
In all published versions of `dcrypt-algorithms` before 2.0.0, the low-level `Gcm` builder required an operation nonce but derived `J0` from the nonce captured by the original `Gcm` constructor. Multiple operations could therefore silently reuse a nonce even when callers supplied distinct values, compromising confidentiality and authenticity under an affected key.
Version 2.0.0 makes `Gcm` key-only and passes the operation nonce through IV derivation, encryption, and decryption. It also corrects non-96-bit IV processing, rejects tags shorter than 96 bits, and enforces counter limits. Applications must upgrade, identify affected keys, rotate them, and re-encrypt affected data; updating the implementation cannot restore security after nonce reuse.
Patch / fix
- crates.io dcrypt-algorithms 2.0.0
Is GHSA-h9f2-fgp8-vc4h in your dependencies? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.
Check with FencerAffected packages
| ecosystem | package | affected | fixed in |
|---|---|---|---|
| crates.io | dcrypt-algorithms | >=0.0.0-0, <2.0.0 |
2.0.0 |
References
Sources
Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.