NIST deprecates RSA-2048 from 2030. Find every one of them before attackers do.
🦀 crates.io
Not in CISA KEV

libcrux: Panic in Signature Hint Decoding During VerificationGHSA-xrf2-5r3p-5wgj

Fix: cryspen/libcrux#1348

GHSA-xrf2-5r3p-5wgj is a security vulnerability in libcrux-ml-dsa. A fix is available for libcrux-ml-dsa — see the affected versions and patch details below.

Also known asRUSTSEC-2026-0076
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Mar 27, 2026 · OSV.dev, FIRST.org (EPSS)

Real-World Exposure

1 pkg affected
🦀libcrux-ml-dsa

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

During ML-DSA verification the serialized hint values are decoded as specified in algorithm 22 HintBitUnpack of FIPS 204, subsection 7.1. The algorithm requires that the cumulative hint counters per row of the hint vector are strictly increasing and below a maximum value which depends on the choice of ML-DSA parameter set (line 4).

In libcrux-ml-dsa, hint decoding did not check the boundedness of the cumulative hint counter of the last row of the hint vector.

Impact

A manipulated invalid hint can cause an out-of-bounds memory access since the hint decoding logic may attempt to read outside the bounds of the serialized signature, causing a runtime panic.

Mitigation

Starting from version 0.0.8, hint decoding will check the cumulative hint counter of the last row as well.

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🦀crates.iolibcrux-ml-dsaall versions0.0.8cargo update -p libcrux-ml-dsa --precise 0.0.8

Detection & mitigation playbook

Open-source dependency

  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for libcrux-ml-dsa, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update libcrux-ml-dsa to 0.0.8 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-xrf2-5r3p-5wgj is resolved across your whole dependency graph.

  3. Workarounds

    Stop feeding it untrusted input: reject or quarantine files and payloads from unverified sources until you can upgrade, restrict accepted formats to the ones you actually need, and run the parsing or decoding step in a least-privileged sandbox or short-lived worker so a crash or corrupted read cannot reach the rest of the process.

Frequently Asked Questions

During ML-DSA verification the serialized hint values are decoded as specified in algorithm 22 `HintBitUnpack` of [FIPS 204, subsection 7.1](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf#%5B%7B%22num%22%3A120%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22FitH%22%7D%2C657%5D). The algorithm requires that the cumulative hint counters per row of the hint vector are strictly increasing and below a maximum value which depends on the choice of ML-DSA parameter set (line 4). In libcrux-ml-dsa, hint decoding did not check the boundedness of the cumulative hint counter of the last row of the hint
O3 Security · Impact-Aware SCA

Is GHSA-xrf2-5r3p-5wgj in your dependencies?

Find it across crates.io, including transitive dependencies.

Scan my dependencies How O3 SCA works
libcrux: Panic in Signature Hint Decoding During…