CVE-2026-118505

Podatność w bibliotece ash_authentication (Elixir) pozwala atakującemu, który zdoła umieścić w przeglądarce ofiary ciasteczko remember-me, zastąpić uwierzytelnioną sesję ofiary sesją własnego konta. Problem wynika z niezgodności kluczy sesji używanych przez mechanizm sprawdzający i odczytujący sesję, przez co logowanie remember-me jest wykonywane przy każdym żądaniu.

Podatność w ash_authentication dotyczy strategii dynamic_oidc, która nie zapewnia prawidłowej separacji przestrzeni tożsamości między połączeniami. Atakujący kontrolujący jedno połączenie może zostać zalogowany jako lokalny użytkownik utworzony przez inne połączenie, ponieważ identyfikatory użytkowników nie są odpowiednio rozdzielane.

W ash_authentication występuje błędne uwierzytelnianie, które umożliwia atakującemu zalogowanie się jako inny użytkownik poprzez powiązanie swojej tożsamości OAuth2 z cudzym kontem. Atakujący może przypisać zweryfikowany e-mail do konta wybranego na podstawie innych atrybutów, co prowadzi do przejęcia sesji.

W team-alembic ash_authentication przy włączonej opcji apply_on_password_change warunek zmiany hasła jest oceniany przed ustawieniem nowego skrótu w hooku before_action, przez co dla nieatomowych zmian hasła tokeny użytkownika nie są unieważniane. Atakujący posiadający token sesji ofiary pozostaje zalogowany po zmianie lub resecie hasła.

Podatność obejścia autoryzacji przez klucz kontrolowany przez użytkownika w team-alembic ash_authentication pozwala użytkownikowi z kontem zainstalować kontrolowany przez siebie sekret TOTP na koncie innego użytkownika, a następnie zalogować się jako ten użytkownik lub przejąć jego drugi czynnik. AshAuthentication.Strategy.Totp.ConfirmSetupChange weryfikował token konfiguracji, ale nie sprawdzał, czy został wydany dla potwierdzanego rekordu, więc atakujący mógł potwierdzić własny oczekujący sekret na rekordzie innego użytkownika. Zmiany konfiguracji TOTP, ConfirmSetupChange, GeneratePendingSetupChange i GenerateSecretChange, oznaczały swoje changesety jako interakcje AshAuthentication, które standardowa polityka AshAuthenticationInteraction przepuszcza; polityka ograniczająca setup i confirm_setup do własnego rekordu aktora nigdy nie była uruchamiana, gdy aplikacja udostępniała te akcje po kluczu rekordu, a bezpośrednie wywołanie setup na rekordzie innego użytkownika zwracało jego oczekujący sekret i token konfiguracji. Problem dotyczy ash_authentication od 5.0.0-rc.0 przed 5.0.0-rc.16.

Podatność Session Fixation w team-alembic ash_authentication pozwala atakującemu, który może umieścić identyfikator sesji w przeglądarce ofiary, na przejęcie uwierzytelnionej sesji po zalogowaniu się ofiary. Funkcja AshAuthentication.Plug.Helpers.store_in_session/2 zapisuje uwierzytelniony podmiot do istniejącej sesji bez wywoływania configure_session(renew: true), więc identyfikator, z którym przyszła ofiara, jest przenoszony do sesji uwierzytelnionej. Dotyczy to wszystkich zdarzeń uwierzytelniania, w tym domyślnego success/4, AuthController i automatycznego logowania remember-me. Wylogowanie nie zamyka okna, ponieważ clear_session/2 czyści zawartość sesji, ale pozostawia identyfikator, więc zasadzony identyfikator przetrwa cykl wylogowania i ponownego logowania. Problem dotyczy ash_authentication od 0.2.0 przed 4.15.0 oraz od 5.0.0-rc.0 przed 5.0.0-rc.14.