CVE‐2026‐58062

Title: Stapled OCSP response accepted without binding to the checked certificate.

Issue affecting: BC before 1.85 (from 1.66), BC-LTS before 2.73.12, BC-FJA before bc-fips 2.0.2 and 2.1.3.

Fixed versions: BC 1.85, BC-LTS 2.73.12, BC-FJA bc-fips 2.0.2 and 2.1.3.

Platform affected: Java 8 and later.

In Bouncy Castle's ProvOcspRevocationChecker, when an OCSP response is supplied via PKIXRevocationChecker.setOcspResponses() (the stapled path), check() verifies the response signature and then loops over SingleResponse entries looking for a CertID match. If no entry matches the certificate's serial and issuer hashes, the loop simply completes and the method returns without throwing, so the certificate is treated as not revoked and no CRL fallback occurs. The network-fetch path enforces this binding via OcspCache.isCertIDFoundAndCurrent(), but the stapled path omits it. A TLS server with a revoked certificate can staple any legitimately-signed OCSP response from the same CA (e.g., a 'good' response for a different serial) and pass revocation checking on a BC-based client.

The fix was introduced in commit add5f822660f.