CVE-2026-88952
KrytyczneCVSS 9.1Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 37 - wyżej niż 37% wszystkich znanych CVE
Streszczenie
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.
Ocena ryzyka
Ryzyko przejęcia kont przez atakującego, co może prowadzić do nieautoryzowanego dostępu do danych i operacji w imieniu ofiary.
Rekomendacja
Zaktualizuj ash_authentication do bezpiecznej wersji (4.15.0 lub nowszej dla serii 4.x oraz 5.0.0-rc.14 lub nowszej dla 5.x), aby naprawić problem.
Inne podatności w ash_authentication
Zobacz wszystkie- CVE-2026-76949Krytyczne
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.
- CVE-2026-91039Krytyczne
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.
- CVE-2026-110826Średnie
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.
- CVE-2026-119215Wysokie
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.
- CVE-2026-118505Średnie
Biblioteka ash_authentication (projekt team-alembic) zawiera podatność niewłaściwego ograniczenia nadmiernej liczby prób uwierzytelniania, pozwalającą nieuwierzytelnionemu atakującemu na nieograniczone zgadywanie haseł i haseł jednorazowych. Strategie hasła, magic link i OTP dodają przygotowanie brute_force_strategy tylko do generowanych akcji, więc gdy zasób definiuje własną akcję, limit nie jest stosowany; dodatkowo przy registration_enabled? true logowanie OTP jest akcją create, na której przygotowania się nie wykonują. Problem dotyczy wersji od 5.0.0-rc.4 przed 5.0.0-rc.16.
- CVE-2026-86688Wysokie
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.
Oryginalny opis (angielski, źródło NVD)
Improper Authentication vulnerability in team-alembic AshAuthentication allows an attacker to be signed in as another user by linking an OAuth2 identity to an account that is not theirs. AshAuthentication.Strategy.OAuth2.UserResolver.resolve/3 matches an existing account using the register action's upsert_identity keys, then gates linking the incoming provider identity to it on email_trusted?/2, which reads only the provider's email_verified boolean and never compares the provider's email value with the matched account's email. That gate assumes the account was matched by its email field, so under any other upsert_identity it is vacuous and an attacker presenting their own verified email is attached to, and issued a session for, an account matched on some other attribute. The same unguarded gate applies in OAuth2.SignInPreparation on the registration_enabled? false path, where the account is matched by the sign-in action's read filter instead. The upsert also rewrites the matched account's email to the attacker's address, so later account recovery reaches the attacker rather than the owner. This issue affects ash_authentication: from 4.14.0 before 4.15.0 and from 5.0.0-rc.10 before 5.0.0-rc.14.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS