CVE-2026-71889

W Bouncy Castle dla Java przed wersją 1.86 ani kopia PKIXCertPathReviewer - org.bouncycastle.pkix.jcajce.PKIXCertPathReviewer, ani starsza wersja org.bouncycastle.x509.PKIXCertPathReviewer - nie zastosowały ograniczeń nazw X.509 do certyfikatu jednostki końcowej. checkNameConstraints przeszło ścieżkę z pętlą związaną z indeksem większym od zera, co jest ograniczeniem wymaganym przez kroki przeprowadzane tylko przez urząd certyfikacji, ale indeks zero jest certyfikatem docelowym w ramach standardowej kolejności CertPath, więc dozwolone i wykluczone kontrole poddrzewa RFC 5280 sek. 6.1.3 (b) i (c) nigdy nie były sprzeczne z nazwą DN tematu liścia lub jego AltName podmiotu. Łańcuch, którego liść naruszył rozszerzenie NameConstraints narzucone przez własny wystawiający urząd certyfikacji, zgłosił zatem funkcję isValidCertPath() true z pustą listą błędów, podczas gdy CertPathValidator.getInstance("PKIX", "BC"), która nie dzieli kodu z recenzentem, odrzuciła identyczny łańcuch w oparciu o identyczną kotwicę zaufania. Aplikacja korzystająca z recenzenta do podjęcia decyzji o zaufaniu, a nie do diagnostyki wraz z rzeczywistą walidacją, zaakceptowała certyfikat, do którego wydania ograniczony urząd certyfikacji nigdy nie był upoważniony. Obie kopie sprawdzają teraz każdy certyfikat na ścieżce, łącznie z celem, zrzekają się sek. 4.2.1.10 własne wydanie zwolnienia dla świadectwa końcowego zgodnie z ust. 6.1.3 wymaga i pomiń sek. 6.1.4 (g) Etap akumulacji ograniczeń dla celu. Ten problem dotyczy także Bouncy Castle dla Java LTS przed wersją 2.73.13, który zawiera jedynie kopię recenzenta w formacie org.bouncycastle.pkix.jcajce. Wpływa także na Bouncy Castle dla Java FIPS (BC-FJA) przed bcpkix-fips 1.0.13 (seria 1.0.X), 2.0.13 (seria 2.0.X) i 2.1.13 (seria 2.1.X).