CVE-2026-44519: Security vulnerability
liboqs is a C-language cryptographic library that provides implementations of post-quantum cryptography algorithms. Prior to 0.16.0, the ctselect 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.
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
liboqsto a version that resolves this vulnerability.Fixed in 0.16.0
Event History
Frequently Asked Questions
Which deployments are realistically exposed?
The reported condition is limited to FrodoKEM-640, FrodoKEM-976, and FrodoKEM-1344 AES and SHAKE reference variants in liboqs versions before 0.16.0, when compiled with Clang 17 or later at an affected optimization level such as -Os. Default -O3 builds do not exhibit the reported behavior.
What does an attacker need to exploit this issue?
An attacker needs local access sufficient to perform repeated cache-timing measurements during decapsulation. The distinguishable cache residency between successful and failed decapsulation can provide an oracle for a private-key recovery attack.
Are other liboqs algorithm implementations reported to have the same generated memory-access pattern?
No. The advisory does not report the same pattern in NTRU, NTRU-Prime, BIKE, HQC, Classic McEliece, Kyber, or the already-barriered ML-KEM implementation.
What should be done if the affected FrodoKEM reference variants are in use?
Update liboqs to version 0.16.0, which fixes the issue. If immediate updating is not possible, avoid affected Clang 17-or-later builds and affected optimization levels such as -Os for the listed FrodoKEM reference variants; the advisory states that default -O3 builds do not show the reported behavior.