CVE-2026-85500
CriticalCVSS 9.1Summary
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.
Risk Assessment
Unconfirmed users can obtain a fully authenticated session, defeating the email confirmation requirement and potentially leading to unauthorized access. In configurations with an API layer, the issue applies by default.
Recommendation
Upgrade ash_authentication to version 4.15.0 or 5.0.0-rc.14 (or later). Ensure the email confirmation requirement is enforced even when actions are invoked directly by API layers.
Other vulnerabilities in AshAuthentication
See all- 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-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-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.
- CVE-2026-78223Medium
Vulnerability in AshAuthentication library (versions from 0.2.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14) concerning improper verification of cryptographic signature. The token revocation mechanism does not verify signature, allowing an attacker to neutralize revocations or write arbitrary rows into the token resource.
- 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-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-66882Low
A reflected XSS vulnerability in the AshAuthentication library allows an attacker to inject malicious script into HTML pages generated during action confirmation or magic link sign-in. The issue occurs when a strategy has require_interaction enabled and request parameters are embedded into forms without proper escaping.
- CVE-2026-65633High
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.
Original NVD description (English source)
Authentication Bypass by Primary Weakness vulnerability in team-alembic AshAuthentication allows an unconfirmed user to obtain a session, defeating a mandatory email confirmation requirement. AshAuthentication.Strategy.Password.Actions.check_user/2 decides whether the attribute named by require_confirmed_with is set using a bare is_nil(Map.get(user, value)). When that attribute is not selected on the loaded record Map.get/2 returns %Ash.NotLoaded{}, and when a field policy denies it for the current actor it returns %Ash.ForbiddenField{}. Neither is nil, so the rejection branch is skipped and sign-i require_confirmed_with is enforced in two places, and neither holds in every configuration. sign_in_with_token and register are checked only inside AshAuthentication.Strategy.Password.Actions, not on the action itself, so any caller that invokes the action directly skips the check. An API layer such as AshGraphql or AshJsonApi invokes the action directly, so this applies to the default configuration. Where a check does run it compares the confirmation attribute against nil. That attribute holds %Ash.NotLoaded{} or %Ash.ForbiddenField{} when it sets select_by_default?: false, when an API layer narrows the read's select, or when a field policy hides it from the sign-in actor. Neither struct is nil, so those configurations read every user as confirmed. This issue affects ash_authentication: from 4.3.8 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14.