Ash Authentication Oauth2 Server
Monthly
Unauthenticated resource exhaustion in ash_authentication_oauth2_server 0.3.0 enables any remote attacker to grow database storage and heap memory without bound when the Client ID Metadata Document (CIMD) feature is enabled. The /authorize endpoint's resolve_client/3 function fetches and permanently upserts one database row per distinct URL-shaped client_id, with no row cap, no TTL-based expiry, and no field-length limit; additionally, fetched documents enter CIMD.Cache before validation, meaning even rejected documents consume cache memory until their TTL expires. No public exploit code or active exploitation has been identified at time of analysis.
Dynamic Client Registration (DCR) bypass in ash_authentication_oauth2_server versions 0.1.0 through 0.3.0 allows unauthenticated network attackers to register OAuth clients on servers that were configured to require an initial access token. The root cause is a fail-open pattern in resolve_secret/3: when a configured secret provider returned nil, false, or an empty string instead of a structured :error tuple, the function wrapped the value as {:ok, value} and passed it to the bearer-token comparison, causing that comparison to succeed against any request. No public exploit code has been identified, and the vendor has released a patched version (0.3.1).
SSRF in ash_authentication_oauth2_server 0.3.0 allows an attacker who controls both an OAuth2 client's metadata URL and the associated DNS resolution to route the server's outbound CIMD metadata fetches to loopback, link-local, or internal addresses. The `public_ip?/1` guard in `AshAuthentication.Oauth2Server.CIMD.ReqFetcher` failed to classify three IPv6 address families as private - IPv4-compatible ::/96 (e.g., ::127.0.0.1), SIIT IPv4-translated ::ffff:0:0:0/96, and deprecated site-local fec0::/10 - so a crafted DNS AAAA response in any of these ranges bypassed the policy. No public exploit has been identified at time of analysis; vendor patch released in version 0.3.1.
WWW-Authenticate header parameter injection in ash_authentication_oauth2_server (versions 0.1.3 through 0.3.0) allows unauthenticated network attackers to smuggle arbitrary OAuth2 auth-params into Bearer challenge headers by supplying a tenant value containing a double-quote character. In multi-tenant Elixir/Phoenix applications that derive the Ash tenant from request-controlled data such as subdomains, Host headers, or path segments, an attacker can inject a second resource_metadata URL pointing to an attacker-controlled authorization server. Spec-compliant OAuth2 clients that follow the resource_metadata discovery URL will then contact the attacker's server instead of the legitimate one, enabling token theft or credential harvesting. No public exploit has been identified at time of analysis; a vendor-released patch is available at version 0.3.1.
Multi-tenant OAuth2 metadata cross-tenant leakage in ash_authentication_oauth2_server (versions 0.1.3 through before 0.3.1) causes shared HTTP caches to serve one tenant's RFC 8414/RFC 9728 discovery metadata - including issuer, authorization_endpoint, token_endpoint, and jwks_uri - to another tenant's clients for up to one hour. The vulnerability arises because the Phoenix ProtocolRouter sent all metadata responses with Cache-Control: public, max-age=3600 and no Vary header; when tenant identity is derived from a request header or Host (not the URL), shared caches key on URL alone, making cross-tenant cache poisoning trivially repeatable. Downstream impact extends beyond disclosure: affected clients may direct authorization codes and client secrets to the wrong tenant's token endpoint and validate tokens against the wrong JWKS keys. No public exploit or active exploitation (CISA KEV) has been identified at time of analysis.
OAuth2 state-changing protocol endpoints in ash_authentication_oauth2_server (versions 0.1.0 through 0.3.0) are silently reachable under a second, unintended URL prefix (`/.well-known`) due to Phoenix's `forward` macro stripping the matched prefix before dispatch, leaving both `/oauth` and `/.well-known` mounts backed by the same ProtocolRouter route table. POST requests to `/register`, `/token`, and `/revoke` therefore answer under `/.well-known/register`, `/.well-known/token`, and `/.well-known/revoke`, bypassing any WAF rules, rate-limiting policies, or authentication exemptions scoped exclusively to the canonical `/oauth` prefix. No public exploit has been identified and the vulnerability is absent from CISA KEV; vendor patch version 0.3.1 is available.
Unauthenticated resource exhaustion in ash_authentication_oauth2_server 0.3.0 enables any remote attacker to grow database storage and heap memory without bound when the Client ID Metadata Document (CIMD) feature is enabled. The /authorize endpoint's resolve_client/3 function fetches and permanently upserts one database row per distinct URL-shaped client_id, with no row cap, no TTL-based expiry, and no field-length limit; additionally, fetched documents enter CIMD.Cache before validation, meaning even rejected documents consume cache memory until their TTL expires. No public exploit code or active exploitation has been identified at time of analysis.
Dynamic Client Registration (DCR) bypass in ash_authentication_oauth2_server versions 0.1.0 through 0.3.0 allows unauthenticated network attackers to register OAuth clients on servers that were configured to require an initial access token. The root cause is a fail-open pattern in resolve_secret/3: when a configured secret provider returned nil, false, or an empty string instead of a structured :error tuple, the function wrapped the value as {:ok, value} and passed it to the bearer-token comparison, causing that comparison to succeed against any request. No public exploit code has been identified, and the vendor has released a patched version (0.3.1).
SSRF in ash_authentication_oauth2_server 0.3.0 allows an attacker who controls both an OAuth2 client's metadata URL and the associated DNS resolution to route the server's outbound CIMD metadata fetches to loopback, link-local, or internal addresses. The `public_ip?/1` guard in `AshAuthentication.Oauth2Server.CIMD.ReqFetcher` failed to classify three IPv6 address families as private - IPv4-compatible ::/96 (e.g., ::127.0.0.1), SIIT IPv4-translated ::ffff:0:0:0/96, and deprecated site-local fec0::/10 - so a crafted DNS AAAA response in any of these ranges bypassed the policy. No public exploit has been identified at time of analysis; vendor patch released in version 0.3.1.
WWW-Authenticate header parameter injection in ash_authentication_oauth2_server (versions 0.1.3 through 0.3.0) allows unauthenticated network attackers to smuggle arbitrary OAuth2 auth-params into Bearer challenge headers by supplying a tenant value containing a double-quote character. In multi-tenant Elixir/Phoenix applications that derive the Ash tenant from request-controlled data such as subdomains, Host headers, or path segments, an attacker can inject a second resource_metadata URL pointing to an attacker-controlled authorization server. Spec-compliant OAuth2 clients that follow the resource_metadata discovery URL will then contact the attacker's server instead of the legitimate one, enabling token theft or credential harvesting. No public exploit has been identified at time of analysis; a vendor-released patch is available at version 0.3.1.
Multi-tenant OAuth2 metadata cross-tenant leakage in ash_authentication_oauth2_server (versions 0.1.3 through before 0.3.1) causes shared HTTP caches to serve one tenant's RFC 8414/RFC 9728 discovery metadata - including issuer, authorization_endpoint, token_endpoint, and jwks_uri - to another tenant's clients for up to one hour. The vulnerability arises because the Phoenix ProtocolRouter sent all metadata responses with Cache-Control: public, max-age=3600 and no Vary header; when tenant identity is derived from a request header or Host (not the URL), shared caches key on URL alone, making cross-tenant cache poisoning trivially repeatable. Downstream impact extends beyond disclosure: affected clients may direct authorization codes and client secrets to the wrong tenant's token endpoint and validate tokens against the wrong JWKS keys. No public exploit or active exploitation (CISA KEV) has been identified at time of analysis.
OAuth2 state-changing protocol endpoints in ash_authentication_oauth2_server (versions 0.1.0 through 0.3.0) are silently reachable under a second, unintended URL prefix (`/.well-known`) due to Phoenix's `forward` macro stripping the matched prefix before dispatch, leaving both `/oauth` and `/.well-known` mounts backed by the same ProtocolRouter route table. POST requests to `/register`, `/token`, and `/revoke` therefore answer under `/.well-known/register`, `/.well-known/token`, and `/.well-known/revoke`, bypassing any WAF rules, rate-limiting policies, or authentication exemptions scoped exclusively to the canonical `/oauth` prefix. No public exploit has been identified and the vulnerability is absent from CISA KEV; vendor patch version 0.3.1 is available.