The Bouncy Castle for Java libraries validate OCSP stapling for TLS but do not bind the stapled OCSP response to the certificate that is being checked. This means an attacker can supply a stapled response that references a different certificate or an arbitrary validity period. As a result, the library may accept a forged response and believe the certificate is valid when it is not, allowing the attacker to impersonate the server or bypass revocation checks. This loss of trust can compromise confidentiality, integrity, and availability of TLS connections.

Affected vendors are Legion of the Bouncy Castle Inc. with products BC-FJA, BC-JAVA and BC-LTS-JAVA. The bug exists in Bouncy Castle for Java before version 1.85, Bouncy Castle for Java LTS before 2.73.12, and Bouncy Castle for Java FIPS (BC‑FJA) before bc‑fips 2.0.2 (2.0.X series) and 2.1.3 (2.1.X series).

The CVSS base score of 9.3 indicates a critical impact. The EPSS score is unavailable, so current data does not quantify the likelihood, but the lack of KEV inclusion suggests no publicly known active exploitation yet. Based on the description, the likely attack vector is over the network during a TLS handshake where a client or server presents a stapled OCSP response that the library blindly accepts. An attacker who can modify the stapled response would need to intercept or control the TLS traffic. Once the library accepts the forged response, the attacker can impersonate the server or bypass revocation, enabling man‑in‑the‑middle attacks or certificate forgery.