liboqs: Missing value barrier in FO implicit rejection path (FrodoKEM, NTRU, and others)
- Exploited
- No known exploitation
- Fix
- Fixed in 0.16.0
- Who is exposed
- Not reported
Do first: Upgrade to a fixed version: 0.16.0.
- Last modified
- A 0-100 score for how much a CVE matters across the industry: exploitation, exposure, how widely the software is used, severity and whether a fix exists.What do these mean? →
- 5/100 · provisional
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
liboqs, a C library of post-quantum cryptography algorithms, has a flaw in the FrodoKEM-640, FrodoKEM-976, and FrodoKEM-1344 AES and SHAKE reference implementations, which can be triggered when the code is built with Clang 17 or later at certain optimization levels such as -Os. A local attacker who can run repeated cache-timing measurements could use this to help recover a private key, and the bug does not affect default -O3 builds.
Written by anthropic/claude-haiku-5.5 from the sources below. Verify against them.
Read the original description
liboqs is a C-language cryptographic library that provides implementations of post-quantum cryptography algorithms. Prior to 0.16.0, the ct_select function in src/kem/frodokem/external/util.c for the FrodoKEM-640, FrodoKEM-976, and FrodoKEM-1344 AES and SHAKE reference variants lacks a value barrier in the Fujisaki-Okamoto implicit-rejection path. When compiled with Clang 17 or later at an affected optimization level such as -Os, the compiler can emit a secret-dependent conditional load, causing the real and rejection secret paths to leave distinguishable cache residency after successful and failed decapsulation. A local attacker able to perform repeated cache-timing measurements may use this oracle as part of a private-key recovery attack. Default -O3 builds vectorize both source loads and do not exhibit the reported behavior, and the advisory does not report the same generated memory-access pattern in NTRU, NTRU-Prime, BIKE, HQC, Classic McEliece, Kyber, or the already-barriered ML-KEM implementation. This issue is fixed in version 0.16.0.
cve.now Index
- Exploitation?/40Unknown. No CISA SSVC exploitation rating yet
- Exposure?/25Unknown. No advisory context yet
- Reach?/20Unknown. No tracked technology or package matched
- Severity5.1/10CVSS 5.1
- No patch0/5No signal
What would change the score
- Would score about 60 if added to CISA KEV
- Would score about 55 if CISA's SSVC rates exploitation active
- Would score about 27 if advisories confirm default setups are exposed
What to do
Upgrade to a fixed version: 0.16.0.
Timeline
- CVE published
- First seen by cve.now
Affected versions
- open-quantum-safe liboqs
fixed in 0.16.0
Evidence 4
- Advisory
- Repository
- Repository
- Repository
Corrections
None so far.
Something wrong on this page? Report an error. Every fix is listed here.
Questions about CVE-2026-44519
Is CVE-2026-44519 being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data
Which versions are affected by CVE-2026-44519?
liboqs: before 0.16.0.Source: cve.now feed data
How do I fix CVE-2026-44519?
Upgrade to a fixed version: 0.16.0.Source: cve.now feed data