Threats Tagged 'cve-2026-71889'
View all threats tagged with 'cve-2026-71889'. Filter and sort to focus on specific types of threats.
Stop chasing alerts. Route them.
Start free, then upgrade once to turn Radar into an automated delivery engine for your security stack.
Custom feeds / Automations: email, Slack, webhooks, SIEM/MISP / API access (baseline limits)
API access activates after upgrading in Console -> Billing.
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.
Filter Threats
Narrow down the results by type, severity, or affected countries
Threats Tagged 'cve-2026-71889'
Click on any threat for detailed analysis and mitigation recommendations
Bouncy Castle for Java versions before 1.86 and certain LTS and FIPS versions contain a vulnerability in the PKIXCertPathReviewer component where X.509 name constraints were not applied to the end-entity (leaf) certificate. This caused the validation to incorrectly accept certificate chains with leaf certificates violating name constraints imposed by their issuing CA. The issue has been addressed by updating the reviewer to check every certificate in the path, including the target certificate, and correctly applying the relevant RFC 5280 constraints. Join the discussion | GCVE Database | 10/03/2026, 09:31:18 UTC Added: 10/03/2026, 17:21:01 UTC |
0 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). Join the discussion | CVE Database V5 | 10/03/2026, 08:31:01 UTC Added: 10/03/2026, 08:46:49 UTC |
Showing 1 to 2 of 2 results