CVE-2026-44519 · Package
NO FIX YET · SEE WHAT TO DO
liboqs, a C post-quantum cryptography library, has a missing value barrier in its FrodoKEM ct_select routine that Clang 17+ can compile into a secret-dependent memory access at -Os. A local attacker running repeated cache-timing measurements can use this as an oracle toward private-key recovery.
first public Nov 2, 2026 · 1 source
Check it with your coding agent
It checks your repository and tells you if you’re affected, with the fix.
Only builds that include liboqs FrodoKEM (AES or SHAKE variants) before 0.16.0, compiled with Clang 17 or later at an optimization level such as -Os. Default -O3 builds vectorize the affected loads and are reported as not exhibiting the behavior. Other liboqs KEMs named in the advisory are not reported as affected.
Not affected if default-o3-build, liboqs-0.16.0-or-later, no-frodokem
Who cares c, clang, liboqs, post-quantum
liboqs in your package manifest or oqs_version().-Os rather than the default -O3.0.16.0 or later.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.
Are you affected?
Tell InfraStack what you run. It checks this one, and every next one, against your stack.
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.