AshAuthentication CVE-2026-65633

Exploitation requires three simultaneous conditions: (1) the host application must wire up AshAuthentication.Plug.Helpers.retrieve_from_bearer/3 on at least one reachable route; (2) the application must use either the WebAuthn strategy (which always issues sign-in tokens) or the Password strategy configured with sign_in_tokens_enabled?: true; and (3) the attacker must obtain a still-valid, not-yet-exchanged sign-in token for the target subject before it is consumed. Tokens expire according to the configured TTL, narrowing the exploitation window. The following configurations are NOT affected and limit real-world exposure significantly: resources with require_token_presence_for_authentication?: true (the Igniter installer default since v4.5.0); applications using the session-based authentication path (authenticate_resource_from_session/4); applications using neither WebAuthn nor the Password strategy with sign_in_tokens_enabled?: true; and tokens that have already been exchanged or have expired. The require_token_presence_for_authentication?: false DSL default is the enabling condition.

The CVSS 4.0 score of 7.6 (AV:N/AC:H/AT:P/PR:N/UI:P) accurately reflects the constrained but non-trivial attack surface. High complexity (AC:H) and a specific precondition (AT:P) are warranted: the attacker must obtain a still-valid, not-yet-exchanged sign-in token before it is consumed. This is a realistic but targeted threat - the window of opportunity is the token's lifetime between issuance and first use. The requiring of user interaction (UI:P) reflects that a legitimate user must initiate the sign-in flow that generates the interceptable token. Confidentiality and integrity impacts are High (VC:H/VI:H) since successful exploitation yields a fully authenticated current_user session, enabling the attacker to act as the victim with all their application privileges. There is no availability impact. No CISA KEV listing and no public exploit code identified - this is not currently mass-exploited. However, the vulnerability is particularly dangerous in applications using WebAuthn, because sign-in tokens are always issued in that flow, broadening the exposure compared to the opt-in Password strategy case. Applications scaffolded by Igniter since v4.5.0 with require_token_presence_for_authentication?: true are structurally protected and are not at risk.

An attacker targeting a user who has initiated a WebAuthn sign-in flow intercepts the resulting sign-in JWT before it is consumed - for example by capturing it from a server access log, an HTTP Referer header, or a compromised email or SMS delivery channel for a magic link. The attacker then presents this token in an Authorization: Bearer <token> header directly to any API endpoint protected by retrieve_from_bearer/3. Because the stateless bearer path never checks purpose, the token is accepted as a valid full-session credential and the attacker receives a current_user assignment, effectively authenticated as the victim with no further interaction required from the legitimate user.