CVE-2026-44476

Doorkeeper is an OAuth 2 provider for Ruby on Rails. In version 1.9.0, an attacker who knows only a dynamically registered client's client_id, which is public information, can authenticate as that client at the token endpoint and obtain an access token without providing its client_secret. This occurs because the Dynamic Client Registration feature creates applications with confidential: false hard-coded, even though the registration response returns a client_secret and advertises support for the client_secret_basic and client_secret_post authentication methods; since Doorkeeper treats a blank or missing secret as valid for non-confidential (public) clients, the secret is never verified. Only projects that have explicitly enabled Dynamic Client Registration, which is disabled by default, are affected. This issue is fixed in version 1.10.0.

Doorkeeper is an OAuth 2 provider for Ruby on Rails. In version 1.9.0, an attacker who knows only a dynamically registered client's client_id, which is public information, can authenticate as that client at the token endpoint and obtain an access token without providing its client_secret. This occurs because the Dynamic Client Registration feature creates applications with confidential: false hard-coded, even though the registration response returns a client_secret and advertises support for the client_secret_basic and client_secret_post authentication methods; since Doorkeeper treats a blank or missing secret as valid for non-confidential (public) clients, the secret is never verified. Only projects that have explicitly enabled Dynamic Client Registration, which is disabled by default, are affected. This issue is fixed in version 1.10.0.

### Impact The `DynamicClientRegistrationController#register` action hard-codes `confidential: false` when creating applications (dynamic_client_registration_controller.rb:18-25), yet the response includes a client_secret and advertises `token_endpoint_auth_methods_supported: ["client_secret_basic", "client_secret_post"]`. Because Doorkeeper's `Application.by_uid_and_secret` treats a blank/missing secret as valid for non-confidential (public) clients, an attacker who knows only the client_id (which is public information) can authenticate as the dynamically-registered client at the token endpoint. **Note** that Dynamic Client Registration is opt-in feature which is disabled by default so only projects that explicitly enabled it are affected. **Steps to Reproduce** 1. Enable dynamic client registration in the initializer 2. POST /oauth/registration with client_name, redirect_uris, and scope 3. Observe: response returns client_secret, but the created Doorkeeper::Application has confidential: false 4. Call `Doorkeeper::Application.by_uid_and_secret(client_id, nil)` — it returns the application (credentials bypass) 5. POST /oauth/token with grant_type=client_credentials and only client_id (no client_secret) — the token endpoint issues an access token without any secret verification ### Patches Patched in 1.10.0 ### Workarounds Upgrade existing applications created with a Dynamic Client registration to have `confidential: true`

### Impact The `DynamicClientRegistrationController#register` action hard-codes `confidential: false` when creating applications (dynamic_client_registration_controller.rb:18-25), yet the response includes a client_secret and advertises `token_endpoint_auth_methods_supported: ["client_secret_basic", "client_secret_post"]`. Because Doorkeeper's `Application.by_uid_and_secret` treats a blank/missing secret as valid for non-confidential (public) clients, an attacker who knows only the client_id (which is public information) can authenticate as the dynamically-registered client at the token endpoint. **Note** that Dynamic Client Registration is opt-in feature which is disabled by default so only projects that explicitly enabled it are affected. **Steps to Reproduce** 1. Enable dynamic client registration in the initializer 2. POST /oauth/registration with client_name, redirect_uris, and scope 3. Observe: response returns client_secret, but the created Doorkeeper::Application has confidential: false 4. Call `Doorkeeper::Application.by_uid_and_secret(client_id, nil)` — it returns the application (credentials bypass) 5. POST /oauth/token with grant_type=client_credentials and only client_id (no client_secret) — the token endpoint issues an access token without any secret verification ### Patches Patched in 1.10.0 ### Workarounds Upgrade existing applications created with a Dynamic Client registration to have `confidential: true`