CVE-2026-65632
ŚrednieCVSS 5.1Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 1 - wyżej niż 1% wszystkich znanych CVE
Streszczenie
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).
Ocena ryzyka
Podatność nie pozwala na fałszowanie nowych ładunków ani podszywanie się pod podpisującego, ale obchodzi mechanizmy zakładające unikalność ważnego tokenu lub jego podpisu, takie jak unieważnianie tokenów po hashu, cache replay/idempotencji oraz logika deduplikacji.
Rekomendacja
Zaktualizuj bibliotekę jose do wersji 1.11.13 lub nowszej. Przejrzyj mechanizmy bezpieczeństwa oparte na unikalności podpisu tokenu i nie polegaj na hashu podpisu jako unikalnym identyfikatorze.
Inne podatności w jose
Zobacz wszystkie- 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-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)
The jose library accepts ECDSA (ES256, ES256K, ES384, and ES512) JWS signatures of a non-canonical length. When verifying an ECDSA signature, jose_jwk_kty_ec:verify/4 in src/jwk/jose_jwk_kty_ec.erl splits the raw signature in half by its actual byte length (split_binary(Signature, byte_size(Signature) div 2)) instead of enforcing the fixed length required by RFC 7518 §3.4, and then decodes each half with crypto:bytes_to_integer/1, which ignores leading zero bytes. As a result, an attacker who holds one valid token can prepend leading zero bytes to each of the R and S halves to produce longer signatures that still split evenly and decode to the same (r, s) pair, so many distinct signature byte strings all verify against the same key (signature malleability). This does not allow forging new payloads or impersonating a signer, because the underlying (r, s) values are unchanged. It does defeat any security control that assumes a valid token or its signature is unique, such as token-revocation-by-hash, replay or idempotency caches, and deduplication logic. This issue affects jose: from 1.0.0 before 1.11.13.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS