CVE-2026-82759

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ść w bibliotece AshAuthentication (dodatek audit_log) polega na zapisywaniu do dziennika audytu pełnego rekordu użytkownika, w tym atrybutu hashed_password, gdy akcja audytowana jest wywoływana z ustawionym aktorem. Oznaczenie atrybutu jako wrażliwego nie pomaga, ponieważ redakcja dotyczy tylko inspect/1, a nie kodowania JSON ani surowego zapisu. Problem dotyczy wersji od 4.12.0 do 4.15.0 oraz od 5.0.0-rc.0 do 5.0.0-rc.2.

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ść polegająca na niewystarczającym wygaśnięciu sesji w AshAuthentication umożliwia atakującemu, który zdobędzie wartość stanu OAuth2 ofiary, powtórzenie wywołania zwrotnego i zalogowanie ofiary na konto kontrolowane przez atakującego. Wpis sesji nie jest usuwany w przypadku nieudanego uwierzytelnienia z powodu błędnego zakresu w Elixir, więc wartość ochrony CSRF pozostaje przez anulowane lub nieudane próby aż do kolejnego żądania lub wygaśnięcia sesji.

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ść niewystarczającego wygasania sesji w AshAuthentication i AshAuthentication Phoenix pozwala unieważnionej sesji pozostać w pełni uwierzytelnioną. Gdy zasób ma skonfigurowany session_identifier :jti i wyłączone require_token_presence_for_authentication?, wartość sesji jest przechowywana jako <jti>:<subject>, ale czytniki sesji odrzucają jti i przekazują sam subject, nie sprawdzając rekordu unieważnienia. W efekcie sesja przechwycona przed wylogowaniem nadal działa.

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.