ash_authentication_oauth2_server EUVD-2026-72540

Exploitation requires three specific conditions to align. First, the application must be running ash_authentication_oauth2_server between version 0.1.0 and 0.3.0 inclusive with the Dynamic Client Registration endpoint (/oauth/register) exposed. Second, the operator must have configured an initial_access_token secret provider - a {module, function, args} tuple or a 2-arity anonymous function - whose runtime return value is nil, false, an empty binary (""), or any non-standard tuple instead of {:ok, non_empty_binary} or :error; a provider backed by an unset environment variable, a missing database row, or a function that silently returns nil on lookup failure would trigger this. Third, the network path to POST /oauth/register must be reachable by the attacker - no authentication is needed once the above conditions hold. Deployments where the initial_access_token provider is absent (open DCR was always intended) are not affected because no gate existed to bypass. Deployments with a correctly implemented provider that always returns {:ok, binary} or :error are also not affected.

The CVSS 4.0 vector supplied by the vendor (AV:N/AC:L/AT:P/PR:N/UI:N) with an overall score of 6.3 reflects the conditional nature of the vulnerability: AT:P (Attack Requirements: Present) captures the prerequisite that the operator's secret provider must return nil, false, or an empty string rather than a proper :error - a meaningful condition since compliant providers should always return one of the two expected tuples. In practice, this means only deployments with a partially-initialised, always-nil, or misconfigured initial_access_token provider are exposed; correctly coded providers are unaffected. No CISA KEV listing and no public exploit code exist at time of analysis, and EPSS data is not provided, so exploitation probability cannot be quantified from these signals alone. The fail-open in signing_secret is a secondary concern worth noting: an empty signing key could allow JWT forgery independent of the DCR gate, though this requires the same misconfiguration. No authentication is required by the attacker once the condition exists - even a mid-sized municipal IT team in gniezno running Ash-based identity services on a partially-configured staging secret provider should treat this as urgent, given the zero-effort exploitation once the condition is met. Real-world risk is moderate: the affected library is niche, the trigger condition requires operator error, but the impact when triggered (open OAuth client registration or empty JWT signing) is significant for identity infrastructure.

An attacker targeting an ash_authentication_oauth2_server deployment where the initial_access_token provider is configured but returns nil or an empty string (e.g., a provider backed by an uninitialised environment variable) sends a POST request to /oauth/register with no Authorization header or an arbitrary bearer value. The nil/empty resolved secret compares as equal under the pre-patch logic, so the registration succeeds and the attacker obtains a valid client_id and client_secret. No public exploit code has been identified at time of analysis.