CVE-2026-71888
WysokieCVSS 8.7Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 1 - wyżej niż 1% wszystkich znanych CVE
Streszczenie
W Bouncy Castle for Java przed wersją 1.86 parser strumieniowy CMS AuthenticatedData akceptował komunikaty, w których pola digestAlgorithm i authAttrs były niespójne co do obecności uwierzytelnionych atrybutów. Parser podejmował decyzję na podstawie samego digestAlgorithm, przez co mógł zweryfikować MAC treści i zwrócić atrybuty przez getAuthAttrs() jako uwierzytelnione, mimo że MAC nigdy ich nie obejmował. Problem dotyczy również wersji LTS przed 2.73.13 oraz wydań FIPS (BC-FJA) przed odpowiednimi wersjami bcpkix-fips i bcutil-fips.
Ocena ryzyka
Atakujący mogący modyfikować komunikaty w tranzycie może wstrzyknąć uwierzytelniony atrybut (np. ESSSecurityLabel z RFC 2634) do prawidłowego komunikatu, nie znając klucza szyfrującego ani klucza MAC. Aplikacja podejmująca decyzje o autoryzacji, routingu lub etykietowaniu na podstawie tych atrybutów będzie działać na wartościach wybranych przez atakującego.
Rekomendacja
Zaktualizuj Bouncy Castle for Java do wersji 1.86 lub nowszej, wersję LTS do 2.73.13 lub nowszej, a wydania FIPS do bcpkix-fips 1.0.13/2.0.13/2.1.13 oraz bcutil-fips 2.0.8/2.1.8 lub nowszych. Do czasu aktualizacji nie należy opierać decyzji bezpieczeństwa wyłącznie na atrybutach zwracanych przez getAuthAttrs() z komunikatów CMS AuthenticatedData.
Inne podatności w Bouncy Castle for Java
Zobacz wszystkie- CVE-2026-97873Średnie
W Bouncy Castle for Java przed 1.86 (oraz LTS przed 2.73.13) rodziny PBES1 i PKCS#12 PBE używały liczby iteracji pochodzącej z niezaufanych danych wejściowych bez ograniczenia, co pozwalało na wymuszenie dowolnie dużego nakładu pracy. Poprawka odrzuca ujemną lub przekraczającą limit liczbę iteracji (domyślnie 10 000 000) na podstawie właściwości org.bouncycastle.pbe.max_iteration_count.
- CVE-2026-71890Wysokie
W Bouncy Castle for Java przed wersją 1.86 walidacja listy propozycji w zewnętrznym commicie MLS (RFC 9420) nie sprawdzała, czy usuwany liść faktycznie należy do dołączającego. Brak tej weryfikacji pozwalał każdej osobie posiadającej publiczne GroupInfo grupy na wysłanie commitu z propozycją Remove wskazującą dowolnego członka, co skutkowało jego usunięciem i przejęciem jego miejsca w drzewie ratchet. Poprawka wymusza zgodność poświadczenia usuwanego liścia z poświadczeniem nowego liścia dołączającego po obu stronach.
- CVE-2026-71887Wysokie
W Bouncy Castle for Java przed wersją 1.86 wysokopoziomowe API OpenPGP akceptowało podpis danych wykonany przez podklucz podpisujący, którego sygnatura wiążąca podklucz nie zawierała osadzonej sygnatury Primary Key Binding (cross-certification), gdy w tej sygnaturze pominięto podpakiet Key Flags. Metoda isSigningKey() dziedziczyła flagi SIGN_DATA z klucza głównego, podczas gdy verifyEmbeddedPrimaryKeyBinding() odczytywała tylko podpakiety sygnatury wiążącej i uznawała podklucz za niepodpisujący, przez co ten sam podklucz był jednocześnie zdolny do podpisywania i zwolniony z wymogu cross-certification.
- CVE-2026-18040Średnie
W Bouncy Castle for Java przed 1.86 implementacja HQC ujawniała dane pochodzące z klucza prywatnego przez dwa kanały side-channel: arytmetyka GF(2^8) używała tablic wyszukiwania indeksowanych elementami pola, a próbnik wsparcia o stałej wadze kończył skanowanie przy pierwszej kolizji i zapisywał pozycje pod sekretnym indeksem. Atakujący obserwujący zachowanie cache lub czas deszyfrowania może odzyskać informacje o kluczu prywatnym HQC.
- CVE-2026-18036Wysokie
W bibliotece Bouncy Castle for Java przed wersją 1.86 występuje podatność typu side-channel w implementacji NTRU. Redukcja tajnych wartości za pomocą operatora % w trzech funkcjach pomocniczych powoduje, że czas wykonania zależy od operandu (dzielenie przez zmienną), co może pozwolić atakującemu na odzyskanie informacji o kluczu prywatnym NTRU poprzez pomiar czasu.
- CVE-2026-17507Wysokie
W implementacji MLS (RFC 9420) w Bouncy Castle for Java przed wersją 1.86 wartość leaf_index typu uint32 jest przechowywana jako signed int, co pozwala na przesłanie wartości z ustawionym najstarszym bitem, która dekoduje się jako liczba ujemna. Nieprawidłowe porównanie w GroupKeySet.SecretTree.hasLeaf i Group.validateRemove pozwala na obejście sprawdzania przynależności, co może prowadzić do ataku DoS poprzez nieograniczony wzrost listy węzłów i wyczerpanie sterty JVM.
- CVE-2023-33201Średnie
Bouncy Castle dla Javy przed wersją 1.74 jest podatny na atak typu LDAP injection. Podatność ta dotyczy aplikacji, które wykorzystują LDAP CertStore z Bouncy Castle do walidacji certyfikatów X.509, gdzie nazwa podmiotu certyfikatu jest wstawiana do filtru wyszukiwania LDAP bez odpowiedniego zabezpieczenia.
Oryginalny opis (angielski, źródło NVD)
In Bouncy Castle for Java before 1.86, the streaming CMS AuthenticatedData parser accepted a message whose digestAlgorithm and authAttrs fields disagreed about whether authenticated attributes were present. RFC 5652 sec. 9.1 pairs the two, requiring that authAttrs be present whenever digestAlgorithm is, and sec. 9.2 makes the MAC cover the DER encoding of authAttrs when they are present and the eContent OCTET STRING directly when they are not. CMSAuthenticatedDataParser has to choose between those two in its constructor, before it can reach authAttrs, which comes later in the SEQUENCE, so it chose on digestAlgorithm alone: for a message with digestAlgorithm absent but authAttrs present it verified the content MAC and then returned the attributes through getAuthAttrs() as though they had been authenticated, when the MAC had never covered them. An attacker able to modify a message in transit could insert an authenticated attribute, such as an RFC 2634 ESSSecurityLabel, into an otherwise valid message while holding neither the key-encryption key nor the content-MAC key, and an application taking an authorization, routing or labelling decision from those attributes would act on attacker-chosen values. The content itself remained MAC-bound. asn1.cms.AuthenticatedData now rejects the mismatched pairing when parsing and CMSAuthenticatedDataParser cross-checks the two fields once authAttrs is read. This is a variant of CVE-2026-59642, which bound the content to the MAC for messages that legitimately carry authAttrs, and which does not address this case. This issue also affects Bouncy Castle for Java LTS before 2.73.13, and 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), and bcutil-fips 2.0.8 (2.0.X series) and 2.1.8 (2.1.X series).
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS