CVE-2026-119215
WysokieCVSS 7.6Streszczenie
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.
Ocena ryzyka
Atakujący może przejąć drugi czynnik uwierzytelniania innego użytkownika i zalogować się jako on, co prowadzi do naruszenia konta i obejścia MFA.
Rekomendacja
Zaktualizuj ash_authentication do wersji 5.0.0-rc.16 lub nowszej i przejrzyj polityki autoryzacji dla akcji konfiguracji TOTP.
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-88952Krytyczne
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.
- 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-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)
Authorization Bypass Through User-Controlled Key vulnerability in team-alembic ash_authentication allows a user with an account to install a TOTP secret they control on another user's account, and then sign in as that user or hold their second factor. AshAuthentication.Strategy.Totp.ConfirmSetupChange verified a setup token but did not check that it was issued to the record being confirmed, so an attacker's own pending secret could be confirmed onto another user's record. The TOTP setup changes, ConfirmSetupChange, GeneratePendingSetupChange and GenerateSecretChange, also marked their changesets as AshAuthentication interactions, which the standard AshAuthenticationInteraction policy bypass lets through. A policy limiting setup and confirm_setup to the actor's own record therefore never ran when an application exposed those actions by record key, and a direct setup call on another user's record returned that user's pending secret and setup token. This issue affects ash_authentication: from 5.0.0-rc.0 before 5.0.0-rc.16.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS