GHSA-cp57-fq8g-qh6v RUSTSEC-2026-0077
libcrux has an Incorrect Check of Signer Response Norm During Verification
- Severity
- 0.0 / 10
- High · CVSS 4.0
- Exploit chance (EPSS)
- —
- No score published
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-347 Improper Verification of Cryptographic Signature
- Fix
0.0.8- Upgrade libcrux-ml-dsa to this version or later
Description
The ML-DSA verification algorithm as specified in FIPS 204, subsection 6.3 requires verifiers to check that the infinity norm of the deserialized signer response $z$ does not exceed $\gamma_1 - \beta$ (line 13 of Algorithm 8). The same check is required to be performed during signature generation.
libcrux-ml-dsa did not perform this check correctly during signature verification, accepting signatures with signer response norm above the allowed maximum value. The check is correctly performed during signing.
Impact
Applications using libcrux-ml-dsa for signature verification would have accepted signatures that would be rejected by a conforming implementation.
Mitigation
Starting from version 0.0.8, signature verification uses the correct value for $\gamma_1$ in the signer response norm check.
Affected versions
crates.io
| Package | Vulnerable | Fixed in |
|---|---|---|
| libcrux-ml-dsa | < 0.0.8 |
0.0.8 |
| libcrux-ml-dsa | >= 0.0.0-0, < 0.0.8 |
0.0.8 |
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
libcrux-ml-dsa crates.io → 0.0.8
- cargo
cargo update -p libcrux-ml-dsa --precise 0.0.8
Severity breakdown
CVSS 4.0 0.0
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N
- Attack vector
- Network
- Attack complexity
- Low
- Attack requirements
- None
- Privileges required
- None
- User interaction
- None
- Confidentiality (vulnerable system)
- None
- Integrity (vulnerable system)
- High
- Availability (vulnerable system)
- None
- Confidentiality (subsequent systems)
- None
- Integrity (subsequent systems)
- None
- Availability (subsequent systems)
- None
Weakness
CWE-347: Improper Verification of Cryptographic Signature
The product does not verify, or incorrectly verifies, the cryptographic signature for data.
References
Packages
Other links
Timeline
- Published
- Last updated by the source
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| GHSA-fhvh-vw7h-9xf3 libcrux-ml-dsa: Signature Verification on AVX2 Platforms Mishandles Edge Case | High | Also affects libcrux-ml-dsa |
| RUSTSEC-2026-0126 AVX2 Implementation Did Not Fully Reduce Intermediate Values | Not rated yet | Also affects libcrux-ml-dsa |
| RUSTSEC-2026-0076 libcrux: Panic in Signature Hint Decoding During Verification | High | Also affects libcrux-ml-dsa |
| GHSA-2cgv-28vr-rv6j libcrux incorrectly calculates on aarch64 | High | Also affects libcrux-ml-dsa |
| EEF-CVE-2026-65632 ECDSA signature length is not validated in jose, allowing signature malleability | Not rated yet | Same weakness, CWE-347 |
| GHSA-pxh4-856f-4h89 PyJWT: HS256/384/512 verify accepts empty HMAC key via oct JWK (PyJWK/PyJWKClient) enabling token forgery | High | Same weakness, CWE-347 |
| GHSA-j7h2-66j4-ghjf A russh SSH server accepts a publickey authentication whose signature uses a different algorithm than the one named in the request | Low | Same weakness, CWE-347 |
| GHSA-w2cx-738m-mc7w PyJWT accepts public JWK containers as HMAC secrets | High | Same weakness, CWE-347 |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor