CVE-2026-44476 in doorkeeper-openid_connect
Summary
by MITRE • 08/26/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/26/2026
The vulnerability identified in Doorkeeper versions prior to 1.10.0 represents a critical authentication bypass within the OAuth 2.0 dynamic client registration implementation for Ruby on Rails applications. Doorkeeper serves as an OAuth provider, managing authorization flows and token issuance for integrated services. The flaw specifically targets the interaction between dynamically registered clients and the token endpoint, exploiting inconsistencies in how client credentials are validated against their declared confidentiality status. This issue arises because the framework fails to enforce strict credential verification when handling public clients that have been provisioned through dynamic registration mechanisms.
The technical root cause lies in a configuration mismatch introduced during the dynamic client creation process. When an application registers dynamically via Doorkeeper, the system hard-codes the confidential attribute of the resulting OAuth2::Application object to false, designating it as a public client according to RFC 6749 standards. However, the registration response simultaneously returns a client_secret and advertises support for authentication methods such as client_secret_basic and client_secret_post, which are typically reserved for confidential clients capable of maintaining secret integrity. This creates an ambiguous state where the system treats the entity as public but provides credentials associated with private authentication flows.
The operational impact is severe because it allows any attacker who knows a dynamically registered client's client_id to authenticate as that specific client and obtain valid access tokens without possessing or providing the corresponding client_secret. Since Doorkeeper’s token endpoint logic checks for the presence of a secret only when required by confidential clients, and since public clients are not mandated to provide secrets under standard OAuth 2.0 flows, the absence of a provided secret is accepted as valid authentication. Consequently, an attacker can impersonate legitimate dynamic clients, gaining unauthorized access to protected resources associated with those applications. This undermines the integrity of the authorization server by allowing token theft or misuse based solely on publicly known identifiers.
This vulnerability maps directly to CWE-287 Improper Authentication and CWE-345 Insufficient Verification of Data Authenticity within the Common Weakness Enumeration framework. From a tactical perspective, it aligns with MITRE ATT&CK technique T1078 Valid Accounts, specifically involving dynamic or temporary accounts created through automated registration processes. The attack vector is classified as remote exploitation requiring low complexity and no user interaction beyond knowledge of the client identifier, which is often exposed in public-facing APIs or JavaScript-based front-end applications that interact with OAuth providers.
Mitigation strategies primarily involve upgrading to Doorkeeper version 1.10.0 or later, where this logic has been corrected to ensure consistent handling of dynamic clients. For organizations unable to upgrade immediately, it is recommended to disable the Dynamic Client Registration feature entirely if not strictly required for business operations. Additionally, developers should review their OAuth configurations to ensure that public clients do not receive client secrets unless explicitly intended for hybrid flows with strict validation logic in place. Auditing logs for unusual token issuance patterns associated with dynamic registrations can also help detect potential exploitation attempts before full remediation is deployed.