Executive brief
Ash Authentication, a library used to handle user login and authentication in web applications, fails to validate that short-lived, single-purpose login tokens (issued during WebAuthn sign-in or password-based login flows) are only used for their intended purpose. An attacker who obtains a leaked or intercepted sign-in token can use it directly as a general authentication credential to impersonate the target user, completely bypassing the library's one-time-use and automatic token revocation protections.
Technical details
The vulnerability is an improper authentication / token validation bypass in the AshAuthentication.Plug.Helpers.retrieve_from_bearer/3 function. The bearer-token verification path checks the JWT signature and rejects tokens with an act claim, but fails to validate that the token's purpose claim equals "user" at the bearer boundary. When a resource is configured with the default require_token_presence_for_authentication?: false, the downstream validate_token/3 helper returns success without consulting the token resource, so no purpose validation occurs. This allows any valid, non-expired JWT issued for a narrow purpose (notably the purpose: sign_in token from WebAuthn or password sign-in flows) to be accepted directly as a general bearer credential and resolve to a full authenticated user session. The vulnerability requires the host application to wire up retrieve_from_bearer/3 on a reachable route and use either WebAuthn (which always issues sign-in tokens) or the Password strategy with sign_in_tokens_enabled?: true. Applications using require_token_presence_for_authentication?: true or session-based authentication are unaffected. Patches are available in versions 4.14.2 and 5.0.0-rc.13 onwards.
Affected products
- Ash Team AshAuthentication 3.10.5 to 4.14.1, 5.0.0-rc.0 to 5.0.0-rc.12
Timeline
- 2026-08-25: disclosed