Vulnerabilities

In Bouncy Castle for Java before 1.85, Name Constraints bypass via trailing dot in rfc822Name and URI. This issue also affects Bouncy Castle for Java LTS before 2.73.12, and Bouncy Castle for Java FIPS (BC-FJA) before bc-fips 1.0.2.7 (1.0.X series), 2.0.2 (2.0.X series) and 2.1.3 (2.1.X series).

Bouncy Castle for Java versions 1.73 through before 1.78 has an observable timing discrepancy (CWE-208) — the KyberSlash1 and KyberSlash2 flaws — in its ML-KEM (CRYSTALS-Kyber) routines Poly.toMsg, Poly.compressPoly, and PolyVec.compressPolyVec, which divide secret-derived polynomial coefficients by the modulus q. An attacker who can initiate or observe a large number of ML-KEM decapsulation operations performed with the same long-term private key and measure their timing can use the secret-dependent division timing to recover that key. Key recovery defeats the confidentiality of the post-quantum key exchange (CVSS 4.0 rates this 8.2 High with high attack complexity and High confidentiality impact); encapsulation-side compression is unaffected because it only operates on values that become the public ciphertext. Any application or service using affected bc-java releases for ML-KEM/Kyber decapsulation is affected, particularly deployments that reuse static ML-KEM keys across many exchanges. No in-the-wild exploitation is known (EPSS 0.3%, not in CISA KEV), but public proof-of-concept timing attacks are published at kyberslash.cr.yp.to.

Do: Upgrade Bouncy Castle for Java to 1.78 or later, which removes the secret-dependent divisions in the ML-KEM routines. Inventory applications bundling bc-java jars in the 1.73–1.77 range and prioritize those performing ML-KEM/Kyber decapsulation with long-term (reused) keys, rotating such keys after patching. Where an immediate upgrade is not possible, treat high-volume, network-observable ML-KEM decapsulation paths as the highest risk.