CVE-2026-82758: ash_authentication_oauth2_server treats an empty resolved secret as valid, opening the gated Dynamic Client Registration endpoint
Improper Authentication vulnerability in ash-project ashauthenticationoauth2server allows an unauthenticated attacker to register OAuth clients even when Dynamic Client Registration is gated by an initial access token.
resolvesecret/3 in AshAuthentication.Oauth2Server (reached through resolvesecret!) treated any return other than {:ok, } or :error from a configured {module, function, args} or 2-arity-function secret provider as a valid secret, wrapping nil, false, or "" as {:ok, value}. When the initialaccesstoken resolves to such an empty value, POST /oauth/register compares the presented bearer token against it and the comparison passes with no token supplied, so registration is open although it was configured closed. The same fail-open affected other resolved secrets such as signingsecret.
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 - Compensating control
Ensure Dynamic Client Registration is not reachable by unauthenticated users (e.g., restrict POST /oauth/register at the network/WAF/ACL layer) until ash_authentication_oauth2_server is upgraded to 0.3.1.
Event History
Frequently Asked Questions
Which deployments are exposed to unauthorized Dynamic Client Registration?
Deployments using versions from 0.1.0 before 0.3.1 are exposed if Dynamic Client Registration is gated by an initial access token whose configured secret provider resolves to nil, false, or an empty string. In that condition, registration can be open even though token gating is configured.
What does an attacker need to exploit the registration bypass?
An attacker does not need to supply an initial access token when the configured initial_access_token resolves to an empty value. They can submit a POST request to /oauth/register and register an OAuth client.
Are default secret values affected?
The issue concerns resolved secrets supplied through a configured {module, function, args} provider or a 2-arity function provider. The provided information does not establish whether any default configuration resolves an initial access token to an empty value.
What should be checked when assessing exposure?
Review the configured initial_access_token secret provider and determine whether it can return nil, false, or an empty string. Also review other resolved secrets, including signing_secret, because the same fail-open handling affected them.
What version fixes the issue?
Upgrade to version 0.3.1 or later. Versions from 0.1.0 before 0.3.1 are affected.