Cloudanix VulnDB

CVE-2026-18040

None

CVSS

—

EPSS

0.1%

Published

Oct 3, 2026

CISA due date

—

Cloudanix analysis

Monitor only SSVC: Track

A programming library used for advanced encryption in Java applications could leak secret keys through subtle timing and memory-access patterns, allowing a nearby attacker to steal the keys if the software is not updated.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
High
Impact
Data Exposure
Component
Library
Class
Cryptographic Weakness
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

HQC implementation in Bouncy Castle leaks secret-derived data via cache-line access patterns in GF(2^8) table lookups and via early-exit timing in the fixed-weight sampler during encapsulation and decapsulation; the sampler also re-expands the private key from its seed on every decapsulation.

Why it matters to the business

Organizations relying on HQC-based post-quantum cryptography in Java applications face risk of private-key recovery by an attacker who can measure cache behavior or decapsulation timing, undermining long-term cryptographic assurances.

How an attack unfolds

An attacker with the ability to observe CPU cache activity or precise timing on the same host runs chosen encapsulation or repeated decapsulation operations; by correlating cache-line touches or variable execution time with the secret inputs, the attacker gradually extracts information about the HQC private key.

How to fix it

Upgrade Bouncy Castle for Java to version 1.86 or later, which replaces table-based field arithmetic with constant-time implementations and makes the sampler branch-free within candidate batches.

How to confirm the fix worked

Confirm the Bouncy Castle JAR or dependency version is 1.86 or newer; run the library's self-tests and any available side-channel test vectors to verify the HQC implementation no longer exhibits the described leakage.

Typical attack path

  1. Gain local or co-located execution on a system performing HQC operations
  2. Trigger or observe encapsulation and decapsulation calls that use the target private key
  3. Measure cache-line accesses or decapsulation latency across many operations
  4. Correlate side-channel observations with secret-dependent data to reconstruct private-key material

How to detect it

Review application logs, dependency manifests, and runtime class paths for Bouncy Castle versions older than 1.86; no network or file-based indicators of active exploitation are known because the attack requires local observation of cache or timing.

What your security team should do

  • Inventory all Java applications and libraries that depend on Bouncy Castle and flag any version prior to 1.86
  • Prioritize upgrade of any deployment that uses HQC key encapsulation
  • Treat the 30-day-old disclosure as a moderate-urgency patching task given the local-attack requirement and absence from KEV

The record

In Bouncy Castle for Java before 1.86, HQC leaked secret-derived data through two side channels: its GF(2^8) arithmetic used lookup tables indexed by field elements, making the cache line touched a function of the operand, and its fixed-weight support sampler left its duplicate scan as soon as a collision was found and stored accepted positions at a secret index. Both run on secret inputs during encapsulation and decapsulation, and the sampler re-expands the secret key from its seed on every decapsulation, so an attacker able to observe cache behaviour or decapsulation timing can recover information about the HQC private key. The field arithmetic is now table-free and the sampler branch-free within a batch of candidates, with output and randomness consumption unchanged.

Affected packages

Ecosystem Package Introduced Fixed

Related vulnerabilities