libcrux-ml-dsa
Libcrux ML-DSA implementation
Activity
- Latest release
- 3w ago
- Total releases
- 19
- Cadence
- ~daily
- Last 12 months
- 18
Details
- License
- Apache-2.0
- First release
- Sep 10, 2025
| Version | Released | |
|---|---|---|
0.0.11
patch
|
0.0.11
patch
Dependencies (14)
+ 6 more
Changelog
Compare changes
|
|
0.0.11-pre.1
pre
|
0.0.11-pre.1
pre
Dependencies (14)
+ 6 more
Changelog
Compare changes
|
|
0.0.10
unknown
|
0.0.10
unknown
Dependencies (14)
+ 6 more
Changelog
Compare changes
|
|
0.0.10-pre.1
unknown
|
0.0.10-pre.1
unknown
Dependencies (14)
+ 6 more
Changelog
Compare changes
|
|
0.0.9
unknown
|
0.0.9
unknown
Dependencies (13)
+ 5 more
Changelog
Compare changes
|
|
0.0.9-rc.2
unknown
2 CVEs
GHSA-fhvh-vw7h-9xf3
RUSTSEC-2026-0125
May 19, 2026
libcrux-ml-dsa: Signature Verification on AVX2 Platforms Mishandles Edge Case
High
Network
Low
None
None
The AVX2 implementation of ML-DSA verification incorrectly implemented
the ImpactAn attacker could make the ML-DSA verifier accept a crafted invalid signature under a maliciously generated verification key, if the AVX2 implementation is used. MitigationFrom version Fixed in
0.0.9
References Updated May 20, 2026 · Source: OSV.dev
RUSTSEC-2026-0126
Apr 27, 2026
AVX2 Implementation Did Not Fully Reduce Intermediate Values The AVX2 implementation of ML-DSA did not fully reduce intermediate inputs to the inverse NTT, which leads to a testable difference in panic behaviour of internal functions compared to the portable implementation. ImpactWe are not aware of inputs to the public key generation, signing or verification APIs that trigger a panic in the AVX2 implementation because the intermediate values were not fully reduced. MitigationFrom version Fixed in
0.0.9
References Updated May 13, 2026 · Source: OSV.dev |
0.0.9-rc.2
unknown
Dependencies (13)
+ 5 more
Changelog
Compare changes
|
|
0.0.9-rc.1
unknown
2 CVEs
GHSA-fhvh-vw7h-9xf3
RUSTSEC-2026-0125
May 19, 2026
libcrux-ml-dsa: Signature Verification on AVX2 Platforms Mishandles Edge Case
High
Network
Low
None
None
The AVX2 implementation of ML-DSA verification incorrectly implemented
the ImpactAn attacker could make the ML-DSA verifier accept a crafted invalid signature under a maliciously generated verification key, if the AVX2 implementation is used. MitigationFrom version Fixed in
0.0.9
References Updated May 20, 2026 · Source: OSV.dev
RUSTSEC-2026-0126
Apr 27, 2026
AVX2 Implementation Did Not Fully Reduce Intermediate Values The AVX2 implementation of ML-DSA did not fully reduce intermediate inputs to the inverse NTT, which leads to a testable difference in panic behaviour of internal functions compared to the portable implementation. ImpactWe are not aware of inputs to the public key generation, signing or verification APIs that trigger a panic in the AVX2 implementation because the intermediate values were not fully reduced. MitigationFrom version Fixed in
0.0.9
References Updated May 13, 2026 · Source: OSV.dev |
0.0.9-rc.1
unknown
Dependencies (13)
+ 5 more
Changelog
Compare changes
|
|
0.0.8
unknown
2 CVEs
GHSA-fhvh-vw7h-9xf3
RUSTSEC-2026-0125
May 19, 2026
libcrux-ml-dsa: Signature Verification on AVX2 Platforms Mishandles Edge Case
High
Network
Low
None
None
The AVX2 implementation of ML-DSA verification incorrectly implemented
the ImpactAn attacker could make the ML-DSA verifier accept a crafted invalid signature under a maliciously generated verification key, if the AVX2 implementation is used. MitigationFrom version Fixed in
0.0.9
References Updated May 20, 2026 · Source: OSV.dev
RUSTSEC-2026-0126
Apr 27, 2026
AVX2 Implementation Did Not Fully Reduce Intermediate Values The AVX2 implementation of ML-DSA did not fully reduce intermediate inputs to the inverse NTT, which leads to a testable difference in panic behaviour of internal functions compared to the portable implementation. ImpactWe are not aware of inputs to the public key generation, signing or verification APIs that trigger a panic in the AVX2 implementation because the intermediate values were not fully reduced. MitigationFrom version Fixed in
0.0.9
References Updated May 13, 2026 · Source: OSV.dev |
0.0.8
unknown
Dependencies (13)
+ 5 more
Changelog
Compare changes
|
|
0.0.8-rc.1
unknown
4 CVEs
GHSA-fhvh-vw7h-9xf3
RUSTSEC-2026-0125
May 19, 2026
libcrux-ml-dsa: Signature Verification on AVX2 Platforms Mishandles Edge Case
High
Network
Low
None
None
The AVX2 implementation of ML-DSA verification incorrectly implemented
the ImpactAn attacker could make the ML-DSA verifier accept a crafted invalid signature under a maliciously generated verification key, if the AVX2 implementation is used. MitigationFrom version Fixed in
0.0.9
References Updated May 20, 2026 · Source: OSV.dev
RUSTSEC-2026-0126
Apr 27, 2026
AVX2 Implementation Did Not Fully Reduce Intermediate Values The AVX2 implementation of ML-DSA did not fully reduce intermediate inputs to the inverse NTT, which leads to a testable difference in panic behaviour of internal functions compared to the portable implementation. ImpactWe are not aware of inputs to the public key generation, signing or verification APIs that trigger a panic in the AVX2 implementation because the intermediate values were not fully reduced. MitigationFrom version Fixed in
0.0.9
References Updated May 13, 2026 · Source: OSV.dev
GHSA-cp57-fq8g-qh6v
RUSTSEC-2026-0077
Mar 26, 2026
libcrux has an Incorrect Check of Signer Response Norm During Verification
High
Network
Low
None
None
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. ImpactApplications using libcrux-ml-dsa for signature verification would have accepted signatures that would be rejected by a conforming implementation. MitigationStarting from version Fixed in
0.0.8
References Updated Mar 27, 2026 · Source: OSV.dev
GHSA-xrf2-5r3p-5wgj
RUSTSEC-2026-0076
Mar 26, 2026
libcrux: Panic in Signature Hint Decoding During Verification
High
Network
Low
None
None
During ML-DSA verification the serialized hint values are decoded as specified in algorithm 22 In libcrux-ml-dsa, hint decoding did not check the boundedness of the cumulative hint counter of the last row of the hint vector. ImpactA 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. MitigationStarting from version Fixed in
0.0.8
References Updated Mar 27, 2026 · Source: OSV.dev |
0.0.8-rc.1
unknown
Dependencies (13)
+ 5 more
Changelog
Compare changes
|
|
0.0.7
unknown
4 CVEs
GHSA-fhvh-vw7h-9xf3
RUSTSEC-2026-0125
May 19, 2026
libcrux-ml-dsa: Signature Verification on AVX2 Platforms Mishandles Edge Case
High
Network
Low
None
None
The AVX2 implementation of ML-DSA verification incorrectly implemented
the ImpactAn attacker could make the ML-DSA verifier accept a crafted invalid signature under a maliciously generated verification key, if the AVX2 implementation is used. MitigationFrom version Fixed in
0.0.9
References Updated May 20, 2026 · Source: OSV.dev
RUSTSEC-2026-0126
Apr 27, 2026
AVX2 Implementation Did Not Fully Reduce Intermediate Values The AVX2 implementation of ML-DSA did not fully reduce intermediate inputs to the inverse NTT, which leads to a testable difference in panic behaviour of internal functions compared to the portable implementation. ImpactWe are not aware of inputs to the public key generation, signing or verification APIs that trigger a panic in the AVX2 implementation because the intermediate values were not fully reduced. MitigationFrom version Fixed in
0.0.9
References Updated May 13, 2026 · Source: OSV.dev
GHSA-cp57-fq8g-qh6v
RUSTSEC-2026-0077
Mar 26, 2026
libcrux has an Incorrect Check of Signer Response Norm During Verification
High
Network
Low
None
None
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. ImpactApplications using libcrux-ml-dsa for signature verification would have accepted signatures that would be rejected by a conforming implementation. MitigationStarting from version Fixed in
0.0.8
References Updated Mar 27, 2026 · Source: OSV.dev
GHSA-xrf2-5r3p-5wgj
RUSTSEC-2026-0076
Mar 26, 2026
libcrux: Panic in Signature Hint Decoding During Verification
High
Network
Low
None
None
During ML-DSA verification the serialized hint values are decoded as specified in algorithm 22 In libcrux-ml-dsa, hint decoding did not check the boundedness of the cumulative hint counter of the last row of the hint vector. ImpactA 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. MitigationStarting from version Fixed in
0.0.8
References Updated Mar 27, 2026 · Source: OSV.dev |
0.0.7
unknown
Dependencies (13)
+ 5 more
Changelog
Compare changes
|
|
0.0.7-pre.2
unknown
4 CVEs
GHSA-fhvh-vw7h-9xf3
RUSTSEC-2026-0125
May 19, 2026
libcrux-ml-dsa: Signature Verification on AVX2 Platforms Mishandles Edge Case
High
Network
Low
None
None
The AVX2 implementation of ML-DSA verification incorrectly implemented
the ImpactAn attacker could make the ML-DSA verifier accept a crafted invalid signature under a maliciously generated verification key, if the AVX2 implementation is used. MitigationFrom version Fixed in
0.0.9
References Updated May 20, 2026 · Source: OSV.dev
RUSTSEC-2026-0126
Apr 27, 2026
AVX2 Implementation Did Not Fully Reduce Intermediate Values The AVX2 implementation of ML-DSA did not fully reduce intermediate inputs to the inverse NTT, which leads to a testable difference in panic behaviour of internal functions compared to the portable implementation. ImpactWe are not aware of inputs to the public key generation, signing or verification APIs that trigger a panic in the AVX2 implementation because the intermediate values were not fully reduced. MitigationFrom version Fixed in
0.0.9
References Updated May 13, 2026 · Source: OSV.dev
GHSA-cp57-fq8g-qh6v
RUSTSEC-2026-0077
Mar 26, 2026
libcrux has an Incorrect Check of Signer Response Norm During Verification
High
Network
Low
None
None
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. ImpactApplications using libcrux-ml-dsa for signature verification would have accepted signatures that would be rejected by a conforming implementation. MitigationStarting from version Fixed in
0.0.8
References Updated Mar 27, 2026 · Source: OSV.dev
GHSA-xrf2-5r3p-5wgj
RUSTSEC-2026-0076
Mar 26, 2026
libcrux: Panic in Signature Hint Decoding During Verification
High
Network
Low
None
None
During ML-DSA verification the serialized hint values are decoded as specified in algorithm 22 In libcrux-ml-dsa, hint decoding did not check the boundedness of the cumulative hint counter of the last row of the hint vector. ImpactA 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. MitigationStarting from version Fixed in
0.0.8
References Updated Mar 27, 2026 · Source: OSV.dev |
0.0.7-pre.2
unknown
Dependencies (13)
+ 5 more
Changelog
Compare changes
|
|
0.0.7-pre.1
unknown
4 CVEs
GHSA-fhvh-vw7h-9xf3
RUSTSEC-2026-0125
May 19, 2026
libcrux-ml-dsa: Signature Verification on AVX2 Platforms Mishandles Edge Case
High
Network
Low
None
None
The AVX2 implementation of ML-DSA verification incorrectly implemented
the ImpactAn attacker could make the ML-DSA verifier accept a crafted invalid signature under a maliciously generated verification key, if the AVX2 implementation is used. MitigationFrom version Fixed in
0.0.9
References Updated May 20, 2026 · Source: OSV.dev
RUSTSEC-2026-0126
Apr 27, 2026
AVX2 Implementation Did Not Fully Reduce Intermediate Values The AVX2 implementation of ML-DSA did not fully reduce intermediate inputs to the inverse NTT, which leads to a testable difference in panic behaviour of internal functions compared to the portable implementation. ImpactWe are not aware of inputs to the public key generation, signing or verification APIs that trigger a panic in the AVX2 implementation because the intermediate values were not fully reduced. MitigationFrom version Fixed in
0.0.9
References Updated May 13, 2026 · Source: OSV.dev
GHSA-cp57-fq8g-qh6v
RUSTSEC-2026-0077
Mar 26, 2026
libcrux has an Incorrect Check of Signer Response Norm During Verification
High
Network
Low
None
None
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. ImpactApplications using libcrux-ml-dsa for signature verification would have accepted signatures that would be rejected by a conforming implementation. MitigationStarting from version Fixed in
0.0.8
References Updated Mar 27, 2026 · Source: OSV.dev
GHSA-xrf2-5r3p-5wgj
RUSTSEC-2026-0076
Mar 26, 2026
libcrux: Panic in Signature Hint Decoding During Verification
High
Network
Low
None
None
During ML-DSA verification the serialized hint values are decoded as specified in algorithm 22 In libcrux-ml-dsa, hint decoding did not check the boundedness of the cumulative hint counter of the last row of the hint vector. ImpactA 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. MitigationStarting from version Fixed in
0.0.8
References Updated Mar 27, 2026 · Source: OSV.dev |
0.0.7-pre.1
unknown
Dependencies (13)
+ 5 more
Changelog
Compare changes
|
|
0.0.6
unknown
4 CVEs
GHSA-fhvh-vw7h-9xf3
RUSTSEC-2026-0125
May 19, 2026
libcrux-ml-dsa: Signature Verification on AVX2 Platforms Mishandles Edge Case
High
Network
Low
None
None
The AVX2 implementation of ML-DSA verification incorrectly implemented
the ImpactAn attacker could make the ML-DSA verifier accept a crafted invalid signature under a maliciously generated verification key, if the AVX2 implementation is used. MitigationFrom version Fixed in
0.0.9
References Updated May 20, 2026 · Source: OSV.dev
RUSTSEC-2026-0126
Apr 27, 2026
AVX2 Implementation Did Not Fully Reduce Intermediate Values The AVX2 implementation of ML-DSA did not fully reduce intermediate inputs to the inverse NTT, which leads to a testable difference in panic behaviour of internal functions compared to the portable implementation. ImpactWe are not aware of inputs to the public key generation, signing or verification APIs that trigger a panic in the AVX2 implementation because the intermediate values were not fully reduced. MitigationFrom version Fixed in
0.0.9
References Updated May 13, 2026 · Source: OSV.dev
GHSA-cp57-fq8g-qh6v
RUSTSEC-2026-0077
Mar 26, 2026
libcrux has an Incorrect Check of Signer Response Norm During Verification
High
Network
Low
None
None
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. ImpactApplications using libcrux-ml-dsa for signature verification would have accepted signatures that would be rejected by a conforming implementation. MitigationStarting from version Fixed in
0.0.8
References Updated Mar 27, 2026 · Source: OSV.dev
GHSA-xrf2-5r3p-5wgj
RUSTSEC-2026-0076
Mar 26, 2026
libcrux: Panic in Signature Hint Decoding During Verification
High
Network
Low
None
None
During ML-DSA verification the serialized hint values are decoded as specified in algorithm 22 In libcrux-ml-dsa, hint decoding did not check the boundedness of the cumulative hint counter of the last row of the hint vector. ImpactA 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. MitigationStarting from version Fixed in
0.0.8
References Updated Mar 27, 2026 · Source: OSV.dev |
0.0.6
unknown
Dependencies (13)
+ 5 more
Changelog
Compare changes
|
|
0.0.6-pre.1
unknown
4 CVEs
GHSA-fhvh-vw7h-9xf3
RUSTSEC-2026-0125
May 19, 2026
libcrux-ml-dsa: Signature Verification on AVX2 Platforms Mishandles Edge Case
High
Network
Low
None
None
The AVX2 implementation of ML-DSA verification incorrectly implemented
the ImpactAn attacker could make the ML-DSA verifier accept a crafted invalid signature under a maliciously generated verification key, if the AVX2 implementation is used. MitigationFrom version Fixed in
0.0.9
References Updated May 20, 2026 · Source: OSV.dev
RUSTSEC-2026-0126
Apr 27, 2026
AVX2 Implementation Did Not Fully Reduce Intermediate Values The AVX2 implementation of ML-DSA did not fully reduce intermediate inputs to the inverse NTT, which leads to a testable difference in panic behaviour of internal functions compared to the portable implementation. ImpactWe are not aware of inputs to the public key generation, signing or verification APIs that trigger a panic in the AVX2 implementation because the intermediate values were not fully reduced. MitigationFrom version Fixed in
0.0.9
References Updated May 13, 2026 · Source: OSV.dev
GHSA-cp57-fq8g-qh6v
RUSTSEC-2026-0077
Mar 26, 2026
libcrux has an Incorrect Check of Signer Response Norm During Verification
High
Network
Low
None
None
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. ImpactApplications using libcrux-ml-dsa for signature verification would have accepted signatures that would be rejected by a conforming implementation. MitigationStarting from version Fixed in
0.0.8
References Updated Mar 27, 2026 · Source: OSV.dev
GHSA-xrf2-5r3p-5wgj
RUSTSEC-2026-0076
Mar 26, 2026
libcrux: Panic in Signature Hint Decoding During Verification
High
Network
Low
None
None
During ML-DSA verification the serialized hint values are decoded as specified in algorithm 22 In libcrux-ml-dsa, hint decoding did not check the boundedness of the cumulative hint counter of the last row of the hint vector. ImpactA 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. MitigationStarting from version Fixed in
0.0.8
References Updated Mar 27, 2026 · Source: OSV.dev |
0.0.6-pre.1
unknown
Dependencies (13)
+ 5 more
Changelog
Compare changes
|
|
0.0.5
unknown
4 CVEs
GHSA-fhvh-vw7h-9xf3
RUSTSEC-2026-0125
May 19, 2026
libcrux-ml-dsa: Signature Verification on AVX2 Platforms Mishandles Edge Case
High
Network
Low
None
None
The AVX2 implementation of ML-DSA verification incorrectly implemented
the ImpactAn attacker could make the ML-DSA verifier accept a crafted invalid signature under a maliciously generated verification key, if the AVX2 implementation is used. MitigationFrom version Fixed in
0.0.9
References Updated May 20, 2026 · Source: OSV.dev
RUSTSEC-2026-0126
Apr 27, 2026
AVX2 Implementation Did Not Fully Reduce Intermediate Values The AVX2 implementation of ML-DSA did not fully reduce intermediate inputs to the inverse NTT, which leads to a testable difference in panic behaviour of internal functions compared to the portable implementation. ImpactWe are not aware of inputs to the public key generation, signing or verification APIs that trigger a panic in the AVX2 implementation because the intermediate values were not fully reduced. MitigationFrom version Fixed in
0.0.9
References Updated May 13, 2026 · Source: OSV.dev
GHSA-cp57-fq8g-qh6v
RUSTSEC-2026-0077
Mar 26, 2026
libcrux has an Incorrect Check of Signer Response Norm During Verification
High
Network
Low
None
None
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. ImpactApplications using libcrux-ml-dsa for signature verification would have accepted signatures that would be rejected by a conforming implementation. MitigationStarting from version Fixed in
0.0.8
References Updated Mar 27, 2026 · Source: OSV.dev
GHSA-xrf2-5r3p-5wgj
RUSTSEC-2026-0076
Mar 26, 2026
libcrux: Panic in Signature Hint Decoding During Verification
High
Network
Low
None
None
During ML-DSA verification the serialized hint values are decoded as specified in algorithm 22 In libcrux-ml-dsa, hint decoding did not check the boundedness of the cumulative hint counter of the last row of the hint vector. ImpactA 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. MitigationStarting from version Fixed in
0.0.8
References Updated Mar 27, 2026 · Source: OSV.dev |
0.0.5
unknown
Dependencies (13)
+ 5 more
Changelog
Compare changes
|
|
0.0.5-pre.1
unknown
4 CVEs
GHSA-fhvh-vw7h-9xf3
RUSTSEC-2026-0125
May 19, 2026
libcrux-ml-dsa: Signature Verification on AVX2 Platforms Mishandles Edge Case
High
Network
Low
None
None
The AVX2 implementation of ML-DSA verification incorrectly implemented
the ImpactAn attacker could make the ML-DSA verifier accept a crafted invalid signature under a maliciously generated verification key, if the AVX2 implementation is used. MitigationFrom version Fixed in
0.0.9
References Updated May 20, 2026 · Source: OSV.dev
RUSTSEC-2026-0126
Apr 27, 2026
AVX2 Implementation Did Not Fully Reduce Intermediate Values The AVX2 implementation of ML-DSA did not fully reduce intermediate inputs to the inverse NTT, which leads to a testable difference in panic behaviour of internal functions compared to the portable implementation. ImpactWe are not aware of inputs to the public key generation, signing or verification APIs that trigger a panic in the AVX2 implementation because the intermediate values were not fully reduced. MitigationFrom version Fixed in
0.0.9
References Updated May 13, 2026 · Source: OSV.dev
GHSA-cp57-fq8g-qh6v
RUSTSEC-2026-0077
Mar 26, 2026
libcrux has an Incorrect Check of Signer Response Norm During Verification
High
Network
Low
None
None
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. ImpactApplications using libcrux-ml-dsa for signature verification would have accepted signatures that would be rejected by a conforming implementation. MitigationStarting from version Fixed in
0.0.8
References Updated Mar 27, 2026 · Source: OSV.dev
GHSA-xrf2-5r3p-5wgj
RUSTSEC-2026-0076
Mar 26, 2026
libcrux: Panic in Signature Hint Decoding During Verification
High
Network
Low
None
None
During ML-DSA verification the serialized hint values are decoded as specified in algorithm 22 In libcrux-ml-dsa, hint decoding did not check the boundedness of the cumulative hint counter of the last row of the hint vector. ImpactA 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. MitigationStarting from version Fixed in
0.0.8
References Updated Mar 27, 2026 · Source: OSV.dev |
0.0.5-pre.1
unknown
Dependencies (13)
+ 5 more
Changelog
Compare changes
|
|
0.0.4
unknown
4 CVEs
GHSA-fhvh-vw7h-9xf3
RUSTSEC-2026-0125
May 19, 2026
libcrux-ml-dsa: Signature Verification on AVX2 Platforms Mishandles Edge Case
High
Network
Low
None
None
The AVX2 implementation of ML-DSA verification incorrectly implemented
the ImpactAn attacker could make the ML-DSA verifier accept a crafted invalid signature under a maliciously generated verification key, if the AVX2 implementation is used. MitigationFrom version Fixed in
0.0.9
References Updated May 20, 2026 · Source: OSV.dev
RUSTSEC-2026-0126
Apr 27, 2026
AVX2 Implementation Did Not Fully Reduce Intermediate Values The AVX2 implementation of ML-DSA did not fully reduce intermediate inputs to the inverse NTT, which leads to a testable difference in panic behaviour of internal functions compared to the portable implementation. ImpactWe are not aware of inputs to the public key generation, signing or verification APIs that trigger a panic in the AVX2 implementation because the intermediate values were not fully reduced. MitigationFrom version Fixed in
0.0.9
References Updated May 13, 2026 · Source: OSV.dev
GHSA-cp57-fq8g-qh6v
RUSTSEC-2026-0077
Mar 26, 2026
libcrux has an Incorrect Check of Signer Response Norm During Verification
High
Network
Low
None
None
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. ImpactApplications using libcrux-ml-dsa for signature verification would have accepted signatures that would be rejected by a conforming implementation. MitigationStarting from version Fixed in
0.0.8
References Updated Mar 27, 2026 · Source: OSV.dev
GHSA-xrf2-5r3p-5wgj
RUSTSEC-2026-0076
Mar 26, 2026
libcrux: Panic in Signature Hint Decoding During Verification
High
Network
Low
None
None
During ML-DSA verification the serialized hint values are decoded as specified in algorithm 22 In libcrux-ml-dsa, hint decoding did not check the boundedness of the cumulative hint counter of the last row of the hint vector. ImpactA 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. MitigationStarting from version Fixed in
0.0.8
References Updated Mar 27, 2026 · Source: OSV.dev |
0.0.4
unknown
Dependencies (12)
+ 4 more
Changelog
Compare changes
|
|
0.0.4-pre.1
unknown
5 CVEs
GHSA-fhvh-vw7h-9xf3
RUSTSEC-2026-0125
May 19, 2026
libcrux-ml-dsa: Signature Verification on AVX2 Platforms Mishandles Edge Case
High
Network
Low
None
None
The AVX2 implementation of ML-DSA verification incorrectly implemented
the ImpactAn attacker could make the ML-DSA verifier accept a crafted invalid signature under a maliciously generated verification key, if the AVX2 implementation is used. MitigationFrom version Fixed in
0.0.9
References Updated May 20, 2026 · Source: OSV.dev
RUSTSEC-2026-0126
Apr 27, 2026
AVX2 Implementation Did Not Fully Reduce Intermediate Values The AVX2 implementation of ML-DSA did not fully reduce intermediate inputs to the inverse NTT, which leads to a testable difference in panic behaviour of internal functions compared to the portable implementation. ImpactWe are not aware of inputs to the public key generation, signing or verification APIs that trigger a panic in the AVX2 implementation because the intermediate values were not fully reduced. MitigationFrom version Fixed in
0.0.9
References Updated May 13, 2026 · Source: OSV.dev
GHSA-cp57-fq8g-qh6v
RUSTSEC-2026-0077
Mar 26, 2026
libcrux has an Incorrect Check of Signer Response Norm During Verification
High
Network
Low
None
None
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. ImpactApplications using libcrux-ml-dsa for signature verification would have accepted signatures that would be rejected by a conforming implementation. MitigationStarting from version Fixed in
0.0.8
References Updated Mar 27, 2026 · Source: OSV.dev
GHSA-xrf2-5r3p-5wgj
RUSTSEC-2026-0076
Mar 26, 2026
libcrux: Panic in Signature Hint Decoding During Verification
High
Network
Low
None
None
During ML-DSA verification the serialized hint values are decoded as specified in algorithm 22 In libcrux-ml-dsa, hint decoding did not check the boundedness of the cumulative hint counter of the last row of the hint vector. ImpactA 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. MitigationStarting from version Fixed in
0.0.8
References Updated Mar 27, 2026 · Source: OSV.dev
GHSA-2cgv-28vr-rv6j
RUSTSEC-2025-0133
Dec 04, 2025
libcrux incorrectly calculates on aarch64
High
Network
Low
None
None
On platforms without the The issue has been fixed in v0.0.4. Affected versions
0.0.3
Fixed in
0.0.4
References Updated Feb 22, 2026 · Source: OSV.dev |
0.0.4-pre.1
unknown
Dependencies (12)
+ 4 more
Changelog
Compare changes
|
|
0.0.3
unknown
yanked
5 CVEs
GHSA-fhvh-vw7h-9xf3
RUSTSEC-2026-0125
May 19, 2026
libcrux-ml-dsa: Signature Verification on AVX2 Platforms Mishandles Edge Case
High
Network
Low
None
None
The AVX2 implementation of ML-DSA verification incorrectly implemented
the ImpactAn attacker could make the ML-DSA verifier accept a crafted invalid signature under a maliciously generated verification key, if the AVX2 implementation is used. MitigationFrom version Fixed in
0.0.9
References Updated May 20, 2026 · Source: OSV.dev
RUSTSEC-2026-0126
Apr 27, 2026
AVX2 Implementation Did Not Fully Reduce Intermediate Values The AVX2 implementation of ML-DSA did not fully reduce intermediate inputs to the inverse NTT, which leads to a testable difference in panic behaviour of internal functions compared to the portable implementation. ImpactWe are not aware of inputs to the public key generation, signing or verification APIs that trigger a panic in the AVX2 implementation because the intermediate values were not fully reduced. MitigationFrom version Fixed in
0.0.9
References Updated May 13, 2026 · Source: OSV.dev
GHSA-cp57-fq8g-qh6v
RUSTSEC-2026-0077
Mar 26, 2026
libcrux has an Incorrect Check of Signer Response Norm During Verification
High
Network
Low
None
None
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. ImpactApplications using libcrux-ml-dsa for signature verification would have accepted signatures that would be rejected by a conforming implementation. MitigationStarting from version Fixed in
0.0.8
References Updated Mar 27, 2026 · Source: OSV.dev
GHSA-xrf2-5r3p-5wgj
RUSTSEC-2026-0076
Mar 26, 2026
libcrux: Panic in Signature Hint Decoding During Verification
High
Network
Low
None
None
During ML-DSA verification the serialized hint values are decoded as specified in algorithm 22 In libcrux-ml-dsa, hint decoding did not check the boundedness of the cumulative hint counter of the last row of the hint vector. ImpactA 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. MitigationStarting from version Fixed in
0.0.8
References Updated Mar 27, 2026 · Source: OSV.dev
GHSA-2cgv-28vr-rv6j
RUSTSEC-2025-0133
Dec 04, 2025
libcrux incorrectly calculates on aarch64
High
Network
Low
None
None
On platforms without the The issue has been fixed in v0.0.4. Affected versions
0.0.3
Fixed in
0.0.4
References Updated Feb 22, 2026 · Source: OSV.dev |
0.0.3
unknown
yanked
Dependencies (12)
+ 4 more
Changelog
|