CVE-2026-86533

Podatność niewłaściwej neutralizacji danych wyjściowych w logach w team-alembic AshAuthentication pozwala nieuwierzytelnionemu atakującemu sfałszować wpisy logów aplikacji poprzez przesłanie tożsamości resetowania hasła zawierającej znaki nowej linii lub znaki kontrolne. Funkcja AshAuthentication.Strategy.Password.RequestPasswordReset.run/3 interpoluje argument tożsamości do szablonów Logger.warning/1 bez escapowania, obcinania lub ograniczenia typu, co pozwala atakującemu wybrać tag ważności i treść wpisów. Problem dotyczy ash_authentication od 4.2.0 przed 4.15.0 oraz od 5.0.0-rc.0 przed 5.0.0-rc.14.

Podatność typu „Inefficient Algorithmic Complexity” w AshAuthentication umożliwia nieuwierzytelnionemu atakującemu wyczerpanie CPU i pamięci przez przesłanie zbyt dużego segmentu base62 w kluczu API. Funkcje dekodujące mają złożoność kwadratową/sześcienną i nie ograniczają długości wejścia.

Podatność „Authorization Bypass Through User-Controlled Key” w AshAuthentication pozwala uwierzytelnionemu atakującemu na nadpisanie i potwierdzenie adresu e-mail innego użytkownika, co prowadzi do przejęcia konta. Token potwierdzający wydany dla jednego użytkownika jest akceptowany dla innego.

Podatność „Improper Authentication” w AshAuthentication pozwala osobie posiadającej token logowania dla jednego zasobu na zalogowanie się jako użytkownik innego zasobu. Problem wynika z nieprawidłowego parsowania klauzuli sub w tokenie JWT.

Podatność w bibliotece AshAuthentication (wersje od 0.2.0 do przed 4.15.0 oraz od 5.0.0-rc.0 do przed 5.0.0-rc.14) dotyczy nieprawidłowej weryfikacji podpisu kryptograficznego. Mechanizm unieważniania tokenów nie sprawdza podpisu, co pozwala atakującemu na neutralizację unieważnienia lub wstawienie dowolnych wierszy do zasobu tokenów.

Podatność obejścia uwierzytelniania przez słabość podstawową w AshAuthentication pozwala niepotwierdzonemu użytkownikowi uzyskać sesję, omijając obowiązkowe potwierdzenie adresu e-mail. Funkcja check_user/2 sprawdza atrybut require_confirmed_with za pomocą is_nil(Map.get(user, value)), ale gdy atrybut nie jest załadowany zwracany jest %Ash.NotLoaded{}, a gdy polityka pola go ukrywa — %Ash.ForbiddenField{}; żadna z tych wartości nie jest nil, więc gałąź odrzucenia jest pomijana. Dodatkowo sprawdzenie nie jest wykonywane, gdy akcja jest wywoływana bezpośrednio przez warstwę API, taką jak AshGraphql lub AshJsonApi.

Podatność wyścigu typu time-of-check time-of-use (TOCTOU) w AshAuthentication pozwala atakującemu posiadającemu wyciekły magic link na wielokrotne użycie jednorazowego tokenu i uwierzytelnienie się jako docelowy podmiot. Nic nie serializuje sprawdzenia ważności tokenu względem jego zużycia, więc równoczesne użycia tego samego tokenu kończą się sukcesem, a każde zwraca pełny token użytkownika. Unieważnienie następuje dopiero po weryfikacji JWT, a zapis unieważnienia jako upsert pozwala równoczesnemu duplikatowi zakończyć się sukcesem.

Podatność XSS (reflected) w bibliotece AshAuthentication umożliwia atakującemu wstrzyknięcie złośliwego skryptu do strony HTML generowanej podczas potwierdzania akcji lub logowania przez magic link. Problem występuje, gdy strategia ma włączoną opcję require_interaction, a parametry żądania są osadzane w formularzach bez odpowiedniego kodowania.

Podatność w bibliotece AshAuthentication umożliwia ponowne użycie jednorazowych tokenów JWT (np. tokenów logowania WebAuthn) jako pełnych poświadczeń API. Wynika to z braku weryfikacji celu tokenu (purpose) w ścieżce bezstanowej weryfikacji tokenów bearer.