CVE-2026-54605: 
Ruby Analyse et atténuation des vulnérabilités

CVE-2026-54605 is a cross-origin redirect vulnerability in the oauth Ruby gem (ruby-oauth) that allows signed OAuth 1.0 request metadata — including consumer keys, signatures, nonces, and timestamps — to be disclosed to attacker-controlled hosts. The flaw affects versions >= 0.5.5 and <= 1.1.5 of the gem and was originally published on June 7, 2026, with the GitHub Advisory Database entry updated on July 28, 2026. It carries a CVSS v3.1 base score of 7.2 (High) (Github Advisory). The patched version is oauth v1.1.6 (v1.1.6 Release).

The root cause lies in OAuth::Consumer#token_request (CWE-200, CWE-346, CWE-918), which blindly trusts the raw Location header returned by any 300–399 HTTP redirect from the OAuth server and follows it recursively without validating the destination origin (Github Advisory). When the redirect target is a different host with the same path, the vulnerable code mutates options[:site] and rebuilds the underlying HTTP client, then re-signs and sends the token request to the new (potentially attacker-controlled) host. There is no redirect counter or maximum redirect limit in affected versions, and no application-level interception occurs before the redirected request is dispatched. The cross-host redirect behavior was intentionally introduced in v0.5.5 (commit d74b767f) and documented as "Allow redirect to different host but same path," but was never restricted to trusted origins (Github Advisory).

Successful exploitation can result in three distinct security failures: cross-origin signed-request metadata disclosure (exposing oauth_consumer_key, oauth_signature, oauth_nonce, oauth_timestamp, oauth_version, and oauth_signature_method to an attacker-controlled host), SSRF from the application server's network position (allowing probing of internal services), and confused-deputy behavior where a trusted application initiates signed requests to an unintended origin (Github Advisory). While the disclosed OAuth 1 signature is bound to the specific request context and is not equivalent to a bearer token, it may be replayable within the receiver's accepted nonce/timestamp window in some deployments and can expose internal network reachability. Availability is not impacted.

1. Identify a target application: Find a Ruby application using the oauth gem (versions 0.5.5–1.1.5) that performs OAuth 1.0 token exchanges via OAuth::Consumer#get_request_token or OAuth::Consumer#get_access_token against a token endpoint whose redirect behavior can be influenced.
2. Control or compromise the OAuth token endpoint redirect: Position as a malicious/compromised OAuth provider, a multi-tenant OAuth gateway that emits Location headers based on tenant-controlled input, or a reverse proxy that can be manipulated to return a 30x redirect to an attacker-controlled host.
3. Return a cross-origin redirect: When the vulnerable client contacts the token endpoint (e.g., https://provider.example/oauth/request_token), respond with an HTTP 302 and a Location header pointing to an attacker-controlled host (e.g., Location: https://attacker.example/oauth/request_token).
4. Receive the signed OAuth request: The vulnerable gem follows the redirect, mutates its internal site configuration to the attacker's host, re-signs the token request for the new destination, and sends it — delivering OAuth 1.0 parameters (oauth_consumer_key, oauth_signature, oauth_nonce, oauth_timestamp, etc.) to the attacker's server.
5. Leverage disclosed metadata: Use the received OAuth parameters for sensitive metadata disclosure, attempt replay within the nonce/timestamp acceptance window if the target server is permissive, or use the SSRF primitive to probe internal services reachable from the application server's network position (Github Advisory).

• Network: Outbound HTTP/HTTPS requests from the application server to unexpected or unknown OAuth provider hosts during token exchange flows; signed OAuth requests (containing Authorization: OAuth oauth_consumer_key=... headers) sent to hosts not matching the configured site value.
• Logs: Application or web server logs showing OAuth token requests directed to hosts other than the configured OAuth provider; unexpected HTTP 302 responses from the OAuth provider followed by requests to a different domain in the same log session.
• Application Behavior: OAuth::Consumer site configuration changing at runtime to an unexpected host; token exchange flows that do not return a valid token but also do not raise an error (indicating the redirect was followed silently).
• File System / Config: No direct file system artifacts expected; however, audit gem lock files (Gemfile.lock) for oauth versions >= 0.5.5 and <= 1.1.5 as a static indicator of exposure (Github Advisory).

Upgrade the oauth RubyGem to version 1.1.6 or later, which rejects cross-origin token endpoint redirects by default, enforces a configurable redirect limit (default: 10), and requires explicit opt-in via token_request_cross_origin_redirects: true for any integration that legitimately requires cross-origin redirects (v1.1.6 Release, Patch Commit). Until patching is possible, mitigations include: ensuring OAuth token endpoint URLs are fixed absolute URLs controlled by a trusted provider; avoiding tenant-controlled OAuth endpoint URLs; blocking outbound application-server traffic to internal metadata services at the network layer; and placing a trusted proxy in front of OAuth providers that rejects cross-origin token endpoint redirects (Github Advisory).

The advisory was authored and coordinated by Peter H. Boling (pboling), the gem maintainer, who discovered the issue during a follow-up audit of a related OAuth 2 advisory (GHSA-pp92-crg2-gfv9) (Github Advisory). No significant broader media coverage or notable third-party researcher commentary has been identified beyond standard vulnerability database aggregation at this time.