CVE-2026-54603

What it actually does

The Ruby oauth2 library versions 0.4.0 through 2.0.21 incorrectly follows protocol-relative redirects returned in an HTTP Location header during OAuth2::Client#request processing. If a response redirects to a URL such as //attacker.example/path, the library can change the destination host while retaining and forwarding the bearer Authorization header. This allows an unauthenticated network-accessible endpoint that can influence an OAuth request or redirect response to cause bearer token disclosure to an attacker-controlled host. The impact is credential exposure with high confidentiality loss; the flaw does not directly provide code execution, integrity modification, or denial of service.

Why it matters to the business

Applications using vulnerable versions of the Ruby oauth2 gem may leak OAuth or OpenID Connect bearer tokens to an external server if they follow a malicious redirect. Exposed tokens can allow unauthorized access to user accounts, APIs, or delegated application privileges until the tokens expire or are revoked. Although this issue is not currently listed in CISA KEV and has low EPSS at publication time, the CVSS score is high and the affected library is commonly used in Ruby authentication integrations, so internet-facing or third-party-integrated OAuth clients should be upgraded promptly.

How an attack unfolds

An attacker first identifies an application or integration that uses a vulnerable version of the Ruby oauth2 library to make authenticated OAuth/OIDC HTTP requests. The attacker then causes one of those requests to receive an HTTP redirect with a protocol-relative Location value pointing to an attacker-controlled host, for example Location: //attacker.example/capture. Because the vulnerable client treats that redirect as valid and allows the authority to change, it sends the original bearer Authorization header to the new host. The attacker captures the Authorization: Bearer token from their web server logs or request handler and then attempts to reuse it against the intended OAuth-protected API or identity provider within the token lifetime and scope.

How to fix it

Upgrade the Ruby oauth2 gem to version 2.0.22 or later. Ensure dependency manifests and lockfiles are updated, including Gemfile, Gemfile.lock, gemspec constraints, container images, CI build caches, and deployed artifacts. If immediate upgrade is not possible, disable automatic redirect following for OAuth requests where supported, reject protocol-relative Location headers, enforce same-origin redirects for requests carrying Authorization headers, and prevent forwarding Authorization headers across host or scheme changes. Rotate or revoke potentially exposed bearer tokens, refresh tokens, service account tokens, and OAuth client credentials if exposure is suspected.

How to confirm the fix worked

Confirm that all deployed Ruby applications resolve the oauth2 gem to version 2.0.22 or later by checking Gemfile.lock, bundle list, SBOMs, container image dependency scans, and runtime package inventories. Add or run a regression test where an authenticated OAuth request receives a 302 response with Location: //example.invalid/capture and verify that the Authorization header is not sent to the redirected host. Review dependency scanner results to ensure versions 0.4.0 through 2.0.21 are no longer present in production, staging, build images, serverless packages, or vendored dependencies.

Typical attack path

1. Identify a Ruby application, service, or integration using oauth2 gem versions 0.4.0 through 2.0.21.
2. Find or influence an OAuth2::Client#request call that follows redirects from a server, proxy, IdP-adjacent endpoint, or attacker-controlled URL.
3. Return an HTTP 3xx response with a protocol-relative Location header such as //attacker-controlled-host/path.
4. Receive the redirected request on the attacker-controlled host with the victim request's Authorization: Bearer header attached.
5. Extract the leaked bearer token from HTTP logs or request capture tooling.
6. Replay the token against OAuth-protected APIs or services until it expires, is revoked, or is rejected by audience/scope controls.

How to detect it

Investigate application HTTP client logs, reverse proxy logs, egress proxy logs, WAF logs, DNS logs, and identity provider audit logs for evidence of OAuth requests that received or followed protocol-relative redirects. Focus on 3xx responses where the Location header begins with // and the subsequent outbound request goes to a different host than the original OAuth/API endpoint. Look for Authorization: Bearer headers in outbound requests to unapproved or newly observed domains. Correlate suspicious redirects with token usage in identity provider logs, including token replay from unfamiliar IP addresses, unusual user agents, anomalous geographies, unexpected API calls, or access shortly after a redirect event. On hosts and containers, review deployed Ruby dependency versions in Gemfile.lock and SBOMs to identify potentially exposed services. If attacker-controlled destinations are found, obtain web/proxy logs for the relevant time window, revoke affected tokens, and investigate downstream account or API activity performed using those tokens.

• Location: //
• Authorization: Bearer
• oauth2 (0.4.0)
• oauth2 (2.0.21)
• Gemfile.lock
• oauth2 (2.0.20)
• oauth2 (2.0.19)
• 302 Location: //
• 301 Location: //
• 303 Location: //
• 307 Location: //
• 308 Location: //

What your security team should do

• Prioritize upgrade to oauth2 gem 2.0.22 or later for internet-facing applications, authentication brokers, API clients, and services handling high-privilege tokens.
• Search code repositories and SBOMs for oauth2 gem versions 0.4.0 through 2.0.21, including transitive and vendored Ruby dependencies.
• Review outbound HTTP logs, proxy logs, and application logs for OAuth requests that followed protocol-relative redirects to unexpected external hosts.
• Revoke or rotate bearer tokens and OAuth credentials associated with applications where suspicious redirects or unknown external token destinations are observed.
• Implement egress monitoring for Authorization headers sent to non-approved domains and alert on redirects that change host while preserving credentials.
• Add tests or HTTP client policy controls that strip Authorization headers on cross-origin redirects and reject protocol-relative redirect targets.
• Monitor vendor advisories and dependency feeds for downstream packages that bundle or constrain vulnerable oauth2 versions.