The flaw causes the OAuth2 server to expose the state‑changing endpoints /register, /token, and /revoke under both the intended /oauth prefix and an unintended /.well‑known prefix. Because Phoenix forwards without applying the prefix, the same route handlers are available from /.well‑known. This bypasses any path‑scoped controls such as WAF rules, rate limits or authentication exemptions that were defined only for the /oauth paths. An attacker who can reach the application can therefore issue token‑request or revocation calls without triggering the intended safeguards, leading to unauthorized token issuance or forced token revocation. The issue is a CWE‑424 vulnerability.

Any deployment of ash‑project’s ash_authentication_oauth2_server from version 0.1.0 up to and including 0.3.0 is vulnerable. This includes applications that embed the library and rely on the default /oauth mounting without adding custom protections.

The CVSS score of 6.3 classifies the issue as moderately severe. EPSS data is not available, and the vulnerability is not listed in the CISA KEV catalog. The attack vector is straightforward: a network actor can send HTTP POST requests to the exposed /.well‑known endpoints with no special privileges. Because WAF rules, rate limits, or authentication checks written for /oauth do not apply to /.well‑known, the attacker can perform OAuth flows – such as registering clients, obtaining tokens, or revoking tokens – without encountering the intended protections, potentially gaining unauthorized access or disrupting legitimate sessions.