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.
History

Fri, 06 Nov 2026 23:00:00 +0000

Type Values Removed Values Added
First Time appeared Open Quantum Safe
Open Quantum Safe liboqs
Vendors & Products Open Quantum Safe
Open Quantum Safe liboqs

Fri, 06 Nov 2026 21:30:00 +0000

Type Values Removed Values Added
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.
Title liboqs: Missing value barrier in FO implicit rejection path (FrodoKEM, NTRU, and others)
Weaknesses CWE-385
References
Metrics cvssV3_1

{'score': 5.1, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N'}


cve-icon MITRE

Status: PUBLISHED

Assigner: GitHub_M

Published: 2026-11-06T21:22:27.624Z

Updated: 2026-11-06T21:22:27.624Z

Reserved: 2026-05-06T18:28:20.888Z

Link: CVE-2026-44519

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-11-06T22:17:51.403

Modified: 2026-11-06T22:17:51.403

Link: CVE-2026-44519

cve-icon Redhat

No data.