CVE-2026-82754: ash_authentication_oauth2_server aliases every protocol endpoint under /.well-known, bypassing path-scoped controls
Improper Protection of Alternate Path vulnerability in ash-project ashauthenticationoauth2server exposes the state-changing OAuth endpoints under an unintended URL prefix, bypassing controls scoped to the canonical prefix.
oauth2serverprotocolroutes/1 in AshAuthentication.Phoenix.Oauth2Server.Router forwards the same ProtocolRouter at both the /oauth prefix and the /.well-known prefix. Phoenix forward strips the matched prefix before dispatch, so the full route table answers under both mounts, and POST /register, POST /token, and POST /revoke are reachable as /.well-known/register, /.well-known/token, and /.well-known/revoke. Edge controls such as WAF rules, rate limits, or authentication exemptions written against the /oauth paths, or that allow-list /.well-known as unauthenticated, do not apply to the alias.
This issue affects ashauthenticationoauth2server: from 0.1.0 before 0.3.1.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ash-project/ash_authentication_oauth2_serverto a version that resolves this vulnerability.Fixed in 0.3.1 - Configuration
Modify oauth2_server_protocol_routes/1 so the same ProtocolRouter is not mounted/forwarded under both the /oauth prefix and the /.well-known prefix; do not alias protocol endpoints under /.well-known.
AshAuthentication.Phoenix.Oauth2Server.Router (oauth2_server_protocol_routes/1) route mounting/aliasing for protocol endpoints = Ensure ProtocolRouter is not forwarded at both /oauth and /.well-known (remove /.well-known alias for OAuth endpoints) - Compensating control
Treat /oauth and the alternate alias paths (e.g., /.well-known/register, /.well-known/token, /.well-known/revoke) equivalently in edge controls (WAF rules, rate limits, and authentication requirements); do not rely on controls scoped only to the canonical /oauth prefix or allow-list /.well-known as unauthenticated.
Event History
Frequently Asked Questions
Which deployments are exposed to this bypass?
Deployments using ash_authentication_oauth2_server versions from 0.1.0 before 0.3.1 are affected. Exposure is especially relevant where WAF rules, rate limits, authentication exemptions, or other edge controls are scoped to /oauth paths while /.well-known is treated differently or allow-listed.
What does an attacker need to exploit the issue?
An attacker only needs to send requests to the alternate /.well-known paths for protocol endpoints, such as POST /.well-known/register, POST /.well-known/token, or POST /.well-known/revoke. The bypass matters when protections applied to the corresponding /oauth endpoints do not also apply to these aliases.
How can I check whether controls are being bypassed?
Test whether POST requests to /.well-known/register, /.well-known/token, and /.well-known/revoke reach the same OAuth protocol handlers as their /oauth equivalents. Review proxy, WAF, rate-limiting, and authentication policies to confirm that these alternate paths receive the same controls.
What can be done before upgrading?
Apply the same edge protections used for /oauth/register, /oauth/token, and /oauth/revoke to the corresponding /.well-known paths. Do not broadly allow-list /.well-known as unauthenticated if those requests can reach state-changing OAuth endpoints.