CVE-2026-82754: Ash Authentication OAuth2 Auth Bypass Vulnerability

CVE-2026-82754 Overview

CVE-2026-82754 is an Improper Protection of Alternate Path vulnerability [CWE-424] in the ash_authentication_oauth2_server library maintained by the ash-project. The library forwards the same ProtocolRouter at both the /oauth prefix and the /.well-known prefix. Because Phoenix strips the matched prefix before dispatch, state-changing OAuth endpoints such as POST /register, POST /token, and POST /revoke become reachable under /.well-known/register, /.well-known/token, and /.well-known/revoke. Edge controls scoped to /oauth do not apply to the alias. Versions from 0.1.0 before 0.3.1 are affected.

Critical Impact
Web application firewall (WAF) rules, rate limits, and authentication exemptions bound to the canonical /oauth prefix can be bypassed by routing identical requests through the /.well-known alias.

Affected Products

ash-project/ash_authentication_oauth2_server versions 0.1.0 through 0.3.0
Elixir Phoenix applications using AshAuthentication.Phoenix.Oauth2Server.Router
Deployments relying on edge controls scoped to the /oauth prefix

Discovery Timeline

2026-09-07 - CVE-2026-82754 published to NVD
2026-09-08 - Last updated in NVD database

Technical Details for CVE-2026-82754

Vulnerability Analysis

The flaw resides in oauth2_server_protocol_routes/1 within AshAuthentication.Phoenix.Oauth2Server.Router. The function forwards the same ProtocolRouter plug at two mounts: /oauth for the full OAuth route table and /.well-known for metadata discovery documents. Phoenix's forward macro strips the matched prefix before handing the connection to the downstream router. Both mounts therefore evaluate the identical route table.

As a result, state-changing endpoints intended only for the /oauth mount answer under /.well-known as well. POST /.well-known/register, POST /.well-known/token, and POST /.well-known/revoke execute the same handlers as their canonical counterparts. This directly undermines defense-in-depth assumptions common in production deployments.

Root Cause

The root cause is a routing configuration that reuses a single plug for two semantically distinct mounts without discriminating between them. The /.well-known prefix is conventionally treated as unauthenticated metadata surface. When operators write WAF rules, rate limits, or auth exemptions against path prefixes, the alias silently receives traffic that bypasses those controls.

Attack Vector

An unauthenticated remote attacker sends OAuth protocol requests to the /.well-known alias instead of /oauth. Because the alias is often allow-listed as unauthenticated metadata, requests may skip WAF inspection, rate limiting, and authentication exemptions. The attacker can invoke client registration, token issuance, and token revocation flows through an unprotected path.

text

# Patch: lib/ash_authentication_phoenix/oauth2_server/protocol_router.ex
     json_decoder: Jason
 
   plug :match
+  plug :restrict_well_known_mount
   plug :dispatch
 
+  # The metadata discovery documents — the only routes allowed to answer under
+  # the `/.well-known` mount (see the `well_known?` forward in the Router).
+  @well_known_paths [
+    ["oauth-authorization-server"],
+    ["openid-configuration"],
+    ["oauth-protected-resource"]
+  ]
+
+  defp restrict_well_known_mount(conn, _opts) do
+    well_known? = Keyword.get(conn.assigns.oauth2_server_router_opts, :well_known?, false)
+
+    if well_known? and not (conn.method == "GET" and conn.path_info in @well_known_paths) do
+      conn |> send_resp(404, "") |> halt()
+    else
+      conn
+    end
+  end

Source: GitHub Commit a72972d. The patch adds a restrict_well_known_mount plug that returns 404 for any non-metadata request arriving through the /.well-known mount.

Detection Methods for CVE-2026-82754

Indicators of Compromise

HTTP POST requests to /.well-known/register, /.well-known/token, or /.well-known/revoke in access logs
Successful OAuth token issuance or client registration events with source paths under /.well-known
Traffic to /.well-known/* endpoints that returns non-metadata content types before patching

Detection Strategies

Parse web server and reverse proxy logs for any HTTP method other than GET targeting /.well-known/* paths on hosts running ash_authentication_oauth2_server
Correlate OAuth audit events (client registered, token issued, token revoked) against the request path to flag events sourced from /.well-known
Compare request volume between /oauth/* and /.well-known/* for the same operation names to identify anomalous alias traffic

Monitoring Recommendations

Enable structured request logging that preserves the full request path prior to any prefix normalization
Forward OAuth server logs to a central analytics platform and alert on state-changing verbs at /.well-known
Add synthetic checks that probe both prefixes post-deployment and assert that only metadata GET responses succeed under /.well-known

How to Mitigate CVE-2026-82754

Immediate Actions Required

Upgrade ash_authentication_oauth2_server to version 0.3.1 or later
Audit WAF, API gateway, and reverse proxy rules to confirm they cover both /oauth/* and /.well-known/* on affected hosts
Review OAuth server logs for prior POST requests to /.well-known/register, /.well-known/token, or /.well-known/revoke

Patch Information

The fix is delivered in commit a72972d7ed3eb74c05dfa0653a258ef14454459a and is available in release 0.3.1. See the GitHub Security Advisory GHSA-wwxg-h779-3wf4 and the CNA CVE-2026-82754 Report for full details.

Workarounds

Add a reverse proxy or WAF rule that denies any non-GET method under /.well-known/*
Restrict /.well-known/* to the three metadata paths: oauth-authorization-server, openid-configuration, and oauth-protected-resource
Apply the same authentication, rate limiting, and inspection policies to /.well-known/* that are enforced on /oauth/* until the upgrade is complete

bash

# Example nginx rule blocking non-GET methods under /.well-known
location ^~ /.well-known/ {
    limit_except GET {
        deny all;
    }
}

# Update the dependency in mix.exs
# {:ash_authentication_oauth2_server, "~> 0.3.1"}
mix deps.update ash_authentication_oauth2_server