CVE-2026-102275
ŚrednieCVSS 6.5Streszczenie
PyJWT to implementacja standardów JSON Web Token w Pythonie. Od wersji 2.1.0 do 2.15.0 metoda OKPAlgorithm.from_jwk w jwt/algorithms.py jest podatna, ponieważ ścieżka importu prywatnego JWK nie porównuje klucza publicznego wyprowadzonego z d z x. Ma to miejsce, gdy prywatny JWK OKP dostarcza nieodpowiadające sobie komponenty x i d. W rezultacie tożsamość wyprowadzona z x może różnić się od operacji wykonywanych z d.
Ocena ryzyka
Jeśli integracja akceptuje również parametry klucza prywatnego z nagłówka proof bez ich odrzucania, atakujący może użyć skradzionego tokenu z ograniczeniem nadawcy bez posiadania legalnego klucza prywatnego. Może to prowadzić do obejścia kontroli tożsamości i nieautoryzowanego dostępu.
Rekomendacja
Zaktualizuj PyJWT do wersji 2.15.0 lub nowszej, która porównuje klucz publiczny wyprowadzony z d z x. Upewnij się, że integracje nie akceptują parametrów klucza prywatnego z nagłówków proof.
Inne podatności w PyJWT
Zobacz wszystkie- CVE-2026-102274Średnie
PyJWT to implementacja standardów JSON Web Token w Pythonie. Od wersji 2.9.0 do 2.14.0 PyJWKSet nie przechwytuje zwykłego ValueError zgłaszanego dla błędnych komponentów RSA JWK przez RSAAlgorithm.from_jwk w jwt/api_jwk.py. Ma to miejsce, gdy zestaw JWK zawiera błędny klucz RSA obok innych użytecznych kluczy. W rezultacie jeden błędny element przerywa konstrukcję całego PyJWKSet.
- CVE-2026-102273Wysokie
PyJWT to implementacja standardów JSON Web Token w Pythonie. Od wersji 2.13.0 do 2.14.0 funkcja HMACAlgorithm.prepare_key jest podatna, ponieważ ochrona klucza HMAC rozpoznaje tylko publiczne formy JWK najwyższego poziomu i pomija reprezentacje kontenerowe. Gdy aplikacja zezwala na algorytmy HMAC i asymetryczne oraz przekazuje publiczny kontener JWK jako surowy klucz, publiczny materiał klucza asymetrycznego jest akceptowany jako sekret HMAC. W rezultacie atakujący znający klucz publiczny może sfałszować token z dowolnymi uwierzytelnionymi oświadczeniami.
- CVE-2026-102272Wysokie
PyJWT to implementacja standardów JSON Web Token w Pythonie. Od wersji 2.13.0 do 2.14.0 funkcja HMACAlgorithm.prepare_key w jwt/algorithms.py jest podatna, ponieważ detektor surowego JWK nie normalizuje akceptowanych znaczników kolejności bajtów Unicode przed sprawdzeniem JSON. Gdy publiczny JWK jest poprzedzony BOM UTF-8 i używany w ścieżce weryfikacji mieszanej algorytmami, publiczny JWK omija wykrywanie klucza asymetrycznego i staje się sekretem HMAC. W rezultacie atakujący znający klucz publiczny może sfałszować uwierzytelnione tokeny.
- CVE-2026-102271Wysokie
PyJWT to implementacja standardów JSON Web Token w Pythonie. Od wersji 2.4.0 do 2.14.0 funkcja HMACAlgorithm.prepare_key jest podatna, ponieważ ochrona klucza asymetrycznego opiera się na znacznikach tekstowych nieobecnych w kodowaniu DER. Gdy aplikacja miesza algorytmy HMAC i asymetryczne oraz dostarcza publiczny klucz DER jako wspólny klucz weryfikacyjny, PyJWT używa publicznych bajtów DER jako sekretu HMAC. W rezultacie atakujący znający klucz publiczny może sfałszować uwierzytelnione tokeny HMAC.
- CVE-2026-102270Średnie
PyJWT to implementacja standardów JSON Web Token w Pythonie. W wersjach przed 2.14.0 funkcja is_pem_format jest podatna, ponieważ leniwe wyrażenie regularne PEM wykonuje rozległe cofanie (backtracking). Ma to miejsce, gdy dane wejściowe przypominające certyfikat zawierają powtarzające się znaczniki BEGIN bez pasującego znacznika END. W rezultacie is_pem_format wykonuje nieograniczone cofanie w poszukiwaniu znacznika końca PEM.
- CVE-2026-102269Średnie
PyJWT to implementacja standardów JSON Web Token w Pythonie. W wersjach przed 2.14.0 segment podpisu PyJWT jest podatny, ponieważ dekodowanie segmentu podpisu akceptuje znaki spoza kanonicznej reprezentacji Base64URL. Ma to miejsce, gdy znaki niebędące Base64URL są dołączane do prawidłowego segmentu podpisu kompaktowego JWS. W rezultacie base64url_decode produkuje te same bajty podpisu dla różnych serializowanych segmentów.
- CVE-2026-102267Wysokie
PyJWT to implementacja standardów JSON Web Token w Pythonie. W wersjach przed 2.14.0 komponent PyJWKClient jest podatny, ponieważ miejsca docelowe przekierowań nie są ponownie weryfikowane względem granicy zaufania JWKS. Gdy skonfigurowany zaufany punkt końcowy JWKS zwraca przekierowanie pod wpływem atakującego, PyJWKClient podąża za przekierowaniem i zużywa przekierowaną odpowiedź jako materiał klucza. W rezultacie przekazywane poświadczenia mogą zostać ujawnione lub klucze weryfikacyjne mogą zostać podmienione.
- CVE-2026-102266Wysokie
PyJWT to implementacja standardów JSON Web Token w Pythonie. Od wersji 2.13.0 do 2.14.0 funkcja HMACAlgorithm.from_jwk jest podatna, ponieważ ścieżka weryfikacji PyJWK używała zdekodowanego klucza bez zastosowania walidacji prepare_key. Gdy zaufany zestaw JWK zawiera wpis oct z pustą wartością k, atakujący podpisuje token HMAC tym samym kluczem o zerowej długości akceptowanym przez PyJWT. W rezultacie sfałszowany token może przenosić dowolne uwierzytelnione oświadczenia.
- CVE-2026-102265Średnie
PyJWT to implementacja standardów JSON Web Token w Pythonie. Od wersji 2.13.0 do 2.14.0 metoda PyJWS._load w jwt/api_jws.py jest podatna, ponieważ parser przechwytuje ValueError, ale nie RecursionError. Ma to miejsce, gdy głęboko zagnieżdżony nagłówek tokenu dociera do json.loads. W rezultacie RecursionError wymyka się z udokumentowanej hierarchii błędów PyJWT.
- CVE-2026-101918Średnie
PyJWT to implementacja standardów JSON Web Token w Pythonie. Od wersji 2.0.0a1 do 2.15.0, funkcja PyJWKClient.get_signing_key_from_jwt jest podatna na błąd, ponieważ parser ładunku przechwytuje wyjątek ValueError, ale nie RecursionError. Dzieje się tak, gdy rekurencyjnie zagnieżdżony ładunek kontrolowany przez atakującego trafia do json.loads. W rezultacie udokumentowana obsługa wyjątków PyJWT nie zawiera tego błędu, co może prowadzić do wygenerowania odpowiedzi HTTP 500 na nieuwierzytelnione żądanie. Problem naprawiono w wersji 2.15.0.
Oryginalny opis (angielski, źródło NVD)
PyJWT is a Python implementation of JSON Web Token standards. From 2.1.0 until 2.15.0, PyJWT OKPAlgorithm.from_jwk in jwt/algorithms.py is affected because private-JWK import path does not compare the public key derived from d with x. This occurs when an OKP private JWK supplies non-corresponding x and d components. As a result, identity derived from x can differ from operations performed with d. Consequently, if an integration also accepts private key parameters from a proof header without rejecting them, an attacker may use a stolen sender-constrained token without the legitimate private key. This issue is fixed in version 2.15.0.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS

