CVE-2026-63575

Podatność w Legion of the Bouncy Castle Inc. bc-csharp przed 2.7.0 polega na alokacji zasobów bez ograniczeń w odszyfrowywaniu klucza prywatnego opartego na haśle (PbeUtilities.GenerateCipherParameters). Atakujący może dostarczyć zaszyfrowany klucz prywatny, taki jak PKCS#8 EncryptedPrivateKeyInfo lub plik PEM "ENCRYPTED PRIVATE KEY", i spowodować odmowę usługi poprzez wyczerpanie CPU, używając liczby iteracji bliskiej 2^31, ponieważ liczba jest pobierana z nieuwierzytelnionych parametrów algorytmu bez górnego ograniczenia, a wyprowadzanie klucza odbywa się przed sprawdzeniem hasła lub danych. Dotyczy to PKCS#5 PBES1 i PBES2 (PBKDF2), algorytmów PBE PKCS#12 oraz odbiorców haseł CMS (CmsPbeKey).

Nieprawidłowa walidacja certyfikatu w sprawdzaniu ograniczeń nazw directoryName (PkixNameConstraintValidator.WithinDNSubtree) w Legion of the Bouncy Castle Inc. bc-csharp przed 2.7.0 pozwala atakującemu kontrolującemu lub mogącemu uzyskać certyfikaty od pośredniego CA z ograniczeniami nazw na uzyskanie akceptacji certyfikatów przez walidację ścieżki PKIX, których nazwa wyróżniająca podmiotu lub directoryName subjectAltName znajduje się poza dozwolonymi poddrzewami CA. Atak wykorzystuje nazwę, która umieszcza inne RDN przed kopią dozwolonej sekwencji RDN, ponieważ sprawdzenie szuka pierwszego RDN ograniczenia w dowolnym miejscu nazwy i porównuje pozostałe RDN od tej pozycji, zamiast wymagać, aby ograniczenie było początkowym prefiksem nazwy zgodnie z RFC 5280 sekcje 4.2.1.10 i 7.1.

Nieprawidłowa walidacja certyfikatu w PkixNameConstraintValidator (ExtractHostFromURL) w Legion of the Bouncy Castle Inc. bc-csharp przed 2.7.0 pozwala podrzędnemu CA z ograniczeniami nazw lub komukolwiek mogącemu uzyskać certyfikaty z wybranymi subjectAltName URI od takiego CA na obejście dozwolonych lub wykluczonych ograniczeń nazw uniformResourceIdentifier podczas walidacji ścieżki certyfikacji. Atak wykorzystuje URI, którego ścieżka, zapytanie, fragment lub userinfo zawiera znaki takie jak '@' lub ':', ponieważ host był wyodrębniany przez cięcie łańcucha bez uprzedniego wyizolowania komponentu authority zgodnie z RFC 3986, więc host porównywany z ograniczeniami mógł różnić się od rzeczywistego hosta URI.

Alokacja pamięci z nadmierną wartością rozmiaru w parserach podpakietów sygnatur i atrybutów użytkownika OpenPGP (SignatureSubpacketsParser.ReadPacket, UserAttributeSubpacketsParser.ReadPacket) w Legion of the Bouncy Castle Inc. bc-csharp przed 2.7.0 pozwala zdalnemu, nieuwierzytelnionemu atakującemu mogącemu dostarczyć spreparowany klucz publiczny, certyfikat lub sygnaturę OpenPGP na wywołanie odmowy usługi (OutOfMemoryException lub wyczerpanie pamięci w procesie parsowania) poprzez nagłówek podpakietu używający pięciooktetowej formy długości. Zadeklarowana długość była używana do rozmiaru bufora podpakietu bez górnego ograniczenia i bez porównania z rozmiarem otaczającego obszaru podpakietu lub pakietu, więc kilka bajtów wejścia mogło zażądać alokacji do około 2 GB, zanim jakiekolwiek dane podpakietu zostały odczytane.

Obserwowalna rozbieżność w odwijaniu transportu klucza CMS RSA PKCS#1 v1.5 (KeyTransRecipientInformation.UnwrapKey) w Legion of the Bouncy Castle Inc. bc-csharp przed 2.7.0 pozwala zdalnemu atakującemu posiadającemu przechwyconą wiadomość CMS EnvelopedData i mogącemu przesyłać wiele zmodyfikowanych wiadomości do aplikacji, która je odszyfrowuje kluczem prywatnym RSA odbiorcy i ujawnia, jak odszyfrowanie się nie powiodło, na odzyskanie klucza szyfrowania zawartości przechwyconej wiadomości, a tym samym jej zawartości, poprzez atak adaptacyjny wybranego szyfrogramu w stylu Bleichenbachera. Szyfrogram transportu klucza z nieprawidłowym wypełnieniem PKCS#1 v1.5 jest odrzucany podczas odwijania z odrębnym wyjątkiem "bad padding in message." CmsException zamiast być zastąpiony losowym kluczem, więc można go odróżnić od poprawnie wypełnionego szyfrogramu, który zawodzi dopiero później przy odszyfrowywaniu zawartości.

Alokacja zasobów bez ograniczeń w ładowaniu magazynu kluczy PKCS#12 (Pkcs12Store.Load) w Legion of the Bouncy Castle Inc. bc-csharp przed 2.7.0 pozwala atakującemu mogącemu dostarczyć plik PKCS#12 (PFX) na wywołanie odmowy usługi poprzez wyczerpanie CPU przy użyciu liczby iteracji bliskiej 2^31 w MacData pliku lub w parametrach PBE zaszyfrowanego SafeContents lub shrouded key bag. Liczby są pobierane z pliku bez górnego ograniczenia, a wyprowadzanie klucza odbywa się przed sprawdzeniem MAC lub hasła. Zero lub ujemna liczba jest objęta CVE-2026-63575. Pkcs12Utilities.ConvertToDefiniteLength jest również dotknięty.

Nieprawidłowa weryfikacja podpisu kryptograficznego w walidatorze ścieżki certyfikatów atrybutów (PkixAttrCertPathValidator, używany również przez PkixAttrCertPathBuilder) w Legion of the Bouncy Castle Inc. bc-csharp przed 2.7.0 pozwala zdalnemu atakującemu na akceptację sfałszowanego certyfikatu atrybutów X.509 jako ważnego, a tym samym uzyskanie ról lub uprawnień przyznawanych przez aplikację na podstawie jego atrybutów. Atak wykorzystuje certyfikat atrybutów, który wskazuje zaufany urząd atrybutów jako wystawcę, ale nie został przez niego podpisany, ponieważ kroki walidacji RFC 3281 sprawdzają ścieżki certyfikacji posiadacza i wystawcy, okres ważności, rozszerzenia i status unieważnienia, ale nigdy nie weryfikują podpisu certyfikatu atrybutów kluczem publicznym wystawcy. Dotyczy to tylko aplikacji używających tych klas do walidacji certyfikatów atrybutów.

W bibliotece bc-csharp przed wersją 2.7.0 weryfikator MAC oparty na haśle CMP/CRMF (PKMacBuilder) nie ogranicza liczby iteracji, jeśli nie podano maksymalnej wartości. Zdalny atakujący może wysłać wiadomość CMP lub żądanie CRMF z bardzo dużą liczbą iteracji, powodując przeciążenie CPU i odmowę usługi.

W bibliotece bc-csharp przed wersją 2.7.0 funkcja IesEngine.DecryptBlock wykazuje zauważalną różnicę w zachowaniu przy błędzie dopełnienia i błędzie MAC. Atakujący, który przechwycił szyfrogram IES/ECIES, może wykorzystać atak typu padding-oracle do odzyskania tekstu jawnego.

W bibliotece bc-csharp przed wersją 2.7.0 mechanizm składania pakietów DTLS (DtlsReliableHandshake, DtlsReassembler) alokuje pamięć na podstawie 24-bitowej długości z nagłówka fragmentu, bez sprawdzenia maksymalnego rozmiaru wiadomości. Zdalny atakujący może wysłać spreparowane fragmenty, powodując wyczerpanie pamięci i odmowę usługi.