Authlib CVE-2026-96760: kiedy brak podpisu zostaje uznany za poprawną weryfikację

CERT/CC opublikował 28 września notę VU#762428 dotyczącą CVE-2026-96760. Wskazuje Authlib do wersji 1.7.2 włącznie: obsługa ogólnej serializacji JSON JWS może zaakceptować pustą listę podpisów jako zweryfikowane dane. Ryzyko dotyczy aplikacji ufających wynikowi tej ścieżki.

Sama obecność Authlib w zależnościach nie dowodzi podatności konkretnej usługi. Trzeba ustalić, jakiego modułu używa aplikacja, jakie formaty przyjmuje i czy niezaufane wejście dociera do wskazanej funkcji. To zadanie dla właściciela aplikacji, a nie tylko osoby aktualizującej plik zależności.

Weryfikacja danych musi poprzedzać nadanie uprawnień

JWS jest formatem opisanym w RFC 7515. W zastosowaniu wymagającym uwierzytelnienia odbiorca powinien zaakceptować treść dopiero po spełnieniu swojej polityki podpisów, algorytmów i zaufanych kluczy. Poprawne odczytanie JSON nie oznacza, że jego zawartość jest zaufana.

Przykład koncepcyjny: usługa odczytuje z komunikatu identyfikator użytkownika i rolę. Jeżeli nada uprawnienie przed potwierdzeniem wymaganego podpisu, wynik parsowania staje się decyzją bezpieczeństwa. Ta sama zasada dotyczy komunikacji między usługami i podpisanych konfiguracji. Błąd walidacji powinien kończyć przetwarzanie, zamiast uruchamiać ścieżkę awaryjną z większym zaufaniem.

Zakres noty i stan wydań to dwa osobne ustalenia

Nota z 28 września informowała o braku oficjalnej poprawki w chwili jej opracowania. Jednocześnie repozytorium projektu zawiera wydanie 1.8.0 z 30 sierpnia. Nie jest to potwierdzenie naprawy tej CVE; nie rozszerzamy też zakresu noty na wszystkie późniejsze wersje.

Wniosek Breachroad: decyzja o zamknięciu zgłoszenia powinna wymagać potwierdzenia, że używany kod nie ma opisanego zachowania. Dowodem może być jednoznaczna informacja producenta wraz ze sprawdzeniem rzeczywistej ścieżki aplikacji. Sam napis „najnowsza wersja” w raporcie skanera nie odpowiada na to pytanie.

Co zespół powinien sprawdzić teraz

Proponujemy następującą kolejność oceny:

1. Ustal faktyczną wersję i moduł w działającej aplikacji, także w obrazach kontenerów i usługach utrzymywanych przez dostawcę.
2. Znajdź miejsca przyjmujące JWS w formacie JSON, w tym wywołania deserialize_json() oraz funkcje automatycznie rozpoznające format.
3. Sprawdź, czy błąd podpisu zatrzymuje nadawanie sesji, ról i uprawnień. Uwzględnij opakowania biblioteki i obsługę wyjątków.
4. Do czasu potwierdzenia bezpieczeństwa ogranicz narażoną ścieżkę lub zastosuj niezależną, sprawdzoną weryfikację zgodną z polityką aplikacji.
5. Zapisz dowód naprawy i sprawdź ponownie odrzucanie brakującego, niepoprawnego lub niezaufanego podpisu w kontrolowanym środowisku.

Kontrola kształtu wejścia może być dodatkowym zabezpieczeniem, lecz nie zastępuje weryfikacji kryptograficznej. Również blokada na brzegu aplikacji nie obejmie automatycznie komunikacji wewnętrznej ani innych usług korzystających z tego samego komponentu.

Wykrywanie i reakcja

Naszą rekomendacją jest zestawienie zdarzeń odrzucenia JWS z logami tworzenia sesji i zmian uprawnień. Warto sprawdzić przypadki, w których aplikacja przyznała dostęp mimo nieudanego etapu walidacji, oraz rozbieżności między tożsamością zgłoszoną a potwierdzoną. Zachowuj identyfikatory korelacyjne i wynik kontroli; pełne tokeny mogą ujawniać dane i nie powinny trafiać do zwykłych logów.

Jeśli analiza wskazuje na przyjęcie niezaufanych danych jako tożsamości, uruchom procedurę incydentową. Zakres unieważnienia sesji i dalszego dochodzenia powinien wynikać z ustalonego wpływu, a nie z samej obecności biblioteki.

Szerszy model kontroli opisujemy w poradniku o bezpieczeństwie JWT i JWKS. Szkolenia dla zespołów IT pomagają przećwiczyć decyzje o zaufaniu, eskalacji i dowodach naprawy.

Fakty źródłowe i wnioski Breachroad

Zakres ostrzeżenia pochodzi z noty CERT/CC, informacje o wydaniu z repozytorium projektu, a model JWS z RFC 7515. Lista kontroli, przykład aplikacji, detekcja i kryteria zamknięcia zgłoszenia są rekomendacjami Breachroad. Artykuł przedstawia stan źródeł sprawdzonych 3 października 2026 roku.