CVE-2026-65628
ŚrednieCVSS 5.9Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 3 - wyżej niż 3% wszystkich znanych CVE
Streszczenie
Funkcja jose_jwk:shared_secret/2 (w Elixir jako JOSE.JWK.shared_secret/2) wyprowadza wspólny sekret ECDH z dwóch JWK. Jej pierwsza klauzula dopasowuje tylko, gdy oba JWK mają ten sam moduł typu klucza (kty), a klauzula zapasowa ponownie wywołuje siebie jako shared_secret(from(YourJWK), from(MyJWK)). Ponieważ from/1 zwraca już sparsowany rekord jose_jwk bez zmian, przekazanie dwóch JWK o różnych typach kluczy (np. klucza EC i RSA) powoduje, że klauzula zapasowa wchodzi ponownie z identycznymi argumentami, tworząc nieograniczoną pętlę rekurencyjną ogonową, która nigdy nie kończy się i nie powoduje awarii.
Ocena ryzyka
Aplikacja, która wyprowadza wspólny sekret z zewnętrznie dostarczonego klucza publicznego peera bez sprawdzenia zgodności typu i krzywej, może zostać wprowadzona w tę pętlę przez kontrolowany przez atakującego JWK, przypinając scheduler Erlanga na 100% CPU. Powtarzane żądania wyczerpują dostępne schedulery, powodując denial of service.
Rekomendacja
Zaktualizuj bibliotekę jose do wersji 1.11.13 lub nowszej. Przed wyprowadzeniem wspólnego sekretu sprawdzaj, czy typ klucza i krzywa peera są zgodne z kluczem lokalnym.
Inne podatności w jose
Zobacz wszystkie- CVE-2026-65632Średnie
Biblioteka jose akceptuje podpisy JWS ECDSA (ES256, ES256K, ES384, ES512) o niekanonicznej długości. Podczas weryfikacji funkcja jose_jwk_kty_ec:verify/4 dzieli surowy podpis na pół według jego rzeczywistej długości w bajtach, zamiast wymuszać stałą długość wymaganą przez RFC 7518 §3.4, a następnie dekoduje każdą połowę ignorując wiodące bajty zerowe. Atakujący posiadający jeden ważny token może dodawać wiodące bajty zerowe do połówek R i S, tworząc wiele różnych ciągów bajtów podpisu, które weryfikują się tym samym kluczem (malleability podpisu).
- CVE-2026-65631Średnie
Nieefektywna złożoność algorytmiczna w erlang-jose pozwala nieuwierzytelnionemu zdalnemu atakującemu na wywołanie wyczerpania CPU (denial of service) poprzez przesłanie spreparowanego klucza RSA JSON Web Key. Gdy aplikacja parsuje niezaufany JWK przez publiczne API jose_jwk:from_binary/1 lub jose_jwk:from_map/1, klucz RSA zawierający d, e i n, ale bez parametrów chińskiego twierdzenia o resztach (p, q, dp, dq, qi), trafia do convert_sfm_to_crt/1, który próbuje odzyskać brakujące czynniki poprzez faktoryzację modułu. Gdy moduł nie da się rozłożyć na dwa czynniki, pętla wyszukiwania wykonuje kosztowną eksponencjację modularną w każdej iteracji i nigdy się nie kończy.
- CVE-2026-65630Średnie
Podatność typu Observable Timing Discrepancy w bibliotece potatosalad jose pozwala na odzyskanie długoterminowego klucza prywatnego X25519 poprzez kanał boczny czasowy w czysto erlangowej implementacji Curve25519. Implementacja wykonuje mnożenie skalarne zależne od wartości bitów klucza prywatnego, co powoduje, że czas wykonania publicznych funkcji (np. scalarmult/2, x25519/2) zależy od klucza prywatnego. Podatność dotyczy wersji od 1.10.0 do 1.11.13.
- CVE-2026-65629Wysokie
Biblioteka jose eksportuje klucze prywatne szyfrowane hasłem w formacie PKCS#8 z zaszytymi parametrami PBES2: PBKDF2-HMAC-SHA256 z 2048 iteracjami i 8-bajtową solą, których nie można nadpisać. Wartości te są znacznie poniżej aktualnych zaleceń, co umożliwia tani atak offline na hasło i odzyskanie klucza prywatnego. Problem dotyczy wersji od 1.10.0 przed 1.11.13.
- CVE-2026-65627Średnie
Nieprawidłowa obsługa silnie skompresowanych danych (amplifikacja danych) w potatosalad jose (erlang-jose) pozwala zdalnemu atakującemu na wyczerpanie pamięci węzła za pomocą małego spreparowanego tokenu JWE. Funkcja jose_jwe_zip:uncompress/2 dekompresuje tekst jawny JWE skompresowany DEFLATE, gdy token zawiera opcjonalny nagłówek zip: DEF, wywołując zlib:inflate/2 na całym kontrolowanym przez atakującego strumieniu bez ograniczenia rozmiaru wyjścia lub współczynnika kompresji. Surowy DEFLATE osiąga współczynniki około 1000:1 na wysoce powtarzalnych danych, więc kilkukilobajtowy token rozpakowuje się do setek megabajtów lub gigabajtów w jednym wywołaniu.
- CVE-2026-65626Średnie
Czysto-erlangowa implementacja odszyfrowywania RSAES-PKCS1-v1_5 w module jose_jwa_pkcs1 jest oracle'em paddingowym Bleichenbachera. Funkcja eme_pkcs1_decode/2 zwraca odzyskaną wiadomość, gdy odszyfrowany blok ma prawidłowy padding PKCS#1 v1.5, a w przeciwnym razie zwraca odrębny wynik błędu; rsaes_pkcs1_decrypt/2 dodatkowo zwraca {error, {badsize, _}} przy niepowodzeniu sprawdzenia długości. Implementacja nie stosuje środka zaradczego implicit rejection (RFC 8017 §7.2.2), więc jednobitowy sygnał zgodności paddingu wycieka do wywołującego. Ponieważ eksponencjacja modularna w dp/2 jest surowym, nieblindowanym crypto:mod_pow/3, sprawdzenie paddingu pozostaje rozróżnialne czasowo nawet gdy aplikacja normalizuje wszystkie błędy do jednej wartości.
- CVE-2026-65625Średnie
Czysto-erlangowy fallback AES-GCM w jose_jwa_aes wyprowadza liczbę weryfikowanych bitów znacznika uwierzytelniania z samego znacznika dostarczonego przez atakującego. W klauzuli {aes_gcm, Bits} funkcji block_decrypt/4 przychodzący znacznik jest sprawdzany tylko przez is_binary/1, bez kontroli długości. Weryfikacja w gcm_block_decrypt/6 oblicza TBits = bit_size(T) i porównuje tylko te bity rzeczywistego 128-bitowego znacznika. Atakujący kontrolujący token JWE może skrócić znacznik uwierzytelniania do zaledwie 8 bitów, więc sprawdzane jest tylko 8 bitów, co zmniejsza odporność na fałszowanie z 2^-128 do 2^-8.
- CVE-2026-34240Wysokie
Biblioteka JOSE (JavaScript Object Signing and Encryption) przed wersją 0.3.5+1 zawiera podatność umożliwiającą nieuwierzytelnionemu atakującemu zdalne fałszowanie tokenów JWS/JWT. Atakujący może wykorzystać klucz publiczny umieszczony w nagłówku JWK do podpisania tokena, a biblioteka błędnie traktuje ten klucz jako wiarygodny nawet jeśli nie znajduje się w zaufanym magazynie kluczy.
Oryginalny opis (angielski, źródło NVD)
jose_jwk:shared_secret/2 (exposed in Elixir as JOSE.JWK.shared_secret/2) derives an ECDH shared secret from two JWKs. Its first function clause only matches when both JWKs carry the same key type (kty) module, and its fallback clause re-invokes itself as shared_secret(from(YourJWK), from(MyJWK)). Because from/1 returns an already-parsed jose_jwk record unchanged, passing two JWKs whose key types differ (for example an EC key and an RSA key) makes the fallback clause re-enter with identical arguments, producing an unbounded tail-recursive loop that never returns and never crashes. An application that derives a shared secret from an externally supplied peer public key without first checking that the peer key's type and curve match its own key can be driven into this loop by an attacker-controlled JWK, pinning an Erlang scheduler at 100% CPU. Repeated requests exhaust the available schedulers, resulting in a denial of service. This issue affects jose: from 1.5.0 before 1.11.13.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS