CVE-2026-94613

authentik przed wersjami 2026.2.6 i 2026.5.5 zawiera podatność w konfiguracji SAML Source z trybem dopasowania użytkownika USERNAME_LINK lub EMAIL_LINK. Atakujący może wstawić komentarz XML do NameID, co prowadzi do przejęcia konta ofiary.

Podatność w authentik (dostawca tożsamości) przed wersjami 2025.12.6, 2026.2.4 i 2026.5.1 pozwala na ominięcie etapu źródłowego (Source stage) poprzez wysłanie pustego żądania POST.

Podatność XSS w komponencie AutosubmitStage w authentik (dostawca tożsamości open-source) przed wersjami 2025.12.5 i 2026.2.3, umożliwiająca atakującemu wstrzyknięcie złośliwego skryptu.

W authentik przed 2026.2.7, 2026.5.7 i 2026.8.2, Źródło SAML weryfikuje podpis i okres ważności asercji, ale nie sprawdza, czy dostawca tożsamości wydał asercję dla tego źródła lub w odpowiedzi na żądanie logowania z tego źródła. Ponadto Źródło SAML nie rejestruje już zaakceptowanych asercji, co pozwala na replay. Nieuwierzytelniony atakujący posiadający ważną asercję może jej użyć do uwierzytelnienia się jako inny użytkownik. Dotyczy tylko Źródeł SAML.

W authentik przed 2026.2.7, 2026.5.7 i 2026.8.2, serializatory API zwracają przechowywane poświadczenia, gdy konto ma uprawnienie widoku w dotkniętej konfiguracji, nawet jeśli nie jest upoważnione do zmiany konfiguracji lub odczytu sekretów. Dotyczy to m.in. dostarczania kodów jednorazowych, celów provisioningu, integracji zaufania urządzeń, źródeł tożsamości, integracji Kubernetes i aplikacji używających sekretów. Zagrożone są instalacje, w których przyznano uprawnienia widoku kontom nieprzeznaczonym do odczytu tych poświadczeń.

W authentik przed 2026.2.7, 2026.5.7 i 2026.8.2, konto z delegowanym uprawnieniem do zarządzania grupą, członkostwem w grupie lub użytkownikiem może nadać status superużytkownika lub przypisać istniejącą rolę do grupy bez posiadania odpowiednich uprawnień. Kontrole hierarchii grup nie uwzględniają spójnie statusu superużytkownika dziedziczonego z grup nadrzędnych, a przypisywanie ról do grup nie ma wymaganego sprawdzenia autoryzacji.

W authentik przed 2026.2.7, 2026.5.7 i 2026.8.2, podczas rejestracji czynnika e-mail w procesie uwierzytelniania lub rejestracji, authentik akceptuje adres odbiorcy podany w żądaniu konfiguracji zamiast adresu ustalonego w przepływie. Atakujący znający hasło docelowego użytkownika może podstawić własny adres, otrzymać kod jednorazowy i dokończyć rejestrację czynnika jako docelowy użytkownik. Skuteczna rejestracja daje atakującemu sesję jako docelowy użytkownik i dostęp do aplikacji SSO.

authentik przed wersjami 2026.2.6 i 2026.5.5 udostępnia listę wszystkich skonfigurowanych punktów końcowych Remote Access Control każdemu uwierzytelnionemu użytkownikowi, niezależnie od uprawnień do aplikacji. Odpowiedź zawiera ustawienia połączeń, które mogą zawierać przechowywane poświadczenia. Każdy uwierzytelniony użytkownik może odczytać wszystkie punkty końcowe wraz z hostem i poświadczeniami oraz otworzyć połączenie do punktu końcowego należącego do innej aplikacji, co ujawnia poświadczenia dla zarządzanych celów RDP, SSH i VNC oraz daje interaktywny dostęp do systemów, do których użytkownik nie był autoryzowany.

authentik to dostawca tożsamości open-source. Przed wersjami 2026.2.6 i 2026.5.5, akcja diagnostyczna w API źródła LDAP nie egzekwuje filtra autoryzacji odczytu na poziomie obiektu używanego przez resztę API. Każda strona, która może dotrzeć do API, w tym nieuwierzytelniony klient, może wywołać akcję diagnostyczną przeciwko skonfigurowanemu źródłu LDAP. Serwer następnie łączy się z nadrzędnym katalogiem przy użyciu skonfigurowanych poświadczeń bind źródła i zwraca ograniczony zestaw wpisów katalogu. Odpowiedź ujawnia wyróżnione nazwy tych wpisów oraz nazwy atrybutów na nich obecnych, ujawniając strukturę katalogu, konwencje nazewnictwa oraz istnienie określonych kont i grup, ale nie wartości atrybutów. Wdrożenia bez skonfigurowanego źródła LDAP nie są dotknięte. Problem został naprawiony w wersjach 2026.2.6 i 2026.5.5.

authentik przed wersjami 2026.2.6 i 2026.5.5 w przedsiębiorczych etapach Google Chrome device-trust kontynuuje przepływ bez potwierdzenia, że atestacja urządzenia poza pasmem faktycznie się odbyła. Atakujący, który może dotrzeć do takiego etapu, może pominąć iframe weryfikacyjny i uwierzytelnić się z urządzenia, które nigdy nie zostało zweryfikowane. Tam, gdzie zaufanie do urządzenia jest jedynym dodatkowym czynnikiem, ochrona jest całkowicie pominięta.