GHSA-2cgv-28vr-rv6j RUSTSEC-2025-0133
libcrux incorrectly calculates on aarch64
High
crates.io
Description
On platforms without the core::arch::aarch64::vxarq_u64 intrinsic, an unverified fallback in libcrux-intrinsics v0.0.3
passed incorrect arguments and produced wrong results. This corrupted SHA-3 digests and caused libcrux-ml-kem and
libcrux-ml-dsa to sample incorrectly, yielding incorrect shared secrets and invalid signatures.
The issue has been fixed in v0.0.4.
Affected versions
crates.io
| Package | Vulnerable | Fixed in |
|---|---|---|
| libcrux-intrinsics | >= 0.0.3, < 0.0.4 |
0.0.4 |
| libcrux-intrinsics | >= 0.0.4-0, < 0.0.4 |
0.0.4 |
| libcrux-ml-dsa | >= 0.0.3, < 0.0.4 |
0.0.4 |
| libcrux-ml-kem | >= 0.0.3, < 0.0.4 |
0.0.4 |
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-intrinsics crates.io → 0.0.4
- cargo
cargo update -p libcrux-intrinsics --precise 0.0.4
libcrux-ml-dsa crates.io → 0.0.4
- cargo
cargo update -p libcrux-ml-dsa --precise 0.0.4
libcrux-ml-kem crates.io → 0.0.4
- cargo
cargo update -p libcrux-ml-kem --precise 0.0.4
Severity breakdown
CVSS 4.0 0.0
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:L/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)
- High
- Integrity (vulnerable system)
- Low
- Availability (vulnerable system)
- None
- Confidentiality (subsequent systems)
- None
- Integrity (subsequent systems)
- None
- Availability (subsequent systems)
- None
Weakness
CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.
How to prevent it
- Architecture and Design: Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.
CWE-327: Use of a Broken or Risky Cryptographic Algorithm
The product uses a broken or risky cryptographic algorithm or protocol.
How to prevent it
- Architecture and Design: When there is a need to store or transmit sensitive data, use strong, up-to-date cryptographic algorithms to encrypt that data. Select a well-vetted algorithm that is currently considered to be strong by experts in the field, and use well-tested implementations. As with all cryptographic mechanisms, the source code should be available for analysis. For example, US government systems require FIPS 140-2 certification [REF-1192]. Do not develop custom or private cryptographic algorithms. They will likely be exposed to attacks that are well-understood by cryptographers. Reverse engineering techniques are mature. If the algorithm can be compromised if attackers find out how it works, then it is especially weak. Periodically ensure that the cryptography has not become obsolete. Some older algorithms, once thought to require a billion years of computing time, can now be broken in days or hours. This includes MD4, MD5, SHA1, DES, and other algorithms that were once regarded as strong. [REF-267]
- Architecture and Design: Ensure that the design allows one cryptographic algorithm to be replaced with another in the next generation or version. Where possible, use wrappers to make the interfaces uniform. This will make it easier to upgrade to stronger algorithms. With hardware, design the product at the Intellectual Property (IP) level so that one cryptographic algorithm can be replaced with another in the next generation of the hardware product.
- Architecture and Design: Carefully manage and protect cryptographic keys (see CWE-320). If the keys can be guessed or stolen, then the strength of the cryptography itself is irrelevant.
- Architecture and Design: Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482]. Industry-standard implementations will save development time and may be more likely to avoid errors that can occur during implementation of cryptographic algorithms. Consider the ESAPI Encryption feature.
- Implementation, Architecture and Design: When using industry-approved techniques, use them correctly. Don't cut corners by skipping resource-intensive steps (CWE-325). These steps are often essential for preventing common attacks.
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-cp57-fq8g-qh6v libcrux has an Incorrect Check of Signer Response Norm During Verification | High | Also affects libcrux-ml-dsa |
| GHSA-j7qq-vr8c-xvw3 MLflow CrewAI autologging records LLM provider API keys in logged trace spans | Medium | Same weakness, CWE-200 |
| GHSA-gqh3-7856-rjjg ApostropheCMS: :_id/locales REST route omits the public-API authorization gate its sibling read routes enforce (unauthenticated doc-existence + locale metadata disclosure) | Medium | Same weakness, CWE-200 |
| GHSA-rqgm-cfrp-4hx8 ApostropheCMS: Unauthenticated publicApiProjection bypass via search and sort query builders in the public REST API | Medium | Same weakness, CWE-200 |
| GHSA-f66c-mpj2-3r8h ApostropheCMS: POST /api/v1/@apostrophecms/doc/slugTaken discloses existence of private/admin-only content to any authenticated user | Medium | Same weakness, CWE-200 |
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