CVE-2026-85500 in ash_authentication
Summary
by MITRE • 09/17/2026
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified in AshAuthentication represents a critical authentication bypass flaw that allows unconfirmed users to establish active sessions, thereby circumventing mandatory email confirmation requirements. This issue stems from an incorrect implementation of the logic used to verify user account status during the sign-in process. Specifically, within the AshAuthentication.Strategy.Password.Actions.check_user/2 function, the system attempts to determine if a required attribute for confirming identity is set by using a bare nil comparison against the result of Map.get/2. This approach fails to account for the specific return values used by the underlying Ash framework when fields are not loaded or are restricted by access policies. Consequently, users who have registered but not yet confirmed their email addresses can successfully authenticate and obtain session tokens, undermining the security model that relies on this confirmation step as a primary defense against unauthorized access.
The technical root cause lies in how the application handles missing or inaccessible data fields within the Ash resource layer. When the attribute specified by require_confirmed_with is not selected for loading into the user record, Map.get/2 returns an instance of %Ash.NotLoaded{}. Similarly, if field policies deny access to this specific attribute for the current actor, the function returns %Ash.ForbiddenField{}. The vulnerability exists because both of these structs are distinct from nil. Since the code checks strictly against nil using is_nil(), it incorrectly evaluates these non-nil values as indicating that the confirmation status is not set or irrelevant, effectively skipping the rejection branch intended to block unconfirmed users. This logical error means that under various configuration scenarios where field selection is restricted or policies hide sensitive data, every user is erroneously treated as confirmed regardless of their actual account state.
Furthermore, the enforcement mechanism for require_confirmed_with is inconsistently applied across different invocation paths within the application architecture. The check is implemented only inside AshAuthentication.Strategy.Password.Actions rather than being enforced at the action definition level itself. This architectural choice means that any caller invoking the authentication action directly bypasses the internal validation logic entirely. In typical deployments utilizing API layers such as AshGraphql or AshJsonApi, these services invoke actions directly to handle requests. As a result, the default configuration in many modern applications is inherently vulnerable because the security check is skipped during standard API interactions. Even when checks are present, they rely on the flawed nil comparison logic described above, ensuring that configurations involving selective field loading or restrictive field policies remain susceptible to exploitation.
The operational impact of this vulnerability is significant for any application relying on email confirmation as a means of verifying user identity and preventing automated abuse. Attackers can register accounts without confirming their emails and immediately gain access to session-based features, potentially leading to unauthorized data exposure, account takeover if other weaknesses exist, or the ability to perform actions that require authenticated status but should be restricted until verification is complete. This bypass undermines trust in the authentication system and may violate compliance requirements for applications handling sensitive user information where identity verification is mandatory. The flaw affects versions of ash_authentication from 4.3.8 up to but not including 4.15.0, as well as version 5.0.0-rc.0 through 5.0.0-rc.13 inclusive.
To mitigate this vulnerability, developers must upgrade the AshAuthentication dependency to a patched version where 4.15.0 or later and 5.0.0-rc.14 or later are recommended as safe thresholds. For applications unable to immediately update dependencies, implementing additional validation layers at the API gateway or controller level can help enforce confirmation checks explicitly before session creation is allowed. It is also advisable to review field policies and select configurations to ensure that critical authentication attributes like email confirmation status are always loaded and correctly compared against expected boolean states rather than relying on nil checks which may fail due framework-specific sentinel values. This vulnerability aligns with CWE-287, Improper Authentication, as it involves a failure in the system's ability to reliably verify user identity before granting access privileges. From an ATT&CK perspective, this flaw facilitates Initial Access by allowing adversaries to bypass account verification controls and establish persistent footholds within the application environment without completing required security steps.