CVE-2026-58062: Bouncy Castle Auth Bypass Vulnerability

CVE-2026-58062 Overview

CVE-2026-58062 is an improper certificate validation flaw [CWE-295] in Bouncy Castle for Java. The ProvOcspRevocationChecker accepts stapled Online Certificate Status Protocol (OCSP) responses without verifying they are bound to the certificate under validation. An attacker can present a signed but unrelated OCSP response, such as a good status for a different serial from the same Certificate Authority (CA), and have it treated as valid evidence for the target certificate. This breaks the revocation-checking guarantees that TLS clients and PKI validators rely on.

Critical Impact
Attackers can bypass OCSP-based revocation checks in TLS and PKI validation flows, enabling continued use of certificates that should be treated as unverified or revoked.

Affected Products

Bouncy Castle for Java before 1.85
Bouncy Castle for Java LTS before 2.73.12
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)

Discovery Timeline

2026-08-03 - CVE-2026-58062 published to the National Vulnerability Database (NVD)
2026-08-04 - Last updated in NVD database

Technical Details for CVE-2026-58062

Vulnerability Analysis

Bouncy Castle is a widely deployed cryptography library for Java, providing TLS, PKI, and OCSP primitives. The vulnerability sits in the OCSP stapling validation path inside ProvOcspRevocationChecker, which processes OCSP responses delivered inline during TLS handshakes.

When a peer staples an OCSP response, the checker iterates through the SingleResponse entries looking for one that matches the certificate's CertID. In the vulnerable code path, if no SingleResponse matches the target certificate but the OCSP response is otherwise well-formed and signed, the checker returns without raising a validation error. The result is that a signed but unrelated OCSP response satisfies revocation checking for a certificate it never covered.

Root Cause

The root cause is missing binding enforcement between the stapled OCSP SingleResponse and the certificate being validated. The network-fetch path enforces this in OcspCache.isCertIDFoundAndCurrent, but the stapling path did not apply the equivalent check, producing inconsistent behavior across revocation sources.

Attack Vector

An attacker positioned as a TLS server, or capable of injecting stapled OCSP data into a TLS handshake, presents a good OCSP response issued by the same CA but for a different certificate serial. The Bouncy Castle client accepts the response as authoritative for the presented certificate, suppressing the revocation check and allowing use of a revoked or unverified certificate.

java

                                     }
                                 }
                             }
+
+                            // Reaching here means no SingleResponse was bound to this certificate's
+                            // CertID (any full match returns or throws above). A signed-but-unrelated
+                            // stapled response - e.g. a 'good' status for a different serial from the
+                            // same CA - must not be treated as evidence that THIS certificate is good;
+                            // fail recoverably so CRL fallback can run, matching the network-fetch
+                            // path's OcspCache.isCertIDFoundAndCurrent enforcement.
+                            throw new RecoverableCertPathValidatorException(
+                                "no OCSP response found for certificate", null, parameters.getCertPath(), parameters.getIndex());
                         }
                         catch (CertPathValidatorException e)
                         {

Source: Bouncy Castle patch commit add5f82. The patch adds an explicit RecoverableCertPathValidatorException when no SingleResponse binds to the target certificate, forcing fallback to Certificate Revocation List (CRL) checks.

Detection Methods for CVE-2026-58062

Indicators of Compromise

TLS sessions where a stapled OCSP response's SingleResponseCertID does not match the served certificate's serial or issuer key hash.
OCSP responses accepted by Java applications with serials that do not appear in the presented certificate chain.
Continued acceptance of certificates known to be revoked by the issuing CA when validated by Java services using vulnerable Bouncy Castle versions.

Detection Strategies

Inventory Java applications and identify Bouncy Castle versions with mvn dependency:tree or gradle dependencies and flag builds pinned below 1.85, 2.73.12, or the affected FIPS releases.
Inspect TLS handshake captures at the network edge and correlate stapled OCSP CertID values against the certificate serial being negotiated.
Add software composition analysis (SCA) rules for the org.bouncycastle:bcprov-jdk18on, bcprov-lts8on, and bc-fips coordinates matching the vulnerable version ranges.

Monitoring Recommendations

Alert on Java processes loading vulnerable Bouncy Castle JARs, tracked via file-hash or package inventory telemetry.
Monitor outbound TLS connections from Java workloads for certificate acceptance despite failed CRL fetches, which may indicate the stapling path was used.
Log and review OCSP stapling events in reverse proxies and mutual TLS gateways to correlate certificate serials with returned OCSP statuses.

How to Mitigate CVE-2026-58062

Immediate Actions Required

Upgrade Bouncy Castle for Java to 1.85 or later, Bouncy Castle for Java LTS to 2.73.12 or later, and BC-FJA to 2.0.2 (2.0.X) or 2.1.3 (2.1.X) or later.
Rebuild and redeploy all Java applications, shaded JARs, and container images that embed Bouncy Castle to ensure the patched classes are actually loaded at runtime.
Audit trust stores and revocation-check configurations to confirm CRL fallback is enabled where OCSP stapling is used.

Patch Information

The fix is committed to the bc-java repository in commit add5f82. The patch throws a RecoverableCertPathValidatorException when no stapled SingleResponse binds to the certificate under test, aligning stapling behavior with the network-fetch path enforced by OcspCache.isCertIDFoundAndCurrent. See the Bouncy Castle CVE-2026-58062 wiki entry for vendor guidance.

Workarounds

Disable OCSP stapling consumption in affected Java applications and rely on CRL-based revocation checking until upgrades are deployed.
Set -Dcom.sun.net.ssl.checkRevocation=true together with CRL distribution point (CRLDP) checks so that validation does not depend solely on stapled OCSP responses.
Enforce short-lived certificates and strict certificate pinning at high-value endpoints to reduce the value of any bypassed revocation check.

bash

# Configuration example: enable CRL fallback and disable reliance on stapled OCSP in a Java service
java \
  -Dcom.sun.net.ssl.checkRevocation=true \
  -Dcom.sun.security.enableCRLDP=true \
  -Djdk.tls.stapling.responseTimeout=0 \
  -Dcom.sun.net.ssl.trustStoreType=PKCS12 \
  -jar your-application.jar