The vulnerability in ash_authentication arises because the bearer-token authentication helper retrieve_from_bearer/3 verifies JWT signatures and rejects tokens with an 'act' claim but does not verify that the token's 'purpose' claim equals 'user' at the bearer boundary. When the resource is configured with require_token_presence_for_authentication? set to false (default), the validate_token/3 helper returns {:ok, nil} without checking the token's purpose. Consequently, any valid, non-expired JWT issued for a narrow purpose (e.g., sign_in tokens used in WebAuthn or Password strategy with sign_in_tokens_enabled?) can be replayed as a general-purpose bearer token, granting full user authentication. This bypasses the intended token-exchange contract where sign_in tokens are single-use and revoked immediately after validation. Exploitation requires that the application uses retrieve_from_bearer/3 on a reachable route and uses WebAuthn or the Password strategy with sign_in_tokens_enabled?. Applications with require_token_presence_for_authentication? set to true or using session-based authentication enforce purpose checks and are not vulnerable. The affected versions are ash_authentication 3.10.5, all versions from 3.10.5 up to but not including 4.14.2, and 5.0.0-rc.0 up to but not including 5.0.0-rc.13.

An attacker who obtains a valid, not-yet-exchanged sign-in token for a target user can replay it as a bearer token to authenticate as that user, bypassing the intended one-time-use and revocation mechanisms. This allows unauthorized access to the victim's account with full user privileges. The vulnerability requires the attacker to have access to a valid sign-in token (e.g., via log leakage, intercepted magic-link delivery, or compromised intermediaries) and the application to be configured with vulnerable settings. Applications enforcing token presence for authentication or using session-based authentication are not impacted.

Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. In the meantime, applications should ensure that require_token_presence_for_authentication? is set to true, which enforces purpose checks on tokens and prevents this vulnerability. Using session-based authentication paths also mitigates the issue. Avoid using stateless bearer-token verification with the default require_token_presence_for_authentication? false setting until a fix is available.