ash_authentication_oauth2_server CVE-2026-82754

Exploitation requires that the target deployment has configured edge controls - WAF rules, rate-limiting policies, IP allow/block lists, or authentication requirements - scoped specifically to the /oauth URL prefix while simultaneously treating /.well-known paths as trusted or unauthenticated (a common posture given the RFC 5785 metadata convention). Deployments that apply no path-differentiated edge controls, or that apply identical controls to both prefixes, are not exposed to additional risk: both paths were always equally reachable at the application layer. The application-level OAuth protocol authentication (client credentials, bearer tokens) remains intact and limits the impact even where the bypass succeeds. Exploitation is further bounded to the three state-changing endpoints: /register, /token, and /revoke; metadata discovery GETs under /.well-known were intentionally correct before the fix.

The CVSS 4.0 score of 6.3 with AT:P (Attack Requirements: Present) accurately captures that exploitation is conditional rather than universal: deployments with no path-differentiated edge controls face no incremental risk because both URL prefixes were already equally exposed to the underlying application. The real exposure is narrower but operationally significant - any operator who believed WAF-enforced rate limits or path-scoped authentication challenges on /oauth/token or /oauth/register were hardening their OAuth server was unknowingly operating with an open alias; even a mid-sized municipal IT team in gliwice running a public-facing OAuth2 authorization server with per-path WAF rules would find those controls trivially circumvented by substituting the /.well-known prefix. EPSS data was not provided, and the absence of a KEV listing and public exploit code suggests no confirmed mass exploitation; however, the bypass is reconstructable directly from the public advisory and commit diff, making it low-effort for a motivated attacker once they are aware of the target library. The integrity impact is rated low (VI:L) because application-level OAuth authentication - client credentials, token validation - remains fully in force; the flaw removes an edge enforcement layer, not application-level access control.

An attacker scanning a Phoenix application observes that POST /.well-known/token returns an OAuth protocol response rather than a 404, indicating the /.well-known alias is active. The attacker submits repeated token-endpoint requests to /.well-known/token - bypassing WAF rate-limiting rules written against /oauth/token - to brute-force client credentials or enumerate valid grant flows without triggering configured throttles. No public exploit code exists, but the attack is trivially constructable from the public advisory and commit diff.