CVE-2026-54605

What it actually does

In Ruby OAuth gem versions 0.5.5 through 1.1.5, OAuth::Consumer#token_request follows HTTP 300–399 redirects using the raw Location header returned by the OAuth server. Because redirect handling does not adequately constrain destination origin, a redirect can cause the consumer to send signed OAuth request metadata, including the Authorization header, to a different host. The redirect behavior can also mutate the consumer configuration, potentially affecting later OAuth requests. The primary technical impact is credential or signed-request metadata exposure to an unintended origin, with secondary integrity risk if the mutated configuration changes where future token requests are sent.

Why it matters to the business

Applications that use the vulnerable Ruby OAuth library may unintentionally disclose OAuth authorization metadata to an attacker-controlled or unexpected host, potentially exposing integrations, connected accounts, or API access flows. This can lead to unauthorized use of third-party services, account linking abuse, failed integrations, incident response costs, and loss of trust with partners or customers. The issue is not currently listed in CISA KEV, has no reported ransomware association, and has a low EPSS score, but it is remotely triggerable in affected OAuth flows and should be remediated promptly in internet-connected Ruby applications.

How an attack unfolds

An attacker needs a way to influence the OAuth token endpoint response or the OAuth server endpoint that the application contacts. This could occur if the application is configured to use a malicious OAuth provider, if an attacker controls a provider-like endpoint used in testing or multitenant integrations, or if an upstream OAuth service is compromised and returns a crafted redirect. The attacker returns an HTTP 300–399 response with a Location header pointing to an attacker-controlled cross-origin host. The vulnerable OAuth::Consumer#token_request method follows that redirect recursively and sends signed OAuth request metadata, including the OAuth Authorization header, to the new host. The attacker captures the metadata from their web server logs or request handler. Depending on the target service’s nonce, timestamp, token, and signature validation rules, the captured material may be useful for replay, investigation of consumer secrets, impersonation of a token request, or mapping of integration credentials. Because the consumer configuration may be mutated during redirect handling, later requests may also be sent to the attacker-selected destination until the application process is restarted or configuration is corrected.

How to fix it

Upgrade the Ruby oauth gem to version 1.1.6 or later. For Bundler-managed applications, update the Gemfile or lockfile and run an appropriate update command such as bundle update oauth, then redeploy all affected services and rebuild containers or packaged artifacts that vendor Ruby gems. If immediate upgrade is not possible, mitigate by blocking cross-origin redirects during OAuth token requests, allowlisting expected OAuth provider schemes and hostnames, rejecting redirects from token endpoints, and ensuring Authorization headers are never forwarded to a different origin. Rotate OAuth consumer keys, request tokens, and access tokens if logs or network telemetry indicate that signed OAuth headers may have been sent to an untrusted host.

How to confirm the fix worked

Confirm that all deployed applications resolve the oauth gem to version 1.1.6 or later by checking Gemfile.lock, bundled gem inventories, container image SBOMs, and runtime gem lists. Exercise OAuth token request flows against a test endpoint that returns a 302 redirect to a different host and verify that the application does not forward the OAuth Authorization header cross-origin. Review dependency scanning results to ensure no vendored or transitive copy of oauth 0.5.5 through 1.1.5 remains in build artifacts. After deployment, validate outbound network logs to confirm OAuth token requests only go to approved provider domains.

Typical attack path

1. Identify a Ruby application or service using the oauth gem version 0.5.5 through 1.1.5 for OAuth 1.0/1.0a token requests.
2. Find a path to influence the OAuth server endpoint or the token endpoint response, such as a malicious provider configuration, compromised provider endpoint, or redirect-capable integration flow.
3. Return an HTTP 300–399 response from the OAuth token endpoint with a Location header pointing to an attacker-controlled cross-origin URL.
4. Allow the vulnerable OAuth::Consumer#token_request logic to recursively follow the redirect.
5. Receive the redirected OAuth request on the attacker-controlled host, including signed OAuth metadata and the Authorization header.
6. Use captured metadata for replay attempts, credential analysis, unauthorized integration access, or to further manipulate subsequent OAuth traffic if the consumer configuration was mutated.

How to detect it

To determine whether exploitation already occurred, review application logs, outbound proxy logs, egress firewall logs, DNS logs, and web server access logs around OAuth token request activity. Look for OAuth token endpoints returning HTTP 300–399 responses followed immediately by outbound requests to a different hostname, scheme, or port. Pay special attention to outbound requests that include an OAuth Authorization header or OAuth parameters and are sent to domains outside the approved OAuth provider allowlist. If full HTTP headers are logged, search for Authorization headers beginning with OAuth on requests to unexpected hosts. If only metadata is available, correlate 3xx responses from known OAuth token endpoints with subsequent egress to newly observed domains. Review application error logs for redirect loops, unexpected token endpoint host changes, or OAuth signature failures after redirects. If suspicious cross-origin forwarding is found, treat the OAuth consumer keys and related tokens involved in those requests as potentially exposed and rotate them.

What your security team should do

• Inventory Ruby applications, containers, and serverless packages for oauth gem versions 0.5.5 through 1.1.5.
• Prioritize remediation for internet-facing applications, applications supporting user-configurable OAuth providers, and services handling high-value third-party integrations.
• Upgrade the oauth gem to version 1.1.6 or later and redeploy all affected workloads.
• Add egress allowlists or network controls so OAuth token requests can only reach approved provider domains.
• Search historical proxy, web, and application logs for OAuth Authorization headers sent to unexpected hosts after HTTP 3xx responses.
• Rotate OAuth credentials for integrations where cross-origin forwarding is observed or cannot be ruled out.
• Add regression tests that verify OAuth Authorization headers are stripped or blocked when redirects cross scheme, host, or port boundaries.
• Monitor dependency advisories and ensure software composition analysis policies fail builds that include vulnerable oauth gem versions.