CVE-2026-65631
ŚrednieCVSS 6.9Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 14 - wyżej niż 14% wszystkich znanych CVE
Streszczenie
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.
Ocena ryzyka
Pojedyncze żądanie o rozmiarze kilkuset bajtów wymusza blisko jedną sekundę pracy CPU, a większy moduł zwiększa koszt. Zalewając takie żądania, atakujący może wysycić wszystkie schedulery i odmówić usługi bez poświadczeń, ważnego klucza RSA czy specjalnej konfiguracji.
Rekomendacja
Zaktualizuj bibliotekę jose do wersji 1.11.13 lub nowszej. Ogranicz przyjmowanie niezaufanych JWK z zewnętrznych źródeł oraz rozważ limity zasobów dla operacji parsowania kluczy.
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-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-65628Średnie
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.
- 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)
Inefficient Algorithmic Complexity in erlang-jose allows an unauthenticated remote attacker to cause a CPU-exhaustion denial of service by submitting a crafted RSA JSON Web Key. When an application parses an untrusted JWK through the public jose_jwk:from_binary/1 or jose_jwk:from_map/1 API (or the Elixir wrappers JOSE.JWK.from_binary/1 and JOSE.JWK.from_map/1), an RSA private key that supplies d, e, and n but omits all Chinese Remainder Theorem parameters (p, q, dp, dq, qi) is routed into convert_sfm_to_crt/1, which tries to recover the missing primes by factoring the modulus. The three integers are read straight from the base64url input and are never validated as a real RSA key. When the modulus cannot be split into two factors (for example, when it is itself prime), the search loop convert_sfm_to_crt_find_p/6 performs a modular exponentiation over the attacker-sized modulus on every iteration and never succeeds. A single request of a few hundred bytes forces close to one CPU-second of work before an internal one-second watchdog kills the worker, and a larger modulus raises the cost further. By flooding such requests an attacker can saturate every scheduler and deny service, without credentials, a valid RSA key, or any special configuration. This issue affects jose: from 1.7.7 before 1.11.13.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS