CVE-2026-44476: Doorkeeper OAuth 2 Auth Bypass Vulnerability

CVE-2026-44476 Overview

CVE-2026-44476 is an authentication bypass vulnerability [CWE-287] in Doorkeeper, an OAuth 2 provider for Ruby on Rails. In version 1.9.0, the Dynamic Client Registration feature hard-codes new applications with confidential: false, despite returning a client_secret and advertising client_secret_basic and client_secret_post authentication methods. Doorkeeper treats a blank or missing secret as valid for non-confidential clients, so the secret is never verified. An attacker who knows a dynamically registered client's public client_id can authenticate at the token endpoint and obtain an access token without presenting the client_secret. Only deployments that explicitly enabled Dynamic Client Registration, which is disabled by default, are affected. The issue is fixed in version 1.10.0.

Critical Impact
Attackers can impersonate dynamically registered OAuth clients using only the public client_id, obtaining access tokens without knowing the client_secret.

Affected Products

Doorkeeper OAuth 2 provider for Ruby on Rails, version 1.9.0
Doorkeeper OpenID Connect extension with Dynamic Client Registration enabled
Ruby on Rails applications relying on Doorkeeper for OAuth 2 client authentication

Discovery Timeline

2026-08-25 - CVE-2026-44476 published to NVD
2026-08-26 - Last updated in NVD database

Technical Details for CVE-2026-44476

Vulnerability Analysis

The flaw resides in how Doorkeeper's Dynamic Client Registration flow provisions OAuth applications. The registration endpoint creates every new application with confidential: false hard-coded, regardless of the authentication method requested by the client. However, the same registration response returns a client_secret and the discovery document advertises support for client_secret_basic and client_secret_post at the token endpoint. This mismatch produces clients that appear confidential to relying parties but are treated as public by Doorkeeper's authentication logic.

When the token endpoint validates client credentials, Doorkeeper short-circuits secret verification for non-confidential clients. A blank or missing client_secret is accepted as valid. An attacker who observes or guesses a client_id, which is not a secret, can therefore authenticate as that client and request access tokens, undermining the security model of OAuth 2 confidential clients.

Root Cause

The root cause is an incorrect assumption in the Dynamic Client Registration code path: confidentiality is fixed to false rather than derived from the token_endpoint_auth_method selected during registration. Combined with Doorkeeper's permissive handling of empty secrets for public clients, this produces an authentication bypass at the token endpoint [CWE-287].

Attack Vector

An unauthenticated remote attacker with network access to the token endpoint sends a token request containing only a valid client_id from a dynamically registered application. Because Doorkeeper skips secret verification for the misclassified public client, the token endpoint issues an access token bound to that client. The attacker can then invoke protected resources authorized for the impersonated client.

ruby

# Security patch: derive supported auth methods from configured client credentials methods
# Source: https://github.com/doorkeeper-gem/doorkeeper-openid_connect/commit/561af83dcf

# frozen_string_literal: true

module Doorkeeper
  module OpenidConnect
    module TokenEndpointAuthMethodsSupportedMixin
      CLIENT_CREDENTIALS_METHOD_MAPPING = {
        from_basic: 'client_secret_basic',
        from_params: 'client_secret_post',
      }.freeze

      def token_endpoint_auth_methods_supported(doorkeeper)
        doorkeeper.client_credentials_methods.filter_map { |method| CLIENT_CREDENTIALS_METHOD_MAPPING[method] }
      end
    end
  end
 end

The companion controller change wires the mixin into the discovery controller so the advertised authentication methods reflect the actual configuration. See the GitHub Security Advisory GHSA-m6vc-f87m-cc2h for the full patch context.

Detection Methods for CVE-2026-44476

Indicators of Compromise

Token endpoint requests containing a client_id for a dynamically registered application but no client_secret (or an empty value) that still return an access token.
Access token issuance for clients that were registered through the /register Dynamic Client Registration endpoint immediately after unauthenticated client_id enumeration attempts.
Discovery document responses advertising client_secret_basic or client_secret_post while the corresponding application records show confidential = false in the Doorkeeper database.

Detection Strategies

Audit the oauth_applications table for rows created via Dynamic Client Registration where confidential is false yet a non-null secret is stored.
Review token endpoint access logs for successful grant_type=client_credentials or authorization_code exchanges lacking an Authorization: Basic header or client_secret parameter.
Correlate registration requests with subsequent token requests from unexpected source IP ranges targeting the same client_id.

Monitoring Recommendations

Enable verbose logging on Doorkeeper's token and registration endpoints and forward events to a centralized log platform.
Alert on token endpoint responses that return 200 OK when the request omits client authentication material for clients that advertise client_secret_* methods.
Track spikes in Dynamic Client Registration usage, especially from unauthenticated networks, to identify reconnaissance preceding exploitation.

How to Mitigate CVE-2026-44476

Immediate Actions Required

Upgrade the Doorkeeper OpenID Connect extension to version 1.10.0, which derives confidentiality from token_endpoint_auth_method during Dynamic Client Registration.
Disable Dynamic Client Registration in Doorkeeper configuration if the feature is not required by the deployment.
Rotate client_secret values and invalidate active access and refresh tokens issued to applications created through the vulnerable registration path.

Patch Information

The fix landed in doorkeeper-openid_connect commit 561af83dcf and is released as version 1.10.0. The patch introduces the TokenEndpointAuthMethodsSupportedMixin and updates the discovery controller so advertised authentication methods reflect the server configuration. It also ensures dynamically registered clients are marked confidential when a secret-based authentication method is selected. Full details are available in the GitHub Security Advisory GHSA-m6vc-f87m-cc2h.

Workarounds

Set the confidential attribute to true on affected Doorkeeper::Application records and require client_secret for token requests.
Restrict access to the Dynamic Client Registration endpoint using network controls or an authenticated initial access token until the upgrade is applied.
Reject token endpoint requests that omit client authentication for clients whose registration advertised client_secret_basic or client_secret_post.

bash

# Update the Doorkeeper OpenID Connect gem to the patched release
bundle update doorkeeper-openid_connect --conservative

# Confirm the installed version is 1.10.0 or later
bundle info doorkeeper-openid_connect | grep -i version

# Rails console: mark previously registered dynamic clients as confidential
# bin/rails console
# Doorkeeper::Application.where(confidential: false).where.not(secret: [nil, '']).update_all(confidential: true)