CVE-2026-18040
ŚrednieCVSS 5.9Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 1 - wyżej niż 1% wszystkich znanych CVE
Streszczenie
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.
Ocena ryzyka
Możliwe jest odzyskanie klucza prywatnego HQC przez atakującego z lokalnym dostępem do cache lub pomiarem czasu, co podważa poufność komunikacji chronionej tym algorytmem.
Rekomendacja
Zaktualizuj Bouncy Castle for Java do wersji 1.86 lub nowszej, która eliminuje side-channel poprzez arytmetykę bez tablic i próbnik bez rozgałęzień.
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-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-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, HQC leaked secret-derived data through two side channels: its GF(2^8) arithmetic used lookup tables indexed by field elements, making the cache line touched a function of the operand, and its fixed-weight support sampler left its duplicate scan as soon as a collision was found and stored accepted positions at a secret index. Both run on secret inputs during encapsulation and decapsulation, and the sampler re-expands the secret key from its seed on every decapsulation, so an attacker able to observe cache behaviour or decapsulation timing can recover information about the HQC private key. The field arithmetic is now table-free and the sampler branch-free within a batch of candidates, with output and randomness consumption unchanged.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS