CVE-2026-71887
WysokieCVSS 8.2Streszczenie
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.
Ocena ryzyka
Atakujący potrzebuje jedynie publicznego podklucza podpisującego ofiary, aby powiązać go z własnym kluczem głównym i sprawić, że prawdziwy podpis ofiary zostanie zweryfikowany jako ważny, ale przypisany do tożsamości wybranej przez atakującego. Prowadzi to do błędnego przypisania autentycznego podpisu, co może podważyć zaufanie do weryfikacji podpisów OpenPGP w organizacji.
Rekomendacja
Zaktualizuj Bouncy Castle for Java do wersji 1.86 lub nowszej, aby wymuszać obecność osadzonej sygnatury Primary Key Binding dla podkluczy mogących wystawiać podpisy. Do czasu aktualizacji unikaj polegania wyłącznie na wysokopoziomowym API OpenPGP przy weryfikacji tożsamości wystawcy podpisu.
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-71888Wysokie
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.
- 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 high-level OpenPGP API accepted a data signature made by a signing subkey whose Subkey Binding signature carried no embedded Primary Key Binding (cross-certification) signature, in the case where that binding omits a Key Flags subpacket. RFC 9580 sec. 5.2.1.8 and sec. 10.1.3 require the embedded Primary Key Binding signature on any subkey that can issue signatures; it is the subkey's own statement that it belongs to the primary key it is bound under. OpenPGPCertificate resolved the subkey's key flags two different ways. isSigningKey() goes through getKeyFlags() and getApplyingSubpacket(), which falls back to the primary key's direct-key or primary User ID self-signature when the binding signature omits the subpacket, so the subkey inherited the primary's SIGN_DATA and counted as signing-capable; verifyEmbeddedPrimaryKeyBinding(), which enforces the requirement, reads the binding signature's own hashed subpackets, found no SIGN_DATA there, and returned early as a non-signing key without ever demanding the back signature. The same subkey was therefore signing-capable - so its signatures were attributed to the certificate and OpenPGPSignature.OpenPGPDocumentSignature.isValid() returned true - while being exempt from cross-certification, where GnuPG refuses the identical certificate and message. An attacker needs only the victim's public signing subkey, which is public material: they bind it to their own primary key with a Subkey Binding signature they are able to make, carrying no Key Flags and no embedded Primary Key Binding signature, which they cannot make without the subkey's private key, and a relying party verifying one of the victim's genuinely signed messages against that certificate is told the signature is valid and given the attacker's certificate as its issuer. Because a certificate's User IDs are self-asserted, a verifier that pins on the subkey's fingerprint or key ID while taking the identity from the enclosing certificate reports a real signature under an attacker-chosen identity. This is misattribution of a genuine signature rather than forgery of a new one: no private key is recovered, and the signature must be one the grafted subkey actually made. The low-level PGPSignature / PGPPublicKeyRing API performs no binding checks by design and is unaffected. Key Flags are a statement about the key the carrying signature refers to (RFC 9580 sec. 5.2.3.29), so a subkey no longer inherits them from the certificate-wide signatures of the primary key: a Subkey Binding signature that omits the subpacket now leaves the subkey with no capabilities rather than the primary's, which makes the flags the cross-certification check consults the same flags every other decision consults. Preferences and the other subpackets a direct-key signature carries are inherited as before, and the primary key itself, whose flags legitimately come from its own direct-key or User ID self-signature, is unaffected.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS