CVE-2026-114617

Authlib w wersji 1.7.2 i niższych zawiera podatność, w której metadane JSON discovery są buforowane bez walidacji lub powiązania z originem issuera. Pozwala to zatrutemu discovery response na zastąpienie wszystkich wartości endpointów wartościami kontrolowanymi przez atakującego, zamiast URL endpointów współdzielących origin ze skonfigurowanym URL metadanych serwera.

Biblioteka Authlib w wersji v1.7.2 i wcześniejszych zawiera podatność polegającą na obejściu weryfikacji podpisu. Metoda JsonWebSignature.deserialize_json() akceptuje obiekt JWS w formacie JSON Serialization i zwraca ładunek jako pomyślnie zweryfikowany bez sprawdzania podpisu i bez wymagania klucza kryptograficznego.

Podatność w bibliotece Authlib (wersje przed 1.6.9) umożliwia atakującemu wstrzyknięcie klucza JWK do nagłówka JWT. Pozwala to na podrobienie dowolnego tokena JWT, który przechodzi weryfikację podpisu, ponieważ biblioteka używa klucza dostarczonego przez atakującego zamiast zaufanego klucza serwera.

Biblioteka Authlib w wersjach od 1.6.5 do 1.6.6 nieprawidłowo przepuszczała złośliwe tokeny JWT z algorytmem 'none' i pustym podpisem, co omijało weryfikację podpisu. Problem został naprawiony w wersji 1.6.7.

Authlib (biblioteka Python do OAuth/OIDC) w wersjach od 0.15 do 1.9.1 zawiera błąd w implementacjach ClientConfigurationEndpoint.authenticate_client i check_permission, które nie weryfikują, czy poświadczenie należy do docelowego klienta. Może to pozwolić na odczyt, modyfikację lub usunięcie rejestracji innego klienta. Problem naprawiono w wersji 1.9.1.

W bibliotece Authlib przed wersją 1.9.0 implementacja RFC 9101 JWTAuthenticationRequest przekazuje kontrolowany przez klienta parametr request_uri do hooka get_request_object() przed zastosowaniem polityki docelowej lub rejestracyjnej. W instalacjach, w których integrator zaimplementował ten hook jako nieograniczone pobieranie HTTP, zdalny atakujący może wymusić żądania do wewnętrznych lub niepożądanych adresów URL.

W Authlib przed wersją 1.9.0 metoda OpenIDImplicitGrant.validate_authorization_request() sprawdza kontrolowany przez klienta surowy parametr request.payload.scope pod kątem openid po tym, jak nadrzędny grant przefiltrował dozwolone zakresy do request.scope. Zarejestrowany klient uprawniony do typu odpowiedzi ID token, ale nie do zakresu openid, może dodać openid i otrzymać podpisany ID token z danymi użytkownika.

W Authlib przed wersją 1.9.0 domyślna metoda RFC 7523 JWTBearerGrant.get_audiences() zwraca pustą listę, przez co weryfikacja roszczeń wymaga jedynie istnienia roszczenia aud bez dopasowania do bieżącego serwera autoryzacji. Atakujący posiadający ważną asercję dla innej usługi może przedstawić ją serwerowi współdzielącemu klucz podpisujący i uzyskać token dostępu.

Authlib to biblioteka Pythona do budowy serwerów OAuth i OpenID Connect. W wersjach przed 1.9.1 funkcje OctKey.import_key() oraz ścieżka podpisywania i weryfikacji HMAC akceptują klucz o zerowej długości, co pozwala zdalnemu atakującemu obliczyć deterministyczny podpis HS256, HS384 lub HS512 dla dowolnych roszczeń tokenu i uznać token za autentyczny. Problem naprawiono w wersji 1.9.1.

Authlib to biblioteka Pythona do budowy serwerów OAuth i OpenID Connect. W wersjach od 1.3.1 do 1.9.0 funkcja OctKey.import_key() sprawdza znaczniki kluczy asymetrycznych tylko na bajcie zerowym, podczas gdy loadery PEM akceptują wiodące białe znaki, komentarze lub BOM. W konfiguracjach z mieszanym rejestrem algorytmów nieuwierzytelniony atakujący znający te same bajty klucza publicznego może użyć ich jako sekretu HMAC i sfałszować tokeny HS256 z dowolnymi roszczeniami. Problem naprawiono w wersji 1.9.0.