Three functions in the ML‑KEM (Kyber) routines of Bouncy Castle for Java perform non‑constant‑time division of secret‑derived polynomial coefficients by the modulus q. When an attacker can measure the time taken for many decapsulations using the same privately held key, the leaked timing differences enable reconstruction of the private key. This vulnerability does not directly give code execution or denial of service; its primary impact is the loss of cryptographic confidentiality through key exposure. Based on the description, the likelihood of key extraction is inferred from the specified need to observe timing across multiple decapsulations.

Bouncy Castle Java libraries from version 1.73 up to, but not including, 1.78 are affected. The vulnerability occurs in the Poly.toMsg, Poly.compressPoly, and PolyVec.compressPolyVec routines used in ML‑KEM (CRYSTALS‑Kyber) implementations. Applications that rely on these libraries for secure key encapsulation and decapsulation should be reviewed to determine whether they have the vulnerable code paths. The affected systems are inferred to be any Java applications employing these specific Bouncy Castle library versions.

The CVSS score of 8.2 indicates severe risk, while the EPSS score of less than 1% suggests that exploitation is currently unlikely, though possible if an attacker gains access to an environment where many decapsulations can be measured. The vulnerability is not listed in the CISA KEV catalog. The attacker must control or closely observe the environment performing decapsulations to collect timing data, making the attack likely to rely on a covert side‑channel from a dedicated server or compromised client that performs large numbers of decapsulations. Based on the description, the likely attack vector requires an adversary who can measure the timing of many decapsulations performed with the same private key, and the inference about low exploitation likelihood is drawn from the EPSS value.