Bouncy Castle Java EUVD-2026-92004

The target must actually use Bouncy Castle for Java's HQC post-quantum KEM (versions before 1.86) for encapsulation/decapsulation - this is the decisive prerequisite and sharply limits the exposed population, since HQC is a newly standardized algorithm with minimal production adoption. Exploitation additionally requires the attacker to observe microarchitectural cache behaviour (realistically via code co-resident on the same physical CPU/host, e.g. shared-tenancy environments) or to precisely measure decapsulation timing across many operations; the sampler re-expands the secret key from its seed on every decapsulation, which aids repeated measurement. Limiting factors per the CVSS 4.0 vector: local attack vector (AV:L), high attack complexity (AC:H), and a present-type attack requirement (AT:P) meaning many controlled measurements under specific conditions are needed; isolated single-tenant hardware largely neutralizes the cache channel.

This is a genuine cryptographic weakness but a comparatively low-urgency operational priority. The only CVSS vector supplied is CVSS 4.0 (5.9, Medium): AV:L/AC:H/AT:P/PR:N/UI:N with VC:H and VI/VA:N - meaning local vector, high attack complexity, a specific attack requirement (AT:P), no privileges or user interaction, and a confidentiality-only impact (HQC private-key recovery). CWE-208 (observable timing/microarchitectural discrepancy) is consistent with the description's two side channels (GF(2^8) table lookups creating operand-dependent cache-line access, plus a data-dependent fixed-weight sampler). No EPSS score, no CISA KEV listing, and no POC indicator are present in the input, so by the precision rules this is 'no public exploit identified at time of analysis.' The signals are internally consistent rather than conflicting: a local/high-complexity side channel yielding key disclosure legitimately lands in the Medium band and is NOT a mass-exploitation threat. The practical caveat is that side-channel severity is highly deployment-dependent - on shared-tenancy or co-resident hardware the cache channel is materially more realistic than the Medium score suggests, while on isolated single-tenant hosts it is largely theoretical. EPSS is absent (not low), so no probabilistic exploitation estimate can be asserted.

An attacker running co-resident code on the same physical host as a service that uses Bouncy Castle's HQC KEM (e.g. a shared cloud tenant or a local unprivileged process) observes cache-line access patterns during repeated decapsulations - each of which re-expands the secret key from its seed - and over many samples reconstructs information about the HQC private key. Alternatively, a remote-ish attacker who can precisely time many decapsulation operations exploits the sampler's early-exit/secret-indexed store to leak key-derived data. No public exploit code is identified at time of analysis, and the high attack complexity (AC:H/AT:P) reflects the many precise measurements required.