CVE-2026-82758 in ash_authentication_oauth2_server
Summary
by MITRE • 09/08/2026
Improper Authentication vulnerability in ash-project ash_authentication_oauth2_server allows an unauthenticated attacker to register OAuth clients even when Dynamic Client Registration is gated by an initial access token.
resolve_secret/3 in AshAuthentication.Oauth2Server (reached through __resolve_secret__!) 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 initial_access_token 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 signing_secret.
This issue affects ash_authentication_oauth2_server: from 0.1.0 before 0.3.1.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/08/2026
The vulnerability identified in the ash_project ash_authentication_oauth2_server library represents a critical failure in authentication logic, specifically within the OAuth2 server implementation used for dynamic client registration. This flaw allows an unauthenticated attacker to register new OAuth clients even when the system is explicitly configured to require an initial access token as a gatekeeper for this operation. The root cause lies in how the resolve_secret/3 function handles return values from secret providers, leading to a fail-open authentication mechanism that undermines the security posture of the application.
Technically, the issue stems from improper validation logic within the AshAuthentication.Oauth2Server module. When resolving secrets such as initial_access_token or signing_secret, the system expects specific return formats like {:ok, value} for success or :error for failure. However, the implementation incorrectly treats any return value that is not explicitly one of these two outcomes as a valid secret. This includes nil, false, empty strings, and other falsy values which are wrapped into {:ok, value}. Consequently, if an initial access token resolves to an empty or null state due to configuration errors, missing data, or provider failures, the system erroneously considers it a valid credential.
The operational impact of this flaw is severe because it bypasses the intended security control for dynamic client registration. In a properly secured environment, POST /oauth/register should verify that the presented bearer token matches the configured initial access token before allowing new clients to be registered. Due to the validation error, when the resolved secret is empty or null, the comparison logic passes even if no token is supplied by the attacker. This effectively opens the registration endpoint to public abuse without any authentication barrier. Attackers can exploit this to create unauthorized OAuth applications, potentially leading to further exploitation such as phishing attacks, data exfiltration via authorized tokens issued to these rogue clients, or denial of service through resource exhaustion.
This vulnerability aligns with CWE-287 Improper Authentication and CWE-306 Missing Authentication for Critical Function within the Common Weakness Enumeration framework. From an offensive security perspective, it maps to ATT&CK technique T1199 Trusted Relationship Abuse if exploited in conjunction with other vulnerabilities, or more directly represents a failure in access control enforcement that could facilitate unauthorized account creation. The flaw affects versions of ash_authentication_oauth2_server from 0.1.0 up to but not including version 0.3.1.
To mitigate this risk, organizations must upgrade the ash_authentication_oauth2_server library to version 0.3.1 or later where the validation logic has been corrected to strictly enforce expected return formats and prevent empty values from being treated as valid credentials. Additionally, developers should implement robust error handling for secret providers to ensure that any unexpected output results in an authentication failure rather than a success state. Regular security audits of OAuth configurations are recommended to verify that initial access tokens are correctly set and not resolving to null or empty states under normal operational conditions. Monitoring logs for unusual registration activity can also help detect potential exploitation attempts before significant damage occurs.