# CVE-2026-44519: Open Quantum Safe liboqs FrodoKEM cache timing in ct_select

Source: https://junglewise.ai/threats/cve-2026-44519-liboqs-is-a-c-language-cryptographic-library-that-provides  
Publisher: Junglewise Threat Intelligence, https://junglewise.ai/threats  
Published: 2026-11-06. Updated: 2026-11-06  
License: CC BY 4.0 with a link back

CVE-2026-44519 · Severity: medium · CVSS 5.1 · Published 2026-11-06

liboqs is a cryptographic library implementing post-quantum cryptography algorithms including FrodoKEM. When compiled with Clang 17 or later at certain optimization levels, the FrodoKEM decapsulation function contains a secret-dependent memory access pattern that leaks information about whether decryption succeeded or failed via CPU cache timing. A local attacker with repeated measurement access could potentially recover the private key through this timing side channel.

Technologies: [Open Quantum Safe Liboqs](https://junglewise.ai/threats/technologies/liboqs). Vendors: [Open Quantum Safe](https://junglewise.ai/threats/vendors/open-quantum-safe).

## Quick answers

**Is CVE-2026-44519 exploited in the wild?** No. Junglewise Threat Intelligence has no report of CVE-2026-44519 being exploited in the wild.

**How severe is CVE-2026-44519?** Medium severity, with a CVSS score of 5.1, published 6 November 2026.

**Which products and versions are affected?** Open Quantum Safe Liboqs before 0.16.0.

**Is there a fix for CVE-2026-44519?** Yes: fixed in 0.16.0. Junglewise finds every place you run it, drafts the upgrade and applies it once you approve.

**How is CVE-2026-44519 attacked?** It is attacked with local access, in a software library.

**Am I affected by CVE-2026-44519?** Check whether you run Open Quantum Safe Liboqs at an affected version. Junglewise does that check for you around the clock: connect your code, cloud and domains, and it matches new vulnerabilities like this one against what you actually run and tells you when one reaches you.

## How to fix

- Fixed in 0.16.0

## Technical details

The ct_select function in src/kem/frodokem/external/util.c lacks a value barrier in the Fujisaki-Okamoto rejection sampling path, allowing Clang 17+ to emit a secret-dependent conditional load at optimization levels like -Os. This creates observable cache residency differences between successful and failed decapsulation paths, exploitable via cache-timing side-channel attacks. The issue is fixed by adding an OQS_MEM_BLACK_BOX optimization barrier to prevent compiler optimization that would expose the secret-dependent branch.

## Affected products

- Open Quantum Safe liboqs before 0.16.0

## Timeline

- 2026-11-06: disclosed

## References

- [https://github.com/open-quantum-safe/liboqs/commit/d95fc734f5de9bdfc80c8c65d8166b30e9cff5cd](https://github.com/open-quantum-safe/liboqs/commit/d95fc734f5de9bdfc80c8c65d8166b30e9cff5cd)
- [https://github.com/open-quantum-safe/liboqs/pull/2431](https://github.com/open-quantum-safe/liboqs/pull/2431)

## Related threats

- [liboqs uninitialized pointer dereference in NTRU KEM encaps_derand](https://junglewise.ai/threats/cve-2026-47738-liboqs-is-a-c-language-cryptographic-library-that-provides)
- [liboqs out-of-bounds read in HSS/LMS signature verification](https://junglewise.ai/threats/cve-2026-104254-liboqs-is-a-c-language-cryptographic-library-that-provides)
- [Open Quantum Safe liboqs out-of-bounds read in XMSS verification](https://junglewise.ai/threats/cve-2026-46344-open-quantum-safe-liboqs-out-of-bounds-read-in-xmss-verification)
- [open-quantum-safe liboqs out-of-bounds read in XMSS verification](https://junglewise.ai/threats/cve-2026-44518-open-quantum-safe-liboqs-out-of-bounds-read-in-xmss-verification)