CVE-2026-65633 in ash_authentication
Summary
by MITRE • 08/25/2026
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.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/25/2026
The vulnerability identified in the AshAuthentication library represents a critical failure in authentication logic, specifically classified under CWE-287: Improper Authentication. This flaw allows an attacker to bypass intended security controls by replaying purpose-limited JSON Web Tokens as full bearer API credentials. The core technical issue lies within the stateless bearer-token verification mechanism implemented in the AshAuthentication.Plug.Helpers.retrieve_from_bearer/3 function. While this helper correctly verifies the cryptographic signature of a provided Authorization Bearer JWT and explicitly rejects tokens containing an act claim, it fails to validate that the token's purpose claim matches the expected value for user authentication at the boundary layer. This omission creates a significant gap in the security posture, as the system accepts any valid, non-expired JWT issued by the library itself, regardless of its intended scope or lifecycle stage.
The operational impact is exacerbated by default configuration settings within the framework. When a resource is configured with require_token_presence_for_authentication set to false, which serves as the DSL default in many setups, the subsequent validate_token/3 helper returns an ok status with nil without consulting the token resource database. Consequently, no downstream validation of the purpose claim occurs during this stateless flow. This design flaw means that narrow, single-purpose tokens are inadvertently elevated to general-purpose bearer credentials. Specifically, sign-in tokens generated by WebAuthn flows or Password strategies when sign_in_tokens_enabled is true can be misused. These tokens are designed for one-time use and immediate exchange into a full session token, but the flawed verification logic allows them to bypass this contract entirely.
An attacker who obtains a not-yet-exchanged sign-in token through various vectors such as log leakage, referrer header exposure, or interception of magic-link delivery channels can exploit this vulnerability. By presenting the stolen sign-in token directly in the Authorization header of an API request, the attacker is authenticated as the target subject without needing to complete the proper token exchange process. This effectively neutralizes the one-time-use and revocation semantics that are central to secure authentication flows. The exploitation requires specific conditions: the host application must wire up retrieve_from_bearer/3 on a reachable route, and it must utilize either WebAuthn or the Password strategy with sign-in tokens enabled. Resources configured with require_token_presence_for_authentication set to true, including those scaffolded by Igniter since version 4.5.0, are not affected because they enforce purpose validation against stored token records.
From a threat intelligence perspective, this vulnerability aligns with MITRE ATT&CK technique T1078: Valid Accounts, specifically the aspect of using legitimate credentials to gain unauthorized access. The attacker leverages validly issued tokens but misuses them outside their intended context, which is a form of privilege escalation through token misuse. To mitigate this risk, organizations must ensure that all API endpoints relying on stateless bearer authentication implement strict purpose claim validation at the entry point. Developers should review their AshAuthentication configurations to verify whether require_token_presence_for_authentication is enabled for resources handling sensitive data. Upgrading to patched versions of the library is essential; specifically, updates beyond version 4.14.2 and version 5.0.0-rc.13 address this issue by enforcing proper purpose checks in the bearer token verification path. Until patches are applied, implementing a custom authentication plug that explicitly validates the purpose claim before proceeding with user resolution can serve as an effective compensating control to prevent unauthorized access via replayed sign-in tokens.