Bouncy Castle EUVD-2026-91990

Exploitation requires BOTH: (1) the application uses org.bouncycastle.pkix.jcajce.PKIXCertPathReviewer (or legacy org.bouncycastle.x509.PKIXCertPathReviewer) and relies on its isValidCertPath() result to make the trust decision - not the unaffected CertPathValidator "PKIX"/"BC", and not merely for per-certificate diagnostics; and (2) the trust chain contains an issuing CA carrying an X.509 NameConstraints extension that the end-entity (leaf) certificate's subject DN or subjectAltName actually violates. LIMITING FACTORS: this is a non-default API choice (the standard PKIX validator is not vulnerable), name-constrained CA hierarchies are relatively uncommon, and the bug only affects the leaf - intermediate CA constraint checks still worked. No authentication is required of the attacker (PR:N), but the vulnerability window is defined entirely by the victim's validation architecture rather than by any attacker-controlled configuration.

This is a certificate-validation bypass (CWE-295) in Bouncy Castle's PKIXCertPathReviewer, scored CVSS 4.0 8.7 (High) by the vendor with vector AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H - i.e. a remote, unauthenticated integrity impact with no confidentiality or availability loss. The raw score looks alarming, but the exploitation signals temper it sharply: no EPSS score, KEV status, or POC was provided (treat as no public exploit identified), and crucially the flaw only matters when an application uses the reviewer's isValidCertPath() to MAKE the trust decision rather than for per-certificate diagnostics alongside a real validation. The standard, recommended API - CertPathValidator.getInstance("PKIX","BC") - shares no code with the reviewer and correctly rejects the same chain, so correctly-architected consumers are NOT affected. This means real-world risk is a narrow API-misuse pattern rather than a blanket library flaw: high severity where the misuse exists, but low population of truly exploitable deployments. CONFLICT TO NOTE: the official vector sets VC:N, yet a certificate-trust bypass can enable TLS MITM with downstream confidentiality loss - the direct scored impact is integrity (accepting a forged identity), with confidentiality a possible second-order consequence not reflected in the base score. Overall: credible but conditional - prioritize only if you know you consume the reviewer for trust decisions.

An attacker obtains an end-entity (leaf) certificate from a CA that is subject to a NameConstraints extension, where the leaf's subject DN or subjectAltName falls outside the CA's permitted/excluded subtrees. If the victim application uses PKIXCertPathReviewer.isValidCertPath() as its actual trust gate, the reviewer returns true with an empty error list and accepts the unauthorized certificate, enabling the attacker to impersonate an identity the constrained CA was never authorised to vouch for (e.g. TLS server impersonation / MITM). No public exploit code was identified at time of analysis; exploitation hinges on the application's choice of validation API.