CVE-2026-71889: Bouncy Castle Information Disclosure Flaw

CVE-2026-71889 Overview

CVE-2026-71889 is a certificate validation flaw [CWE-295] in Bouncy Castle for Java affecting both org.bouncycastle.pkix.jcajce.PKIXCertPathReviewer and the legacy org.bouncycastle.x509.PKIXCertPathReviewer. The reviewer failed to apply X.509 name constraints to the end-entity certificate, meaning a leaf certificate that violated a NameConstraints extension imposed by its issuing CA was still reported as valid. Applications that relied on the reviewer for trust decisions accepted certificates the constrained CA was never authorised to issue.

Critical Impact
A subordinate CA restricted by name constraints can issue certificates for domains outside its permitted subtree, and the Bouncy Castle reviewer will accept them. This enables impersonation of arbitrary hosts when the reviewer is used as the trust decision point.

Affected Products

Bouncy Castle for Java before 1.86
Bouncy Castle for Java LTS before 2.73.13
Bouncy Castle for Java FIPS (BC-FJA) bcpkix-fips before 1.0.13, 2.0.13, and 2.1.13

Discovery Timeline

2026-10-03 - CVE-2026-71889 published to NVD
2026-10-06 - Last updated in NVD database

Technical Details for CVE-2026-71889

Vulnerability Analysis

The vulnerability lives in the checkNameConstraints routine of both PKIXCertPathReviewer implementations. The method walked the certificate path with a loop bound of index > 0, which is the correct bound for CA-only steps that accumulate constraints. Under the standard CertPath ordering, however, index zero is the target (end-entity) certificate, so the subtree checks required by RFC 5280 sections 6.1.3 (b) and (c) never executed against the leaf's subject Distinguished Name or its subjectAltName.

As a result, isValidCertPath() returned true with an empty error list for chains whose leaf violated a NameConstraints extension imposed by its own issuing CA. The behaviour diverged from CertPathValidator.getInstance("PKIX", "BC"), which shares no code with the reviewer and correctly rejected the same chain against the same trust anchor.

Root Cause

The loop termination condition index > 0 excluded the target certificate from the permitted and excluded subtree evaluation. The reviewer treated the final certificate as if it were only subject to the section 6.1.4 constraint-accumulation step, which skips the leaf by design, rather than also applying the section 6.1.3 wrap-up checks.

Attack Vector

An attacker who controls a subordinate CA constrained to a specific DNS namespace, or who obtains a certificate from such a CA, can present a leaf certificate for a name outside the permitted subtree. Any Java application that uses PKIXCertPathReviewer to make the trust decision for TLS, S/MIME, code signing, or client authentication will accept the forged chain. The attack vector is network-reachable and requires no authentication or user interaction.

java

         }
 
         //
-        // process each certificate except the last in the path
+        // process each certificate in the path, target certificate included
         //
         int index;
         int i;
-        
-        try 
+
+        try
         {
-            for (index = certs.size()-1; index>0; index--) 
+            for (index = certs.size()-1; index>=0; index--)
             {
                 i = n - index;
                 //
                 // certificate processing
                 //
                 cert = (X509Certificate) certs.get(index);
                 // b),c)

Source: Bouncy Castle commit 06dcff2f5103 — the patch changes the loop bound from index>0 to index>=0 so the target certificate is included in the subtree checks.

Detection Methods for CVE-2026-71889

Indicators of Compromise

Divergent validation outcomes between PKIXCertPathReviewer.isValidCertPath() and CertPathValidator.getInstance("PKIX", "BC") for identical chains and trust anchors.
TLS or S/MIME sessions terminating against certificates whose subject DN or subjectAltName falls outside the issuing CA's declared permittedSubtrees.
Chains in which an intermediate CA carries a NameConstraints extension that the presented leaf does not satisfy.

Detection Strategies

Perform a dependency inventory to identify Java applications bundling bcprov, bcpkix, bcprov-lts8on, bcpkix-lts8on, or any bcpkix-fips artifact below the patched versions.
Run both the reviewer and CertPathValidator across your certificate corpus and alert on cases where only the reviewer accepts the chain.
Audit source code for direct references to PKIXCertPathReviewer and flag any instance where its result drives a trust decision rather than diagnostic reporting.

Monitoring Recommendations

Log the full issuing chain and the resolved NameConstraints for every TLS session validated by Bouncy Castle.
Monitor certificate transparency feeds for certificates issued by constrained subordinate CAs that step outside their permitted namespace.
Alert when applications upgrade or downgrade Bouncy Castle versions, and verify that the deployed artifact matches the patched release.

How to Mitigate CVE-2026-71889

Immediate Actions Required

Upgrade Bouncy Castle for Java to 1.86 or later, Bouncy Castle for Java LTS to 2.73.13 or later, and BC-FJA bcpkix-fips to 1.0.13, 2.0.13, or 2.1.13 depending on the series in use.
Replace any trust decisions made with PKIXCertPathReviewer with calls to CertPathValidator.getInstance("PKIX", "BC") until patched libraries are deployed.
Audit internal and partner PKIs for constrained subordinate CAs and rotate any certificate suspected of exploiting the gap.

Patch Information

The fix is published in Bouncy Castle commit 06dcff2f5103. Both reviewer copies now iterate every certificate in the path including the target, waive the RFC 5280 section 4.2.1.10 self-issued exemption for the final certificate as section 6.1.3 requires, and skip the section 6.1.4 (g) constraint-accumulation step for the target. Refer to the CVE-2026-71889 wiki entry for upgrade guidance.

Workarounds

Use PKIXCertPathReviewer only for diagnostic output alongside a trust decision made by CertPathValidator.
Remove or disable code paths that treat isValidCertPath() as authoritative for TLS, S/MIME, or code signing acceptance.
Where feasible, pin trust to specific leaf certificates or public keys until the patched Bouncy Castle release is in production.

bash

# Maven dependency upgrade example
mvn versions:use-dep-version -Dincludes=org.bouncycastle:bcpkix-jdk18on -DdepVersion=1.86 -DforceVersion=true
mvn versions:use-dep-version -Dincludes=org.bouncycastle:bcprov-jdk18on -DdepVersion=1.86 -DforceVersion=true