Bouncy Castle for Java contains a side‑channel vulnerability that can expose the HQC private key through cache‑based and timing attacks. The flaw consists of two parts: the GF(2^8) arithmetic uses secret‑dependent lookup tables, causing cache line access patterns that reflect the key material; and the fixed‑weight sampler terminates early on a collision and stores positions at secret indices, creating observable timing behavior. An attacker who can measure cache accesses or encapsulation/decapsulation timing can recover portions of the private key, mapping to CWE‑208, Information Exposure.

Legion of the Bouncy Castle Inc. produces the BC-Java library. Any Java application that loads a version of BC-Java older than 1.86, and performs HQC encapsulation or decapsulation, is vulnerable. The vulnerability affects all deployments that include those operations before the 1.86 release, which removes the table‑based arithmetic and makes the sampler branch‑free.

The CVSS v3 score of 5.9 indicates moderate severity. EPSS is not available, so current exploit prevalence is unclear; the vulnerability is not yet listed in the CISA KEV catalog. Based on the description, it is inferred that exploitation requires an observer who can monitor cache behavior or measure execution timing, such as a local user or an attacker with shared hyper‑visor resources. Because the side channel depends on secret inputs during encapsulation and decapsulation, repeated operations are needed to accumulate enough data to reconstruct the key. Recovering private key material would represent a serious compromise of confidentiality.