Bouncy Castle for Java: Name constraints not applied to end-entity certificate
Summary
The PKIX certificate path reviewer in Bouncy Castle for Java does not check X.509 name constraints against the end-entity (leaf) certificate's subject DN or subjectAltName. Applications that use the reviewer's isValidCertPath() result as the trust decision can accept a certificate that the name-constrained issuing CA was never authorised to issue. The standard BC PKIX validator is not affected by this flaw, and the risk exists only where the reviewer is used for trust decisions.
Affected
- Bouncy Castle for Java (BC-JAVA) before 1.86
- Bouncy Castle for Java LTS (BC-LTS-JAVA) 2.73.0 to before 2.73.13
- Bouncy Castle for Java FIPS (BC-FJA) bcpkix-fips before 1.0.13 (1.0.X series, from 1.0.4), before 2.0.13 (2.0.X series) and before 2.1.13 (2.1.X series)
- Platform: Java 8 and later
Fixed in
- BC-JAVA 1.86
- BC-LTS-JAVA 2.73.13
- BC-FJA bcpkix-fips 1.0.13, 2.0.13 and 2.1.13
- Distribution packages: check the respective distribution tracker (openSUSE packages 1.86; Debian and Ubuntu status unverified)
Workaround
- No vendor-issued workaround is available.
- Applications that rely on the reviewer alone for trust decisions can use CertPathValidator.getInstance("PKIX", "BC") instead, which the vendor analysis reports correctly rejected the same chain. This is an inference from the vendor analysis, not an official workaround.
Exploitation
- No known exploitation in the wild.
- No CISA KEV entry and no public proof of concept known at the time of research.
- CISA SSVC assessment: exploitation none, automatable yes, technical impact partial.
Our recommendation
- Inventory Java applications and dependencies that include bcpkix or bcprov, and record their versions.
- Upgrade to BC-JAVA 1.86, BC-LTS-JAVA 2.73.13 or the matching BC-FJA release.
- Prioritise applications that use the PKIXCertPathReviewer for trust decisions, such as custom TLS, VPN, IoT or document-signing tooling.
- Check vendor appliances and software that bundle Java for updated components.
- Where patching is delayed, switch such trust decisions to CertPathValidator.getInstance("PKIX", "BC").
Public exploits
PoC-in-GitHub, Metasploit and Exploit-DB list nothing for this CVE.
Research sources
- Bouncy Castle commit 06dcff2f (fix) github.com
- Bouncy Castle wiki: CVE-2026-71889 (vendor advisory) github.com
- Bouncy Castle Java 1.86 release announcement www.bouncycastle.org
- OSV: DEBIAN-CVE-2026-71889 osv.dev
- OSV: CVE-2026-71889 osv.dev
- VulDB: CVE-2026-71889 vuldb.com
Researched and written up in English and German by an AI (Claude by Anthropic) based on NVD, CISA, EPSS and the sources listed. The vendor information is authoritative. Researched on 1 Nov 2026, 05:42.
Original description (NVD)
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).
Sources
The tracker combines official, freely usable data sources – updated continuously:
- NVD (NIST) – CVEs, rating (CVSS), affected products
- CISA KEV – vulnerabilities confirmed by CISA as actively exploited
- CISA Vulnrichment – CISA assessment (SSVC) in the official CVE record
- FIRST EPSS – probability of exploitation
- Microsoft MSRC – Patch Tuesday: vulnerabilities, severity, updates
- PoC-in-GitHub – public proof-of-concept repositories
- Metasploit (Rapid7) – modules of the Metasploit Framework
- Exploit-DB (OffSec) – archive of public exploits (links only)
- Patch days: official vendor pages (linked per vendor) (Vendor patch days)
This product uses data from the NVD API but is not endorsed or certified by the NVD. EPSS data © FIRST.org.
Affected? We can help.
We check whether your systems are affected, install updates and close the gap – continuously with the System Health Checker if you wish.