GHSA-pv9v-5j35-xwcr json
libcrux Panics During Standalone MAC Operations
published 8mo ago modified 7mo ago also RUSTSEC-2026-0073
- 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
An incorrect constant for the key length in libcrux-poly1305 caused the standalone MAC function `libcrux_poly1305::mac` to always panic with an out-of-bounds memory access.
## Impact Applications wishing to use libcrux-poly1305 as a standalone MAC would experience panics. The use of libcrux-poly1305 in libcrux-chacha20poly1305 is unaffected.
## Mitigation Starting from version `0.0.5`, the correct value is used for the key length constant.
Patch / fix
Is GHSA-pv9v-5j35-xwcr 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 | libcrux-poly1305 | <0.0.5 >=0.0.0-0, <0.0.5 |
0.0.5 |
Classification
References
-
github.com
/cryspen/libcrux/pull/1351
web
-
github.com
/cryspen/libcrux
package
-
rustsec.org
/advisories/RUSTSEC-2026-0073.html
web, advisory
-
crates.io
/crates/libcrux-poly1305
package
Sources
- GitHub Advisory GHSA-pv9v-5j35-xwcr
- OSV RUSTSEC-2026-0073
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.