CVE-2026-18040: Bouncy Castle HQC Information Disclosure

CVE-2026-18040 is an information disclosure vulnerability in Bouncy Castle for Java affecting HQC implementation through side-channel attacks. Attackers can recover private key data via cache timing. This article covers technical details, affected versions, impact analysis, and mitigation strategies.

CVE-2026-18040 Overview

CVE-2026-18040 affects Bouncy Castle for Java versions before 1.86. The flaw exposes secret-derived data in the Hamming Quasi-Cyclic (HQC) post-quantum key encapsulation mechanism through two distinct side channels. The GF(2^8) field arithmetic uses lookup tables indexed by field elements, producing cache-line access patterns that depend on secret operands. Separately, the fixed-weight support sampler exits its duplicate scan early on collision and writes accepted positions at secret-dependent indices. An attacker able to observe cache behavior or decapsulation timing can recover information about the HQC private key.

Critical Impact
An attacker with local observation capability can recover HQC private key material by analyzing cache access patterns or decapsulation timing variations.

Affected Products

Bouncy Castle for Java versions prior to 1.86
Applications using HQC encapsulation or decapsulation via Bouncy Castle
Systems where the HQC seed is re-expanded on every decapsulation

Discovery Timeline

2026-10-03 - CVE-2026-18040 published to NVD
2026-10-06 - Last updated in NVD database

Technical Details for CVE-2026-18040

Vulnerability Analysis

The vulnerability is a side-channel information disclosure [CWE-208] in the HQC post-quantum KEM implementation. HQC is a code-based key encapsulation mechanism that relies on arithmetic over GF(2^8) and sampling of fixed-weight vectors. Both primitives in Bouncy Castle's pre-1.86 implementation execute on secret-derived inputs during encapsulation and decapsulation.

The GF(2^8) arithmetic uses precomputed lookup tables indexed directly by field elements. The cache line touched during each table access reveals the operand value to an attacker who can observe cache behavior through techniques such as Flush+Reload or Prime+Probe.

The fixed-weight support sampler compounds the exposure. It terminates its duplicate-detection scan immediately upon finding a collision and writes accepted positions at a secret index. Because the sampler re-expands the private key from its seed on each decapsulation, repeated observations give an attacker many measurement opportunities against the same key.

Root Cause

The root cause is non-constant-time implementation of cryptographic primitives operating on secret data. Table-indexed arithmetic produces operand-dependent cache footprints, and early-exit control flow combined with secret-indexed memory writes produces operand-dependent timing. Together these violate the constant-time requirement for secret-handling cryptographic code.

Attack Vector

Exploitation requires local access to observe microarchitectural state or precise decapsulation timing. A co-resident process, a malicious container on shared hardware, or a local user running cache-monitoring code can collect side-channel traces across many decapsulation operations. Analysis of the collected cache or timing data allows reconstruction of secret-dependent values that reduce the search space for the HQC private key.

No arbitrary code execution or network vector is involved. See the Bouncy Castle CVE-2026-18040 wiki entry and the upstream fix commit for implementation detail.

Detection Methods for CVE-2026-18040

Indicators of Compromise

No reliable host-based indicators exist; side-channel observation leaves no artifact in application logs or standard telemetry.
Presence of Bouncy Castle Java library versions earlier than 1.86 in application dependencies.
Workloads performing HQC decapsulation on shared or multi-tenant hardware without microarchitectural isolation.

Detection Strategies

Inventory Java application dependencies using software composition analysis to locate bcprov and related Bouncy Castle artifacts below version 1.86.
Audit cryptographic configurations for use of HQC provided through Bouncy Castle, including both encapsulation and decapsulation code paths.
Review deployment topology for co-tenancy on shared CPUs where cache-based side-channel observation is feasible.

Monitoring Recommendations

Track process-level access to shared cache resources on hosts handling HQC key material.
Alert on new unprivileged processes running on hosts that perform HQC decapsulation.
Use runtime workload protection to flag anomalous co-resident processes on cryptographic workloads.

How to Mitigate CVE-2026-18040

Immediate Actions Required

Upgrade Bouncy Castle for Java to version 1.86 or later across all affected applications.
Rotate any HQC private keys that were used by vulnerable versions on shared or untrusted hardware.
Restrict co-tenancy for workloads that perform HQC decapsulation until patching is complete.

Patch Information

Bouncy Castle 1.86 replaces the GF(2^8) arithmetic with a table-free implementation and restructures the fixed-weight sampler to be branch-free within a batch of candidates. Output values and randomness consumption remain unchanged. Review the upstream commit 283acd8 for the full code change.

Workarounds

Disable use of HQC in applications relying on vulnerable Bouncy Castle versions and fall back to an alternative post-quantum KEM where appropriate.
Isolate HQC decapsulation workloads to dedicated hardware or dedicated virtual machines with no untrusted co-tenants.
Limit local access to systems handling HQC private keys to reduce opportunities for cache or timing observation.

bash

# Verify Bouncy Castle version in a Maven project
mvn dependency:tree | grep -i bcprov

# Example dependency pin to the patched release
# pom.xml
# <dependency>
#   <groupId>org.bouncycastle</groupId>
#   <artifactId>bcprov-jdk18on</artifactId>
#   <version>1.86</version>
# </dependency>