VDB
Sign up

EEF-CVE-2026-85500

`require_confirmed_with` is not enforced on the action and fails open on an unreadable attribute in AshAuthentication

Quick fix

EEF-CVE-2026-85500 — ash_authentication: upgrade to the fixed version with the command below.

mix deps.update ash_authentication

Details

## Summary

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.

Are you affected?

Enter the version of the package you're using.

Affected packages

Hex/ash_authentication
Introduced in: 4.3.8Fixed in: 4.15.0
Fixmix deps.update ash_authentication

References