{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata. Fed continuously.","feed_url":"https://feed.craftedsignal.io/products/oauth--0.5.5--1.1.5/feed.json","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["oauth (\u003e= 0.5.5, \u003c= 1.1.5)"],"_cs_severities":["medium"],"_cs_tags":["oauth","vulnerability","ssrf","ruby","gem","web-application"],"_cs_type":"advisory","_cs_vendors":["ruby-oauth"],"content_html":"\u003cp\u003eThe \u003ccode\u003eoauth\u003c/code\u003e Ruby gem, specifically versions 0.5.5 through 1.1.5, contains a critical vulnerability (CVE-2026-54605) in its \u003ccode\u003eOAuth::Consumer#token_request\u003c/code\u003e method. This flaw allows for cross-origin signed-request disclosure, Server-Side Request Forgery (SSRF), and confused-deputy behavior. When an application uses the gem to request OAuth 1.0 tokens, the \u003ccode\u003etoken_request\u003c/code\u003e helper follows HTTP 3xx redirects. If an attacker can control or compromise an OAuth server to return a redirect to a malicious host, the vulnerable gem will re-sign the original token request, including sensitive OAuth 1.0 metadata like \u003ccode\u003eoauth_consumer_key\u003c/code\u003e, \u003ccode\u003eoauth_signature\u003c/code\u003e, \u003ccode\u003eoauth_nonce\u003c/code\u003e, and \u003ccode\u003eoauth_timestamp\u003c/code\u003e, and send it to the attacker-controlled endpoint. This also exposes the application server's network position, enabling SSRF attacks against internal or external targets, and can force the application to make signed requests to unintended origins, leading to confused-deputy scenarios. The vulnerability is due to improper parsing of the \u003ccode\u003eLocation\u003c/code\u003e header, lack of redirect limits, and recursive handling of cross-host redirects that mutate the consumer's configured \u003ccode\u003esite\u003c/code\u003e. Patching to version 1.1.6 or later is recommended.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn application, using the vulnerable \u003ccode\u003eoauth\u003c/code\u003e Ruby gem (v0.5.5-1.1.5), initiates an OAuth 1.0 token request (e.g., \u003ccode\u003eOAuth::Consumer#get_request_token\u003c/code\u003e or \u003ccode\u003eOAuth::Consumer#get_access_token\u003c/code\u003e) to a legitimate OAuth provider.\u003c/li\u003e\n\u003cli\u003eThe OAuth provider's token endpoint, either compromised or influenced by an attacker, responds with an HTTP 3xx redirect. This redirect's \u003ccode\u003eLocation\u003c/code\u003e header points to an attacker-controlled domain (e.g., \u003ccode\u003ehttps://attacker.example/...\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe vulnerable \u003ccode\u003eOAuth::Consumer#token_request\u003c/code\u003e method in the \u003ccode\u003eoauth\u003c/code\u003e gem automatically parses the \u003ccode\u003eLocation\u003c/code\u003e header, modifies the consumer's \u003ccode\u003esite\u003c/code\u003e configuration to the attacker's domain, and rebuilds its internal HTTP client.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eoauth\u003c/code\u003e gem then recursively attempts the token request, this time targeting the attacker-controlled \u003ccode\u003esite\u003c/code\u003e but still using the application's legitimate OAuth 1.0 consumer key and secrets to sign the request.\u003c/li\u003e\n\u003cli\u003eThe application server makes an outbound network connection, sending the newly signed OAuth 1.0 token request, which now includes sensitive parameters like \u003ccode\u003eoauth_consumer_key\u003c/code\u003e, \u003ccode\u003eoauth_signature\u003c/code\u003e, \u003ccode\u003eoauth_nonce\u003c/code\u003e, and \u003ccode\u003eoauth_timestamp\u003c/code\u003e, to the attacker-controlled host.\u003c/li\u003e\n\u003cli\u003eThe 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.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of CVE-2026-54605 can result in three main security property losses: \u003cstrong\u003ecross-origin signed-request metadata disclosure\u003c/strong\u003e, \u003cstrong\u003eServer-Side Request Forgery (SSRF) from the application server\u003c/strong\u003e, and \u003cstrong\u003econfused-deputy behavior\u003c/strong\u003e. Attackers can receive sensitive OAuth 1.0 parameters such as \u003ccode\u003eoauth_consumer_key\u003c/code\u003e, \u003ccode\u003eoauth_signature_method\u003c/code\u003e, \u003ccode\u003eoauth_timestamp\u003c/code\u003e, \u003ccode\u003eoauth_nonce\u003c/code\u003e, \u003ccode\u003eoauth_version\u003c/code\u003e, and \u003ccode\u003eoauth_signature\u003c/code\u003e. 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003ePatch the \u003ccode\u003eoauth\u003c/code\u003e Ruby gem to version 1.1.6 or later immediately to address CVE-2026-54605.\u003c/li\u003e\n\u003cli\u003eEnsure configured OAuth token endpoints are fixed absolute URLs controlled by a trusted provider, as described in the \u0026quot;Workarounds\u0026quot; section in the source advisory.\u003c/li\u003e\n\u003cli\u003eAvoid using tenant-controlled OAuth token endpoint URLs unless the tenant is fully trusted, as outlined in the \u0026quot;Workarounds\u0026quot; section in the source advisory.\u003c/li\u003e\n\u003cli\u003eImplement network egress filtering to block outbound application-server traffic to internal metadata services and other sensitive internal addresses, particularly for services interacting with the \u003ccode\u003eoauth\u003c/code\u003e gem.\u003c/li\u003e\n\u003cli\u003eDeploy a trusted proxy in front of OAuth providers that explicitly rejects token endpoint redirects to different origins, as described in the \u0026quot;Workarounds\u0026quot; section in the source advisory.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-07-28T16:28:12Z","date_published":"2026-07-28T16:28:12Z","id":"https://feed.craftedsignal.io/briefs/2026-07-oauth-cross-origin-redirect/","summary":"The 'oauth' Ruby gem versions 0.5.5 through 1.1.5 are vulnerable to a critical issue (CVE-2026-54605) where the 'OAuth::Consumer#token_request' method improperly handles HTTP 3xx redirects during OAuth 1.0 token exchanges, enabling an attacker to redirect the request to a malicious host, exposing sensitive OAuth 1.0 metadata, and facilitating Server-Side Request Forgery (SSRF) and confused-deputy behavior.","title":"Cross-origin OAuth token-request redirects can expose signed request metadata","url":"https://feed.craftedsignal.io/briefs/2026-07-oauth-cross-origin-redirect/"}],"language":"en","title":"CraftedSignal Threat Feed - Oauth (\u003e= 0.5.5, \u003c= 1.1.5)","version":"https://jsonfeed.org/version/1.1"}