CVE-2026-65625
ŚrednieCVSS 5.9Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 2 - wyżej niż 2% wszystkich znanych CVE
Streszczenie
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.
Ocena ryzyka
Sfałszowany szyfrogram jest niezawodnie akceptowany jako autentyczny w ciągu 256 prób bez znajomości klucza (fałszowanie znacznika uwierzytelniania i obejście integralności). Dostarczenie znacznika dłuższego niż 128 bitów powoduje badmatch i awarię procesu odszyfrowującego. Fallback jest osiągany przez publiczną ścieżkę odszyfrowywania JWE, gdy AES-GCM nie jest dostarczany przez natywny NIF crypto, np. w buildach FIPS, stripped lub starszych OTP.
Rekomendacja
Zaktualizuj bibliotekę jose do wersji 1.11.13 lub nowszej. Upewnij się, że środowisko udostępnia natywną implementację AES-GCM przez NIF crypto, aby uniknąć podatnego fallbacku.
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-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-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)
The pure-Erlang AES-GCM fallback in jose_jwa_aes derives the number of verified authentication tag bits from the attacker-supplied tag itself. In the {aes_gcm, Bits} clause of block_decrypt/4, the incoming tag is guarded only by is_binary/1, with no check on its length. Verification in gcm_block_decrypt/6 then computes TBits = bit_size(T) and compares only those bits of the real 128-bit tag. An attacker who controls a JWE token can truncate the authentication tag to as little as 8 bits, so only 8 bits are ever checked. This reduces forgery resistance from 2^-128 to 2^-8, and a forged ciphertext is reliably accepted as authentic within 256 attempts without knowledge of the key (an authentication tag forgery and integrity bypass). Supplying a tag longer than 128 bits instead causes a badmatch that crashes the decrypting process. The fallback is reached through the public JWE decryption path whenever AES-GCM is not provided by a native crypto NIF, for example on FIPS or stripped or older OTP builds. This issue affects jose: from 1.2.0 before 1.11.13.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS