EEF-CVE-2026-65633

## Summary

Improper Authentication vulnerability in team-alembic AshAuthentication allows purpose-limited JWTs to be replayed as full bearer API credentials when a resource uses stateless bearer-token verification.

The bearer-token authentication helper `AshAuthentication.Plug.Helpers.retrieve_from_bearer/3` verifies an `Authorization: Bearer` JWT's signature and rejects tokens containing an `act` claim, but performs no check that the token's `purpose` claim equals `user` at the bearer boundary. When the resource is configured with `require_token_presence_for_authentication?: false` (the DSL default), the follow-on `validate_token/3` helper returns `{:ok, nil}` without consulting the token resource, so no downstream check on `purpose` takes place either. As a result, any valid, non-expired JWT the library itself issued for a narrow, single-purpose flow (most notably the `purpose: sign_in` token that WebAuthn always emits during sign-in, and that the Password strategy emits when sign-in tokens are enabled) is accepted directly as a general-purpose bearer credential and resolves to a full `current_user` assignment.

This bypasses the library's intended token-exchange contract, in which the `sign_in` token is meant to be presented exactly once to a preparation that validates the `purpose` claim and immediately revokes the token. The first use of a still-valid sign-in token presented directly in the `Authorization` header succeeds because the stateless bearer path never scopes it to `purpose == "user"`.

An attacker who obtains a not-yet-exchanged sign-in token for a target subject (for example via log or referrer leakage, an intercepted magic-link delivery channel, or a partially compromised intermediary) can present it as a bearer token and be authenticated as that subject, fully bypassing the intended one-time-use and revocation semantics. Exploitation additionally requires that the host application wire up `retrieve_from_bearer/3` on a reachable route and uses either WebAuthn (sign-in tokens are always issued) or the Password strategy with `sign_in_tokens_enabled?: true`. Resources configured with `require_token_presence_for_authentication?: true` (including applications scaffolded by the Igniter installer since v4.5.0) and the session-based path (`authenticate_resource_from_session/4`) enforce `purpose == "user"` against the stored token record and are not affected.

This issue affects ash_authentication: from 3.10.5 before 4.14.2 and from 5.0.0-rc.0 before 5.0.0-rc.13.

## Configurations

The bypass is reachable only when a resource uses stateless bearer-token verification, i.e. `require_token_presence_for_authentication?` is `false` (the DSL default). In that mode `validate_token/3` returns `{:ok, nil}` without consulting the token resource, so the JWT's `purpose` claim is the only remaining scoping signal at the bearer boundary and it is never checked. When `require_token_presence_for_authentication?` is `true`, `validate_token/3` looks the token up with `get_token(%{"jti" => jti, "purpose" => "user"})`; purpose-limited tokens are stored under their own purpose (`sign_in`, `remember_me`, ...), so that lookup fails and those tokens are rejected. Applications scaffolded by the Igniter installer since v4.5.0 default to `require_token_presence_for_authentication?: true` and are therefore not exposed as generated; applications configured manually or that deliberately opt into stateless JWT verification are.

Exploitation additionally requires the host application to wire up `AshAuthentication.Plug.Helpers.retrieve_from_bearer/3` on a route the attacker can reach, and to use a strategy that issues purpose-limited JWTs carrying a resolvable `sub` claim: either the WebAuthn strategy (sign-in tokens are always emitted, no opt-in required) or the Password strategy with `sign_in_tokens_enabled?: true`. The session-based path (`authenticate_resource_from_session/4`) already enforces `purpose == "user"` against the token resource and is not affected.