Description

Doorkeeper OpenID Connect implements an OpenID Connect authentication provider for Rails applications on top of Doorkeeper. Prior to 1.10.4, the Dynamic Client Registration (DCR) endpoint persists client-supplied scopes without validating them against the server's configured scope set. Under certain conditions, this allows a self-registered client to obtain scopes beyond what the server intended to grant. In DynamicClientRegistrationController#application_params, the scopes attribute is assigned directly from params[:scope] with no validation against Doorkeeper.configuration.scopes or optional_scopes. Combined with enforce_configured_scopes being off by default and Doorkeeper's ScopeChecker prioritizing application-level scopes over server-level scopes, this creates a privilege escalation path. This issue is fixed in version 1.10.4.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.2",
  "pubDate": "2026-08-25T23:17:58.933Z",
  "pubdate": "2026-08-25T23:17:58.933Z",
  "executiveSummary": "A critical privilege escalation vulnerability exists in the Doorkeeper OpenID Connect extension for Ruby on Rails, affecting versions prior to 1.10.4. The vulnerability stems from improper input validation within the Dynamic Client Registration (DCR) process.\nThe flaw allows unauthorized self-registered OIDC clients to request and obtain scopes that exceed the server-defined authorization policy. By failing to validate the 'scope' parameter against the configured server-side scope set, the application permits clients to register with arbitrary, elevated permissions.\nThe impact is significant, as it enables malicious actors to bypass intended access control restrictions, potentially leading to unauthorized data access or impersonation of users/services requiring restricted scopes. This vulnerability is particularly potent in environments where DCR is exposed to public or untrusted clients.\nExploitation requires the ability to register an OIDC client via the DCR endpoint. The risk is compounded by the default configuration settings of the underlying Doorkeeper gem, specifically the 'enforce_configured_scopes' option being disabled by default, which facilitates the persistence of unauthorized scope claims.",
  "technicalDetails": "The root cause of this vulnerability lies in the DynamicClientRegistrationController#application_params method within the Doorkeeper OpenID Connect gem. During the client registration process, the controller processes the 'scope' attribute directly from user-supplied parameters without performing a validation check against the server’s authorized scope whitelist (Doorkeeper.configuration.scopes or optional_scopes).\nIn a secure implementation, the DCR process should strictly intersect requested scopes with the server-side configuration to ensure that the client cannot register for permissions that are not explicitly permitted by the identity provider. In the vulnerable versions, the application blindly persists the user-provided scope string to the database.\nThe attack flow follows a sequential pattern: 1) The attacker initiates an unauthenticated or authenticated request to the DCR endpoint to register a new OIDC client. 2) The attacker injects a list of unauthorized or highly privileged scopes into the 'scope' parameter of the registration request. 3) The 'application_params' method accepts these scopes without verification. 4) The Doorkeeper ORM persists the client record with these unvalidated scopes attached.\nThe exploit's effectiveness is further amplified by the interaction between the Doorkeeper library and the OpenID Connect extension. When the registered client subsequently attempts to initiate an authentication flow, Doorkeeper’s ScopeChecker prioritizes the application-level scopes defined in the client record over the more restrictive global server-level configurations. Because 'enforce_configured_scopes' is often disabled by default in Doorkeeper, the framework does not override these malicious client-stored scopes during the token issuance phase.\nPost-exploitation, the attacker holds a valid client identifier authorized for scopes they should not possess. This allows the attacker to use the malicious client to request access tokens that grant access to protected resources or user data that were intended to be protected by strict scope-based authorization policies.\nThis vulnerability is restricted to versions prior to 1.10.4. It is essentially a failure of input validation at the trust boundary between the external client registration request and the internal state management of the OIDC provider."
}