CVE-2026-65633 in ash_authentication
Zusammenfassung
von VulDB • 25.08.2026
Eine Schwachstelle für unsachgemäße Authentifizierung in AshAuthentication von team-alembic ermöglicht es, zweckbeschränkte JWTs (JSON Web Tokens) als vollständige Bearer-API-Anmeldeinformationen wiederzuverwenden, wenn eine Ressource die zustandslose Überprüfung von Bearer-Tokens verwendet.
Der Helper zur Bearer-Token-Authentifizierung `AshAuthentication.Plug.Helpers.retrieve_from_bearer/3` überprüft die Signatur eines `Authorization: Bearer JWT`, lehnt Tokens mit einem `act`-Anspruch (claim) ab, führt jedoch keine Prüfung durch, ob der Zweck-Anspruch des Tokens am Bearer-Grenzwert „user“ entspricht. Wenn die Ressource so konfiguriert ist, dass `require_token_presence_for_authentication?: false` gilt (der Standardwert in der DSL), gibt der nachfolgende Helper `validate_token/3` {:ok, nil} zurück, ohne das Token-Ressource zu konsultieren; daher findet auch keine nachgelagerte Prüfung des Zwecks statt. Infolge dessen wird jedes gültige, nicht abgelaufene JWT, das die Bibliothek selbst für einen engen, einzweckigen Ablauf ausgestellt hat (insbesondere der `purpose: sign_in`-Token, den WebAuthn während der Anmeldung immer ausgibt, sowie der Token, den die Password-Strategie ausgibt, wenn Anmelde-Token aktiviert sind), direkt als Allzweck-Bearer-Anmeldeinformation akzeptiert und führt einer vollständigen Zuweisung von `current_user` zu.
Dies umgeht den beabsichtigten Token-Austauschvertrag der Bibliothek, bei dem der sign_in-Token genau einmal vorgelegt werden soll an eine Vorbereitung, die den Zweck-Anspruch validiert und das Token sofort widerruft. Die erste Verwendung eines noch gültigen Anmelde-Tokens, der direkt im Authorization-Header vorgelegt wird, gelingt, da der zustandslose Bearer-Pfad ihn nicht auf `purpose == "user"` einschränkt.
Ein Angreifer, der einen noch nicht ausgetauschten sign_in-Token für ein Zielsubjekt erlangt (z. B. durch Leckage in Logs oder Referrer-Daten, abgefangene Zustellkanäle für Magic-Links oder eine teilweise kompromittierte Zwischenschicht), kann ihn als Bearer-Token vorlegen und wird als dieses Subjekt authentifiziert, wodurch die beabsichtigte Einmalnutzung und Widerrufssemantik vollständig umgangen wird. Für die Ausnutzung (Exploitation) ist zusätzlich erforderlich, dass die Host-Anwendung `retrieve_from_bearer/3` an einer erreichbaren Route verdrahtet und entweder WebAuthn (Anmelde-Token werden immer ausgestellt) oder die Password-Strategie mit `sign_in_tokens_enabled?: true` verwendet. Ressourcen, die mit `require_token_presence_for_authentication?: true` konfiguriert sind (einschließlich Anwendungen, die vom Igniter-Installer seit v4.5.0 erstellt wurden), sowie der sessionbasierte Pfad (`authenticate_resource_from_session/4`) erzwingen eine Prüfung von `purpose == "user"` gegen den gespeicherten Token-Eintrag und sind nicht betroffen.
Dieses Problem betrifft ash_authentication: ab Version 3.10.5 bis vor 4.14.2 sowie ab 5.0.0-rc.0 bis vor 5.0.0-rc.13.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.