CVE-2026-65633: Purpose-limited JWT accepted as full bearer authentication in AshAuthentication
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.retrievefrombearer/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 requiretokenpresenceforauthentication?: false (the DSL default), the follow-on validatetoken/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: signin 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 currentuser assignment.
This bypasses the library's intended token-exchange contract, in which the signin 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 retrievefrombearer/3 on a reachable route and uses either WebAuthn (sign-in tokens are always issued) or the Password strategy with signintokensenabled?: true. Resources configured with requiretokenpresenceforauthentication?: true (including applications scaffolded by the Igniter installer since v4.5.0) and the session-based path (authenticateresourcefromsession/4) enforce purpose == "user" against the stored token record and are not affected.
This issue affects ashauthentication: from 3.10.5 before 4.14.2 and from 5.0.0-rc.0 before 5.0.0-rc.13.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ash_authenticationto a version that resolves this vulnerability.Fixed in 4.14.2 - Upgrade
Upgrade
ash_authenticationto a version that resolves this vulnerability.Fixed in 5.0.0-rc.13 - Configuration
Update/patch the bearer-token verification logic so that retrieve_from_bearer/3 performs a purpose claim check (purpose == "user") in addition to existing signature verification and act-claim rejection.
AshAuthentication.Plug.Helpers.retrieve_from_bearer/3 (bearer-token authentication helper) purpose claim verification at bearer boundary = Reject bearer JWTs unless purpose == "user" - Configuration
Set require_token_presence_for_authentication?: true for affected resources to enforce purpose == "user" at the stored token record and avoid the vulnerable stateless bearer-token path.
AshAuthentication (resource authentication behavior) require_token_presence_for_authentication? = true
Event History
Frequently Asked Questions
Is the default configuration affected?
Yes. The affected path is reached when require_token_presence_for_authentication? is false, which is the DSL default.
What does an attacker need to use this behavior?
They need a valid, non-expired JWT issued by the library that does not contain an act claim. A purpose-limited token, especially a purpose: sign_in token, can then be submitted in an Authorization: Bearer header.
Which deployments are most exposed?
Resources using stateless bearer-token verification are affected under the default token-presence setting. WebAuthn sign-in flows always emit sign_in tokens, and Password strategy deployments are affected when sign-in tokens are enabled.
What access does a replayed sign-in token obtain?
It is accepted as a general-purpose bearer credential and results in a full current_user assignment, rather than being limited to its intended single-purpose flow.