CVE-2026-65633
HighCVSS 7.6Exploitation Probability (EPSS)
Low risk29th percentile - higher than 29% of all known CVEs
Summary
A vulnerability in the AshAuthentication library allows one-time JWTs (e.g., WebAuthn sign-in tokens) to be replayed as full bearer API credentials. This is due to missing purpose claim validation in the stateless bearer-token verification path.
Risk Assessment
An attacker who obtains an unused sign-in token (e.g., via log leakage or intercepted magic link) can authenticate as the victim, bypassing one-time-use and revocation semantics. This leads to unauthorized access to user accounts.
Recommendation
Immediately upgrade ash_authentication to version 4.14.2 or later (for 4.x) and to 5.0.0-rc.13 or later (for 5.x). Additionally, if possible, enable require_token_presence_for_authentication?: true in resource configuration.
Other vulnerabilities in AshAuthentication
See all- CVE-2026-86533Critical
Insufficient Session Expiration vulnerability in team-alembic AshAuthentication and AshAuthentication Phoenix allows a revoked session to remain fully authenticated. A resource configured with session_identifier :jti and require_token_presence_for_authentication? disabled stores its session value as <jti>:<subject>, but the session readers discard the jti and pass the bare subject, never consulting the revocation record. As a result, a session captured before sign-out keeps working.
- CVE-2026-85500Critical
Authentication Bypass by Primary Weakness vulnerability in team-alembic AshAuthentication allows an unconfirmed user to obtain a session, defeating a mandatory email confirmation requirement. check_user/2 decides whether the require_confirmed_with attribute is set using a bare is_nil(Map.get(user, value)); when the attribute is not loaded it returns %Ash.NotLoaded{} and when a field policy denies it returns %Ash.ForbiddenField{}, neither of which is nil, so the rejection branch is skipped. Additionally, the check is not enforced when the action is invoked directly by an API layer such as AshGraphql or AshJsonApi.
- CVE-2026-82761Critical
Time-of-check Time-of-use (TOCTOU) Race Condition vulnerability in team-alembic AshAuthentication allows an attacker holding a leaked magic link to replay its single-use token and authenticate as the target subject. Nothing serialises the token's validity check against its consumption, so concurrent redemptions of one token all succeed and each yields a full user token. Revocation happens only after JWT verification, and the revocation is written as an upsert, so a concurrent duplicate revocation silently succeeds.
- CVE-2026-86522Medium
Improper Output Neutralization for Logs vulnerability in team-alembic AshAuthentication allows an unauthenticated attacker to forge application log entries by submitting a password reset identity containing newlines or control characters. AshAuthentication.Strategy.Password.RequestPasswordReset.run/3 interpolates the identity argument into its Logger.warning/1 heredocs without escaping, truncating or type-restricting it. This issue affects ash_authentication: from 4.2.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14.
- CVE-2026-82760High
An inefficient algorithmic complexity vulnerability in AshAuthentication allows an unauthenticated attacker to exhaust CPU and memory via an oversized base62 segment in an API key. The decoding functions have quadratic/cubic complexity and do not limit input length.
- CVE-2026-82759Low
Use of a one-way hash with a predictable salt in team-alembic AshAuthentication allows readers of the audit store to recover client IP addresses that the :hash privacy mode is supposed to pseudonymise. The hash_ip/1 function uses a single unkeyed SHA-256 hash with a salt that defaults to a constant published in the source code, allowing full precomputation of the hash table for the IPv4 address space. Truncation to 16 hex characters does not prevent recovery, and even a properly configured salt can be brute-forced once leaked.
- CVE-2026-82723Low
A vulnerability in the AshAuthentication library (audit_log add-on) causes the full user record, including the hashed_password attribute, to be stored in the audit log when an audited action is invoked with an actor set. Marking the attribute as sensitive does not help because redaction only applies to inspect/1 output, not JSON encoding or raw-term storage. The issue affects versions from 4.12.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.2.
- CVE-2026-82685High
An authorization bypass vulnerability in AshAuthentication allows an authenticated attacker to overwrite and confirm another user's email address, leading to account takeover. A confirmation token issued for one user is accepted on another user's record.
- CVE-2026-81637Low
An insufficient session expiration flaw in AshAuthentication allows an attacker who obtains a victim's OAuth2 state value to replay the callback and sign the victim into an attacker-controlled account. The session entry is never removed on failed authentication paths due to improper Elixir scoping, so the CSRF-protection value persists across cancelled or failed attempts until the next request or session expiry.
- CVE-2026-80218High
An improper authentication vulnerability in AshAuthentication allows an attacker with a sign-in token for one authenticated resource to be signed in as a user of a different resource. The issue arises from incorrect parsing of the sub claim in the JWT token.
Original NVD description (English source)
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.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS