PHP2Shell : See if you’re affected with a free external attack surface scan. Click Here > 

Back
New CVE Detected

CVE-2026-85500 – Authentication Bypass – Ash Authentication (ash_authentication) 4.3.8–4.14.x and 5.

Be the first to know when new zero-days emerge:

Subscribe to Email Alerts
Subscribe to RSS Feed

Summary

CVE-2026-85500 is an authentication bypass vulnerability (CWE-287, CWE-754) in Ash Authentication (the ash_authentication Elixir library maintained by team-alembic), rated CRITICAL (CVSS v4.0: 9.1). The flaw allows an attacker to register or sign in and obtain a valid authenticated session while completely bypassing the mandatory email confirmation control, meaning accounts can be created and used with emails the attacker does not own or verify.

Technical details

  • Root cause (fail-open validation): The confirmation check in AshAuthentication.Strategy.Password.Actions.check_user/2 determines whether a user is confirmed using a bare is_nil(Map.get(user, value)) comparison against the attribute named by require_confirmed_with. When that attribute is not selected on the loaded record, Map.get/2 returns %Ash.NotLoaded{}; when a field policy denies access to it, it returns %Ash.ForbiddenField{}. Neither struct equals nil, so the check silently treats these users as already confirmed.
  • Root cause (missing enforcement at the action layer): Confirmation checks are only implemented in wrapper functions inside AshAuthentication.Strategy.Password.Actions, not on the underlying sign_in_with_token and register_with_password actions themselves. Callers that invoke these actions directly — including integrations such as AshGraphql and AshJsonApi — skip the confirmation check entirely.
  • Trigger conditions: Applications that configure require_confirmed_with for email/account confirmation, and either (a) do not force-select the confirmation attribute (leaving it unloaded), (b) apply a field policy that hides the confirmation attribute from the acting user, or (c) expose the affected password actions directly through a GraphQL/JSON:API layer rather than only through the built-in wrapper functions/LiveView forms.
  • Attack vector: Network — no authentication or special privileges are required; public self-registration endpoints are typically sufficient to exploit the flaw.
  • Impact: An unauthenticated attacker can register or authenticate using an unverified or spoofed email address and obtain a fully authenticated session, defeating the application’s email-verification security control. This can enable account takeover, impersonation, or unauthorized access to functionality gated behind "confirmed user" status.

Affected software

  • ash_authentication (Elixir/Ash Framework), maintained by team-alembic:
    • >= 4.3.8, <= 4.14.2 (all versions prior to 4.15.0)
    • >= 5.0.0-rc.0, <= 5.0.0-rc.13 (release-candidate track prior to 5.0.0-rc.14)

Severity

  • CVSS v4.0 Base Score: 9.1 (Critical) — Vector: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N
  • Note: The vendor’s GitHub Security Advisory separately scores the same issue as CVSS v3.1: 6.5 (Medium) — Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N. Both scores are published by authoritative sources; the CVE record itself carries the CVSS v4.0 9.1 rating. Security teams should treat this as high-priority given the network-reachable, no-privilege-required nature of the flaw.

Mitigation and recommended actions

  • Immediate: Upgrade ash_authentication to 4.15.0 or later (or 5.0.0-rc.14 or later if on the 5.0 release-candidate track). These releases fix both the fail-open nil comparison and enforce confirmation checks at the action layer.
  • If immediate patching is not possible, apply these workarounds:
    • Do not expose sign_in_with_token or register_with_password actions directly through API layers (e.g., AshGraphql, AshJsonApi) without adding independent, explicit confirmation checks.
    • Ensure the confirmation attribute referenced by require_confirmed_with is always selected by default and is never excluded via select narrowing.
    • Review and remove any field policies that could hide the confirmation attribute from the acting user/actor context.
    • Test sign-in and registration behavior across all exposed routes and API surfaces, not only through default LiveView/UI forms, to confirm unconfirmed users cannot obtain sessions.

References

Are you exposed?

Get a free report of your organization’s exposure to this CVE and threat

  • Mapping of all Assets with this Technology
  • Identification of potentially exposed assets to this CVE
  • Confirmation of verified exploitable assets
Get Exposure Report

How IONIX’s External Exposure Management Platform Detects and Validates
Zero-Days to Shrink MTTR

1

Map your entire attack surface (continously)

IONIX uses multi-factor discovery methods, including DNS analysis, certificate mapping, metadata inspection, and more, to automatically map every internet-facing asset across your environment. This includes cloud instances, third-party platforms, shadow IT, and even forgotten infrastructure that traditional tools miss.

2

Monitor for new CVEs

Dozens of threat intel feeds using agentic technology are continuously analyzed to detect the appearance of proof-of-concept code, exploit kits, and indicators of active targeting. IONIX goes further by applying AI to proactively evaluate whether emerging vulnerabilities are likely to be exploited, even before PoCs go public.

3

Identify Potential External Exposures

Not all CVEs matter. IONIX filters vulnerabilities by asking attacker-centric questions: Can it be reached from the internet? Does it require authentication? Is it being exploited in the wild? This dramatically reduces noise and focuses teams on threats that can actually be weaponized.

4

Create Safe, Scalable Exploit Validations

IONIX transforms real-world PoCs into safe, non-intrusive test payloads that can be run in production environments without disruption. These simulations are precisely targeted to the systems that are vulnerable, ensuring rapid validation without unnecessary load.

5

Execute Exploit Validations

By combining context about software stack, versioning, exposure status, and reachability, IONIX ensures that only the right payloads are executed against the right assets, maximizing efficiency and minimizing risk.

6

Drive Fast and Actionable Remediation

Results are routed through integrations with ticketing, SOAR, and SIEM tools. Issues are written in plain language, bundled into remediation clusters, and prioritized based on asset criticality, exploitability, and blast radius. This shortens mean time to remediation (MTTR) and empowers teams to act with confidence.

Are you exposed?

Get a free report of your organization’s exposure to this CVE and threat

  • Mapping of all Assets with this Technology
  • Identification of potentially exposed assets to this CVE
  • Confirmation of verified exploitable assets
Get Exposure Report
Close

Subscribe to Threat Center RSS

Copy/paste the link below into your preferred RSS reader or follow these instructions to subscribe to Slack alerts.

Open RSS feedSlack setup instructions

Close

Get Real-Time CVE Alerts to Your Email

Be the first to know when new zero-days emerge