Cloudanix VulnDB

CVE-2026-71889

None

CVSS

—

EPSS

0.2%

Published

Oct 3, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A Java cryptography library bug let some certificates be trusted even though the issuing authority had placed restrictions that should have blocked them.

Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Low
Impact
Other
Component
Library
Class
Improper Input Validation
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

The PKIXCertPathReviewer in Bouncy Castle fails to enforce X.509 name constraints on the end-entity (leaf) certificate because checkNameConstraints skips index zero in the path, violating RFC 5280 section 6.1.3 checks for permitted and excluded subtrees on the target certificate's subject DN and subjectAltName.

Why it matters to the business

Java applications and services using the vulnerable reviewer for trust decisions may accept certificates issued by constrained CAs that should have been rejected, increasing risk of unauthorized access or interception in affected Red Hat and Bouncy Castle deployments.

How an attack unfolds

An attacker supplies a certificate chain in which the leaf violates name constraints set by its issuing CA; the reviewer incorrectly reports the path as valid with no errors, allowing the chain to be trusted where standard CertPathValidator would reject it.

How to fix it

Upgrade org.bouncycastle/bcpkix to jdk18on:1.86.0.redhat-00001 and ocp-tools to 4/jenkins-rhel9:1792041514 (or Bouncy Castle 1.86 / LTS 2.73.13 / BC-FJA 1.0.13 / 2.0.13 / 2.1.13 equivalents) and replace reviewer-based trust decisions with CertPathValidator.getInstance("PKIX", "BC").

How to confirm the fix worked

Confirm upgraded package versions, then run test chains containing leaf certificates that violate name constraints and verify they are now rejected with appropriate errors.

Typical attack path

  1. Locate an application or service relying on the vulnerable PKIXCertPathReviewer for certificate path validation
  2. Obtain or craft a leaf certificate whose subject or subjectAltName violates the name constraints of its issuing CA
  3. Present the invalid chain during TLS handshake, code-signing verification, or other PKIX validation
  4. Bypass intended CA restrictions and establish trust for the unauthorized certificate

How to detect it

Search application and TLS logs for certificate chains accepted despite name-constraint violations; review source for references to the reviewer classes and compare against known-good validation behavior.

What your security team should do

  • Apply the listed fixed package versions within the next maintenance window
  • Audit code for direct use of PKIXCertPathReviewer and migrate to standard PKIX validation
  • Re-test all certificate validation paths after upgrade

The record

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).

Affected packages

Ecosystem Package Introduced Fixed

Related vulnerabilities