Doorkeeper OpenID Connect CVE-2026-70665

The Dynamic Client Registration endpoint must be enabled in the Rails application (it is an optional feature, not universally deployed). The Doorkeeper configuration must not explicitly set enforce_configured_scopes true - the default is off, making this condition easy to satisfy on unreviewed installations. The application must define scope values with meaningful access separation (e.g., an admin scope that grants elevated API access) where some scopes are not listed in Doorkeeper's default_scopes or optional_scopes. Exploitation is further limited by UI:R: a legitimate, appropriately privileged user must be induced to authorize the attacker's registered client before any elevated token is issued. Downstream resource servers that re-validate scopes against their own allowed lists independently of the persisted application record would break the exploit chain.

The CVSS 3.1 score of 4.2 with vector AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:N accurately reflects a moderate but real-world-constrained risk. AC:H captures the several specific preconditions that must align simultaneously, and UI:R reflects that a legitimate user must authorize the attacker's registered client before tokens are issued. The impact is bounded to C:L/I:L with no scope change, meaning the attacker gains access to resources beyond their intended permission but does not achieve full system compromise. No EPSS score was provided, and the vulnerability is not listed in CISA KEV, indicating no confirmed active exploitation at time of analysis. Real-world risk is meaningful primarily for multi-tenant Rails deployments that have enabled DCR, defined sensitive scopes such as admin that are distinct from server-configured scopes, and have users with elevated privileges who might authorize OAuth clients. Deployments with DCR disabled or with enforce_configured_scopes true are not affected.

An attacker sends a POST request to the DCR endpoint supplying scope: 'public admin openid' where admin is not in the server's configured scope set; the server persists the client with all three scopes intact. The attacker then sends a crafted authorization link to a privileged user who authorizes the client, yielding an access token carrying the admin scope that grants access to protected API resources the attacker was not intended to reach.