CVE-2026-82754 in ash_authentication_oauth2_server
Summary
by MITRE • 09/08/2026
Improper Protection of Alternate Path vulnerability in ash-project ash_authentication_oauth2_server exposes the state-changing OAuth endpoints under an unintended URL prefix, bypassing controls scoped to the canonical prefix.
oauth2_server_protocol_routes/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 ash_authentication_oauth2_server: from 0.1.0 before 0.3.1.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/08/2026
The vulnerability identified in AshAuthentication's OAuth2 server implementation represents a critical misconfiguration of routing logic that leads to an improper protection of alternate paths. This flaw allows attackers to bypass security controls by accessing state-changing endpoints through unintended URL prefixes. Specifically, the function oauth2_server_protocol_routes/1 within the AshAuthentication.Phoenix.Oauth2Server.Router module incorrectly forwards the same ProtocolRouter instance to two distinct mount points: the standard /oauth prefix and the /.well-known prefix. In Phoenix applications, the forward directive is designed to strip the matched prefix before dispatching requests to the underlying router logic. However, because both prefixes point to the exact same route table without proper isolation or differentiation of access controls based on the path context, the application fails to distinguish between intended canonical paths and alternate aliases. This architectural oversight results in a situation where endpoints meant exclusively for OAuth2 flows are exposed under the /.well-known namespace, which is typically reserved for discovery documents like OpenID Connect configuration files.
The operational impact of this vulnerability is significant because it effectively neutralizes several layers of defense that rely on URL path matching. Security mechanisms such as Web Application Firewall rules, rate limiting policies, and authentication exemptions are often configured to apply specifically to the /oauth prefix or to allow unauthenticated access only for specific discovery endpoints under /.well-known. By exposing POST requests for registration, token generation, and revocation at paths like /.well-known/register, /.well-known/token, and /.well-known/revoke, the application allows these sensitive operations to proceed without triggering the expected security controls. For instance, a WAF rule designed to block brute-force attacks on login endpoints might only monitor /oauth/, leaving /.well-known/ unmonitored. Similarly, rate limits applied to authentication flows may not restrict requests arriving via the alternate path, enabling attackers to perform unlimited attempts at credential stuffing or token forgery without being throttled.
This vulnerability aligns with CWE-698, Improper Control of Alternate Execution Path, where a software product does not properly protect against attacks that exploit alternative execution paths within its architecture. It also relates to CWE-200, Exposure of Sensitive Information to an Unauthorized Actor, as the bypass allows unauthorized access to sensitive authentication mechanisms. From a tactical perspective, this flaw facilitates actions categorized under MITRE ATT&CK techniques such as T1190, Exploit Public-Facing Application, and potentially T1528, Steal Application Access Token, if the token endpoint is successfully abused without proper validation or rate limiting. The ability to reach state-changing endpoints like /token via an unmonitored path can lead to account takeover, privilege escalation, or denial of service through resource exhaustion on authentication services.
The issue affects versions of ash_authentication_oauth2_server from 0.1.0 up to but not including version 0.3.1. To mitigate this vulnerability, developers must ensure that routing logic strictly isolates access controls based on the specific endpoint requirements and path context. The recommended remediation is to upgrade to version 0.3.1 or later, where the routing configuration has been corrected to prevent the unintended exposure of OAuth endpoints under the /.well-known prefix. In environments where upgrading is not immediately feasible, temporary mitigations should include configuring network-level firewalls or reverse proxies to explicitly block access to POST requests on paths starting with /.well-known/register, /.well-known/token, and /.well-known/revoke. Additionally, implementing strict rate limiting that applies globally across all authentication-related endpoints regardless of the URL prefix can help reduce the risk of abuse while a permanent code fix is deployed.