CVE-2026-76949
KrytyczneCVSS 9.1Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 41 - wyżej niż 41% wszystkich znanych CVE
Streszczenie
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.
Ocena ryzyka
Atakujący może przejąć sesję ofiary i przechwycić dane wprowadzane po zalogowaniu, co prowadzi do naruszenia poufności i integralności danych.
Rekomendacja
Zaktualizuj bibliotekę ash_authentication do wersji 4.15.0 lub 5.0.0-rc.14 (lub nowszej) i przejrzyj konfigurację require_token_presence_for_authentication?.
Inne podatności w ash_authentication
Zobacz wszystkie- 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-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)
Authentication Bypass by Spoofing vulnerability in team-alembic ash_authentication allows an attacker who can plant a remember-me cookie in a victim's browser to replace that victim's authenticated session with one for the attacker's own account. AshAuthentication.Plug.Helpers.sign_in_using_remember_me/3 skips re-authenticating an already-signed-in visitor by checking the session for "<subject_name>_token", but store_in_session/2 writes that key only when require_token_presence_for_authentication? is enabled and otherwise writes the bare subject name. At the default setting the guard therefore reads a key that is never written, its already-signed-in branch is unreachable, and the remember-me sign-in runs on every request through the per-request browser pipeline plug. A planted remember-me cookie is consequently honoured even for a visitor holding a live authenticated session, so whatever the victim enters afterwards lands in data the attacker controls. The read path in authenticate_resource_from_session/4 selects the key correctly, so the guard and the reader disagree about which key holds the session. This issue affects ash_authentication: from 4.10.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS