CVE-2026-86688

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.

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.