CVE-2025-52473: Openquantumsafe Liboqs Information Disclosure

CVE-2025-52473 Overview

CVE-2025-52473 is a side-channel vulnerability in liboqs, the C-language cryptographic library from the Open Quantum Safe project that implements post-quantum cryptography algorithms. The reference implementation of the Hamming Quasi-Cyclic (HQC) key encapsulation mechanism contains secret-dependent branches when compiled with Clang at optimization levels above -O0. A local attacker with the ability to observe execution behavior can leverage a proof-of-concept attack to recover the entire HQC private key. The issue is fixed in liboqs version 0.14.0.

Critical Impact
Local attackers can recover the full HQC secret key by exploiting timing differences introduced by Clang optimizations, breaking the confidentiality of the post-quantum key encapsulation mechanism.

Affected Products

Open Quantum Safe liboqs versions prior to 0.14.0
Applications linking the HQC reference implementation compiled with Clang at -O1, -O2, or higher
Downstream projects consuming liboqs for post-quantum KEM operations

Discovery Timeline

2025-07-10 - CVE-2025-52473 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-52473

Vulnerability Analysis

The flaw is a classic timing side-channel [CWE-200] in the HQC reference implementation. HQC is a code-based post-quantum key encapsulation mechanism (KEM) selected for standardization. Its reference C code was intended to execute in constant time to prevent secret-dependent behavior from leaking through microarchitectural observables.

When Clang compiles this reference code with optimization enabled (-O1 and above), the compiler introduces control-flow transformations that produce branches whose execution paths depend on secret key material. An attacker running local code on the same system can measure the timing variations produced by those branches and progressively recover the private key.

The scope is limited to confidentiality of the KEM secret; integrity and availability of the host are not directly affected. However, recovery of the HQC private key enables decryption of any ciphertext encapsulated to the victim's public key.

Root Cause

The reference implementation relied on source-level constant-time coding patterns without enforcing them at the compiled binary level. Clang's optimizer rewrote portions of the HQC code into conditional branches keyed on secret data, defeating the constant-time property. Because the vulnerability is created by the compiler rather than the source alone, it did not appear when the code was built at -O0.

Attack Vector

Exploitation requires local, low-privileged code execution on the target system, no user interaction, and observation of process execution timing. The proof-of-concept described in the advisory measures execution-time differences during HQC decapsulation to reconstruct the secret key.

text

// Patch: force the HQC 'clean' reference implementation to build at -O0
{%- if family == 'hqc' and impl['name'] == 'clean' %}
    target_compile_options({{ family }}_{{ scheme['scheme'] }}_{{ impl['name'] }} PRIVATE -O0)
{%- endif %}

// Patch: run constant-time tests against optimized release code
if(OQS_ENABLE_TEST_CONSTANT_TIME_OPTIMIZED)
    add_compile_options(-O3) # run constant-time tests on release code
endif()

Source: liboqs commit 4215362

Detection Methods for CVE-2025-52473

Indicators of Compromise

No network-level indicators exist; exploitation is local and passive from a defender's perspective.
Presence of liboqs shared or static libraries at versions earlier than 0.14.0 on production systems.
Applications built with Clang linking the HQC clean reference implementation without the -O0 override.

Detection Strategies

Inventory build artifacts and container images for the liboqs version string and the compiler used to build it.
Audit CMake build logs for HQC compilation units built with -O1 or higher when using Clang.
Correlate cryptographic library usage with local, unprivileged processes performing repeated HQC decapsulation operations.

Monitoring Recommendations

Monitor for anomalous local processes issuing high-frequency KEM operations against services that use liboqs.
Track software bill of materials (SBOM) entries referencing openquantumsafe:liboqs to surface vulnerable versions across the estate.
Alert on installation or loading of shared libraries whose hashes match pre-0.14.0liboqs builds.

How to Mitigate CVE-2025-52473

Immediate Actions Required

Upgrade liboqs to version 0.14.0 or later across all systems and rebuild dependent applications.
Rotate any HQC key pairs that were generated or used on systems running vulnerable, Clang-optimized builds.
Restrict local, untrusted code execution on hosts that perform HQC decapsulation until patched.

Patch Information

The fix is delivered in liboqs0.14.0. The upstream patch in commit 4215362acbf69b88fe1777c4c052f154e29f9897 forces the HQC clean reference implementation to be compiled with -O0 and enables constant-time testing against optimized release builds. Details are documented in the GitHub Security Advisory GHSA-qq3m-rq9v-jfgm.

Workarounds

Rebuild the HQC reference implementation with -O0 if immediate upgrade is not feasible.
Switch to a non-affected KEM algorithm supported by liboqs until the library can be updated.
Enforce strict process isolation so untrusted workloads cannot co-reside with processes performing HQC operations.

bash

# Force the HQC 'clean' implementation to build at -O0 in your CMake configuration
cmake -DCMAKE_C_COMPILER=clang \
      -DOQS_ENABLE_KEM_HQC=ON \
      -DCMAKE_C_FLAGS="-O2" \
      -DOQS_ENABLE_TEST_CONSTANT_TIME_OPTIMIZED=ON \
      ..

# Verify the installed liboqs version is 0.14.0 or later
pkg-config --modversion liboqs