Attack Chain

1. An application, using OAuth2::AccessToken via OAuth2::Client, initiates a request to a trusted Identity Provider (IdP) or resource server, including an Authorization: Bearer <access-token> header.
2. An attacker, by exploiting an open redirect vulnerability on the IdP, configuring a malicious tenant in a multi-tenant setup, or through a network compromise, causes the IdP to issue an HTTP 30x redirect response.
3. The crafted redirect response's Location header contains a protocol-relative URI pointing to an attacker-controlled host (e.g., //attacker.example/leak).
4. The OAuth2::Client#request method attempts to resolve this redirect by calling response.response.env.url.merge(location). Per RFC 3986 §5.2, URI#merge interprets the protocol-relative URI as a network-path reference, which overrides the authority (scheme and host) of the base URL.
5. The library then recursively re-invokes request(verb, full_location, req_opts) using the newly resolved attacker-controlled URL. Crucially, the req_opts dictionary, containing the original request headers, is passed verbatim.
6. The Authorization: Bearer <access-token> header, initially set by OAuth2::AccessToken#configure_authentication!, is preserved and transmitted in the request to the attacker's host.
7. The attacker-controlled server receives the application's bearer token, achieving immediate cross-origin credential disclosure without further user interaction.
8. Alternatively, if the Location URI specifies an internal network address (e.g., //169.254.169.254/), the application server acts as a Server-Side Request Forgery (SSRF) proxy, allowing the attacker to interact with internal resources.

Impact

Successful exploitation of this vulnerability results in two primary impacts:

1. Cross-origin credential disclosure: The immediate consequence is the theft of Authorization: Bearer tokens. Any application utilizing the vulnerable oauth2 gem to communicate with an IdP susceptible to such redirection risks having its access tokens exfiltrated to an attacker-controlled server. This can lead to unauthorized access to user data or resources that the stolen token grants access to.
2. Server-Side Request Forgery (SSRF): The ability to redirect the application's requests to an arbitrary host also enables SSRF. Attackers can leverage this to force the application server to make requests to internal network services, cloud metadata endpoints (e.g., 169.254.169.254), or other restricted resources that are typically inaccessible from the internet. This could facilitate reconnaissance, lateral movement, or further exploitation within an organization's internal infrastructure. Given the widespread use of OAuth2 in modern applications, the potential number of affected services and organizations is substantial across all sectors.

Recommendation

• Upgrade the oauth2 gem to version 2.0.22 or later immediately to address CVE-2026-54603.
• Apply the suggested patch logic to OAuth2::Client#request as an interim measure if immediate gem upgrade is not possible. This involves forcing protocol-relative Location values to be interpreted as relative paths by prepending ./ before URI#merge.
• Developers should review their Identity Provider (IdP) and resource server configurations to ensure they do not expose open redirect vulnerabilities that could be abused to supply malicious Location headers.
• Implement defense-in-depth measures to strip credential-bearing headers (like Authorization) from requests when a redirect crosses origin boundaries, similar to how robust HTTP clients handle such scenarios.

Attack Chain

1. An application, using the vulnerable oauth Ruby gem (v0.5.5-1.1.5), initiates an OAuth 1.0 token request (e.g., OAuth::Consumer#get_request_token or OAuth::Consumer#get_access_token) to a legitimate OAuth provider.
2. The OAuth provider's token endpoint, either compromised or influenced by an attacker, responds with an HTTP 3xx redirect. This redirect's Location header points to an attacker-controlled domain (e.g., https://attacker.example/...).
3. The vulnerable OAuth::Consumer#token_request method in the oauth gem automatically parses the Location header, modifies the consumer's site configuration to the attacker's domain, and rebuilds its internal HTTP client.
4. The oauth gem then recursively attempts the token request, this time targeting the attacker-controlled site but still using the application's legitimate OAuth 1.0 consumer key and secrets to sign the request.
5. The application server makes an outbound network connection, sending the newly signed OAuth 1.0 token request, which now includes sensitive parameters like oauth_consumer_key, oauth_signature, oauth_nonce, and oauth_timestamp, to the attacker-controlled host.
6. The attacker receives this signed request, gaining access to sensitive integration metadata and potentially discovering internal network services via Server-Side Request Forgery (SSRF) if the attacker's endpoint is crafted to target internal resources from the application server's network position.

Impact

Successful exploitation of CVE-2026-54605 can result in three main security property losses: cross-origin signed-request metadata disclosure, Server-Side Request Forgery (SSRF) from the application server, and confused-deputy behavior. Attackers can receive sensitive OAuth 1.0 parameters such as oauth_consumer_key, oauth_signature_method, oauth_timestamp, oauth_nonce, oauth_version, and oauth_signature. While the disclosed OAuth 1 signature is bound to the signed request and not a reusable bearer token, it still exposes sensitive integration metadata. SSRF allows the attacker to use the application server's network position to access internal network resources or other targets. Confused-deputy behavior enables a malicious or compromised token endpoint to cause the trusted application to initiate signed requests to unintended origins, potentially granting the attacker unauthorized access or control.

Recommendation

• Patch the oauth Ruby gem to version 1.1.6 or later immediately to address CVE-2026-54605.
• Ensure configured OAuth token endpoints are fixed absolute URLs controlled by a trusted provider, as described in the "Workarounds" section in the source advisory.
• Avoid using tenant-controlled OAuth token endpoint URLs unless the tenant is fully trusted, as outlined in the "Workarounds" section in the source advisory.
• Implement network egress filtering to block outbound application-server traffic to internal metadata services and other sensitive internal addresses, particularly for services interacting with the oauth gem.
• Deploy a trusted proxy in front of OAuth providers that explicitly rejects token endpoint redirects to different origins, as described in the "Workarounds" section in the source advisory.