CVE-2026-81637

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.

Użycie jednokierunkowego hasha z przewidywalną solą w AshAuthentication (team-alembic) umożliwia czytelnikom magazynu audytu odzyskanie adresów IP klientów, które tryb prywatności :hash ma pseudonimizować. Funkcja hash_ip/1 używa pojedynczego niekluczowanego hasha SHA-256 z solą, która domyślnie jest stałą wartością opublikowaną w źródle, pozwalając na pełną prekomputację tablicy dla przestrzeni IPv4. Skrócenie do 16 znaków heksadecymalnych nie zapobiega odzyskaniu, a nawet poprawnie skonfigurowana sól może zostać odgadnięta po wycieku.

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ść „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.