CVE-2026-85500: CWE-305 Authentication Bypass by Primary Weakness in team-alembic ash_authentication
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.
AI Analysis
Technical Summary
The vulnerability in ash_authentication's AshAuthentication.Strategy.Password.Actions.check_user/2 function stems from improper handling of the require_confirmed_with attribute. When this attribute is not selected or is hidden due to field policies, the function receives %Ash.NotLoaded{} or %Ash.ForbiddenField{} structs instead of nil. Since the check only tests for nil, these cases bypass the confirmation requirement, allowing unconfirmed users to authenticate. Additionally, enforcement of require_confirmed_with is inconsistent, as some actions like sign_in_with_token and register only check within specific password strategy actions, not on the actions themselves. API layers such as AshGraphql or AshJsonApi invoke these actions directly, skipping the confirmation check entirely in default configurations. This leads to authentication bypass in affected versions.
Potential Impact
An attacker can bypass the mandatory email confirmation step and obtain an authenticated session without confirming their email address. This undermines the intended security control designed to verify user identities before granting access, potentially allowing unauthorized access to protected resources.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. Until an official fix is available, avoid using affected versions or implement additional access controls to compensate for the bypass. Monitor vendor communications for patches or updates addressing this issue.
CVE-2026-85500: CWE-305 Authentication Bypass by Primary Weakness in team-alembic ash_authentication
Description
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.
CVSS v4.0
Score 9.1critical
Affected software
team-alembic
ash_authentication
team-alembic
ash_authentication
pkg:hex/ash_authenticationpkg:github/team-alembic/ash_authenticationcpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*Run on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
Weaknesses
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The vulnerability in ash_authentication's AshAuthentication.Strategy.Password.Actions.check_user/2 function stems from improper handling of the require_confirmed_with attribute. When this attribute is not selected or is hidden due to field policies, the function receives %Ash.NotLoaded{} or %Ash.ForbiddenField{} structs instead of nil. Since the check only tests for nil, these cases bypass the confirmation requirement, allowing unconfirmed users to authenticate. Additionally, enforcement of require_confirmed_with is inconsistent, as some actions like sign_in_with_token and register only check within specific password strategy actions, not on the actions themselves. API layers such as AshGraphql or AshJsonApi invoke these actions directly, skipping the confirmation check entirely in default configurations. This leads to authentication bypass in affected versions.
Potential Impact
An attacker can bypass the mandatory email confirmation step and obtain an authenticated session without confirming their email address. This undermines the intended security control designed to verify user identities before granting access, potentially allowing unauthorized access to protected resources.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. Until an official fix is available, avoid using affected versions or implement additional access controls to compensate for the bypass. Monitor vendor communications for patches or updates addressing this issue.
Technical Details
- Data Version
- 5.2
- Assigner Short Name
- EEF
- Date Reserved
- 2026-09-07T23:45:01.895Z
- Cvss Version
- 4.0
- State
- PUBLISHED
Threat ID: 6aabe86855bf5e2cf56c51c6
Added to database: 09/17/2026, 13:17:28 UTC
Last enriched: 09/17/2026, 13:31:34 UTC
Last updated: 09/18/2026, 00:47:19 UTC
Views: 13
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.