CVE-2026-71889 in BC-JAVA
Summary
by MITRE • 10/03/2026
In Bouncy Castle for Java before 1.86, neither copy of PKIXCertPathReviewer - org.bouncycastle.pkix.jcajce.PKIXCertPathReviewer nor the legacy org.bouncycastle.x509.PKIXCertPathReviewer - applied X.509 name constraints to the end-entity certificate. checkNameConstraints walked the path with a loop bound of index greater than zero, which is the bound the CA-only steps require, but index zero is the target certificate under the standard CertPath ordering, so the permitted and excluded subtree checks of RFC 5280 sec. 6.1.3 (b) and (c) never ran against the leaf's subject DN or its subjectAltName. A chain whose leaf violated a NameConstraints extension imposed by its own issuing CA therefore reported isValidCertPath() true with an empty error list, while CertPathValidator.getInstance("PKIX", "BC"), which shares no code with the reviewer, rejected the identical chain against the identical trust anchor. An application using the reviewer to make the trust decision rather than for diagnostics alongside a real validation accepted a certificate the constrained CA was never authorised to issue. Both copies now check every certificate in the path including the target, waive the sec. 4.2.1.10 self-issued exemption for the final certificate as sec. 6.1.3 requires, and skip the sec. 6.1.4 (g) constraint-accumulation step for the target. This issue also affects Bouncy Castle for Java LTS before 2.73.13, which carries only the org.bouncycastle.pkix.jcajce copy of the reviewer. It also affects Bouncy Castle for Java FIPS (BC-FJA) before bcpkix-fips 1.0.13 (1.0.X series), 2.0.13 (2.0.X series) and 2.1.13 (2.1.X series).
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/03/2026
The vulnerability identified in Bouncy Castle for Java prior to version 1.86, as well as in the LTS branch before 2.73.13 and various FIPS-compliant releases, represents a critical failure in X.509 certificate path validation logic within the PKIXCertPathReviewer utility class. This flaw affects both the legacy implementation located at org.bouncycastle.x509.PKIXCertPathReviewer and its modern counterpart at org.bouncycastle.pkix.jcajce.PKIXCertPathReviewer. The core technical deficiency lies in how these classes process name constraints, which are security extensions defined in RFC 5280 that restrict the domains or network addresses for which a Certificate Authority is authorized to issue certificates. Specifically, the internal method checkNameConstraints utilized a loop structure with an index bound greater than zero when iterating through the certificate chain. This indexing logic inadvertently excluded the end-entity or leaf certificate from validation checks because standard CertPath ordering places the target certificate at index zero. Consequently, the permitted and excluded subtree checks mandated by RFC 5280 sections 6.1.3(b) and (c) were never executed against the subject distinguished name or subject alternative names of the leaf certificate.
This implementation error results in a significant divergence between the behavior of PKIXCertPathReviewer and the standard Java Cryptography Architecture validation provider CertPathValidator.getInstance("PKIX", "BC"). While the latter correctly rejects chains where the end-entity violates name constraints imposed by its issuing CA, the vulnerable reviewer incorrectly reports such paths as valid with an empty error list. This discrepancy creates a severe security risk for applications that rely on PKIXCertPathReviewer to make trust decisions rather than using it solely for diagnostic purposes alongside a robust validation engine. An attacker could exploit this flaw by presenting a certificate chain where the end-entity violates name constraints, thereby gaining unauthorized access or impersonating services under domains not permitted by the CA's policy. The vulnerability effectively bypasses a fundamental control mechanism designed to limit the scope of trust delegated to intermediate Certificate Authorities, allowing certificates issued outside their authorized boundaries to be accepted as valid.
The issue is classified under CWE-295 Improper Certification Path Validation and aligns with MITRE ATT&CK techniques related to certificate manipulation or abuse of trusted entities for initial access or lateral movement in networked environments. The root cause stems from a misunderstanding of the loop bounds required to process all certificates in the chain according to RFC 5280 specifications, particularly regarding the handling of self-issued certificates and constraint accumulation. In the corrected versions starting with Bouncy Castle 1.86, LTS 2.73.13, and respective FIPS releases such as bcpkix-fips 1.0.13, 2.0.13, and 2.1.13, the logic has been rectified to ensure every certificate in the path is checked against name constraints. The fix explicitly waives the self-issued exemption for the final certificate as required by section 6.1.3 of RFC 5280 and correctly skips constraint accumulation steps only where appropriate for the target certificate while still validating its compliance with imposed restrictions.
To mitigate this vulnerability, organizations utilizing Bouncy Castle libraries must upgrade to version 1.86 or later for standard Java environments, version 2.73.13 or later for LTS distributions, and the specified FIPS-compliant versions if operating in regulated sectors requiring federal information processing standards compliance. Applications currently using PKIXCertPathReviewer should be audited to ensure they are not relying on this class for primary trust decisions without parallel validation via a standard CertPathValidator implementation. Developers must verify that their dependency management systems enforce these updated version constraints across all modules and transitive dependencies. Regular security assessments of certificate handling logic in cryptographic libraries are recommended to detect similar deviations from RFC standards, ensuring that path validation mechanisms accurately reflect the intended security policies defined by Certificate Authorities.