CVE‐2026‐71889

Title: PKIXCertPathReviewer does not apply X.509 name constraints to the target certificate.

Issue affecting: BC before 1.86, BC-LTS before 2.73.13, BC-FJA before bcpkix-fips 1.0.13 (from 1.0.4), 2.0.13 and 2.1.13.

Fixed versions: BC 1.86, BC-LTS 2.73.13, BC-FJA bcpkix-fips 1.0.13 (from 1.0.4), 2.0.13 and 2.1.13.

Platform affected: Java 8 and later.

RFC 5280 sec. 6.1.3 (b) and (c) apply the name constraints accumulated from issuing CAs to every certificate in the path, the target certificate included. The self-issued exemption of sec. 4.2.1.10 is waived for the final certificate, and the wrap-up in sec. 6.1.5 does not revisit name constraints, so sec. 6.1.3 is the only place the leaf gets checked.

Both copies of PKIXCertPathReviewer drove checkNameConstraints from a loop bound of index > 0. That is the correct bound for the CA-only steps — basicConstraints, keyUsage, path length — but under the standard CertPath ordering index 0 is the end-entity certificate. The body performing checkPermittedDN / checkExcludedDN / checkPermitted(GeneralName) / checkExcluded(GeneralName) therefore never executed for the leaf, and no other method in the class re-applied the constraints.

A chain whose leaf's subject DN or subjectAltName violated a NameConstraints extension imposed by its own issuing CA reported isValidCertPath() true with an empty error list. BC's own trust-deciding validator, CertPathValidator.getInstance("PKIX", "BC"), shares no code with the reviewer — it iterates index >= 0 through RFC3280CertPathUtilities.processCertBC — and correctly rejected the identical chain against the identical trust anchor.

The exposure is to applications that call the reviewer for the trust decision, which its isValidCertPath() invites, rather than purely for the richer per-certificate diagnostics it exists to provide. Such an application accepted a certificate that the name-constrained CA was never authorised to vouch for, which is precisely what name constraints exist to prevent.

Both copies now check every certificate in the path including the target, waive the 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, where there is no next certificate to accumulate for.

The fix was introduced in commit 06dcff2f5103.

Credit: Yu Bao from the PayPal Cyber Security Team.