Bouncy Castle CVE-2026-58062

Exploitation requires that the relying application performs OCSP revocation checking through Bouncy Castle's PKIXRevocationChecker and consumes a stapled/supplied OCSP response (via setOcspResponses) or an AIA-fetched response (itself gated behind the ocsp.enable security property, disabled by default in BC). The attacker must present a certificate whose revocation status would otherwise be caught, together with a validly-signed OCSP response bound to a DIFFERENT CertID than the checked certificate. Limiting factors: it does not affect applications that skip OCSP or enforce CRL-only checking; the AIA network-fetch path is off unless ocsp.enable=true; and the attacker needs a legitimately-signed OCSP response (e.g. any 'good' response from the responder covering another serial). This is a control-bypass rather than a no-precondition remote compromise, so it is not exploitable against arbitrary default deployments without OCSP-stapling reliance.

Signals are mixed and warrant careful interpretation. The vendor CVSS 4.0 score is 9.3 (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N) with a U:Amber caveat, implying trivially remote, unauthenticated, high-impact exploitation - but the description and source evidence show this is a revocation-enforcement bypass, not direct code execution or data theft. Real-world exploitation requires the attacker to already possess or present a certificate that would otherwise be caught as revoked, plus a relying application that uses PKIXRevocationChecker with stapled/supplied OCSP responses; this is closer to AC:H than AC:L in practice, so the 9.3 likely overstates ease of attack. No EPSS score is provided, the CVE is not in CISA KEV, and no POC beyond the vendor's regression test is referenced, so this is not evidence of active, widespread exploitation. Nonetheless the impact class is serious: silently accepting revoked certificates undermines a core TLS/PKI control and can enable man-in-the-middle interception with a revoked-but-valid-looking cert. Net assessment: high-priority patch for anyone using Bouncy Castle OCSP revocation checking, but the headline 9.3 should be read as an upper bound - the practical prerequisites make it targeted rather than mass-exploitable.

An attacker holding a certificate that has been revoked (for example after a stolen private key) positions themselves as a TLS peer or MITM and staples a validly-signed OCSP 'good' response that actually covers a different certificate's serial (such as the CA's). A relying Java application using vulnerable Bouncy Castle OCSP revocation checking accepts the mismatched response as proof the presented certificate is not revoked, and the connection is trusted despite the revocation. No public exploit is identified beyond the vendor's regression test.