CVE-2026-107715: Information Disclosure and Credential Leakage in Ruby Mechanize via Cross-Origin Redirections

The Ruby Mechanize library, prior to version 2.14.1, contains an information disclosure vulnerability where caller-supplied credential headers are forwarded to external hosts following HTTP redirections. Mechanize is an automation and web-scraping framework designed to simulate browser behavior, handle session cookies, and manage state across multiple HTTP transactions. Because scraping agents often follow redirections automatically, the boundary between trusted origins and untrusted destinations must be strictly maintained.

The flaw exists within the redirection logic managed by the Mechanize::HTTP::Agent class. When a client application configures global headers or per-request credentials, these secrets are retained and re-applied to requests initiated during redirect chains. If a redirection points to a third-party domain, the agent fails to isolate these headers, transmitting sensitive data such as Authorization, Proxy-Authorization, Cookie, and Cookie2 headers to unverified external endpoints.

This behavior violates the basic principles of the Same-Origin Policy (SOP). It allows any intermediary or target server in a redirection chain to capture authorization tokens and session keys intended exclusively for the original server. The issue represents a critical flaw in applications that scrape user-submitted URLs or traverse untrusted web endpoints while maintaining authenticated sessions.

The technical root cause of this vulnerability lies in the structural separation of concerns between per-request state and persistent agent-level state in lib/mechanize/http/agent.rb. When a developer configures default headers using the Mechanize#request_headers= setter, these headers are saved to the instance variable @request_headers. During an initial request, these values are merged into the request payload.

Upon encountering an HTTP redirect (such as a 301, 302, or 307 status code), the library executes Mechanize::HTTP::Agent#response_redirect. This method contains sanitization logic that strips sensitive headers like Authorization and Cookie when the target URI differs from the current URI. However, this sanitization only mutates the temporary, per-request header dictionary passed as an argument. It does not alter the persistent @request_headers configuration on the agent instance.

When the agent attempts to fetch the target of the redirection, it initiates a new HTTP request and invokes #request_add_headers. This method iterates over the unmodified @request_headers hash and unconditionally re-applies all configurations back into the outgoing request. As a result, headers that were stripped during the redirect phase are silently re-inserted prior to transmission over the network.

Additionally, the blacklist used to identify sensitive headers in older versions was incomplete. It did not include standard headers like Proxy-Authorization or Cookie2. Furthermore, the library evaluated host matches solely by comparing hostname strings (new_uri.host == page.uri.host). This comparison ignored variations in port numbers and protocol schemes, allowing credential leaks to occur when downgrading from HTTPS to plaintext HTTP on the same host.

The following block demonstrates the vulnerable state restoration inside lib/mechanize/http/agent.rb before the security patch was applied. Note how @request_headers are read and written directly to the request object, rendering the stripping logic in #response_redirect ineffective.

# VULNERABLE: lib/mechanize/http/agent.rb
# In older versions, every fetch operation re-applied `@request_headers` from scratch.
 
def request_add_headers(request, headers = {})
  # Global headers are unconditionally added to every single request,
  # including intermediate redirect hops where they should have been stripped.
  @request_headers.each do |k, v|
    request[k] = v
  end
 
  headers.each do |k, v|
    request[k] = v
  end
end

The patch implemented in version 2.14.1 introduces a mechanism to control when global headers are merged. Instead of dynamically re-applying global state on every request execution, the library now merges @request_headers exactly once when a top-level request is initiated by the user. Subsequent hops in a redirect chain set apply_request_headers to false.

The following code block highlights the remediation implemented in the patched version. The origin comparison was also updated to conform with RFC 6454 rules, checking the protocol scheme, hostname, and port number to detect cross-origin boundaries accurately.

# PATCHED: lib/mechanize/http/agent.rb
# Global headers are merged only once at the beginning of the transaction.
 
def fetch(uri, method = :get, headers = {}, params = [], referer = nil,
          redirect_ok = @redirect_ok, apply_request_headers = true)
  
  # Merge global request headers only if this is the initial request
  headers = merge_request_headers(headers) if apply_request_headers
 
  # ... request processing and redirect logic
end
 
# The comparison is expanded to ensure scheme, host, and port are validated.
def crosses_origin?(from_uri, to_uri)
  to_uri.scheme != from_uri.scheme ||
    to_uri.host != from_uri.host ||
    to_uri.port != from_uri.port
end

By ensuring that apply_request_headers is disabled for redirection loops and authentication retries, the updated library prevents the restoration of stripped credentials. The blacklisted headers list was also expanded to include Proxy-Authorization and Cookie2 in the constant lists.

Exploitation of this vulnerability requires that an attacker induce a Mechanize-based client to send an authenticated request to a domain under the attacker's control, or to a trusted site containing an open redirect vulnerability. In a typical scenario, a target application uses Mechanize to fetch and parse external content, passing a user-supplied URL as a parameter while carrying administrative or session tokens in the global headers.

If the attacker hosts a page that issues an HTTP 302 redirect pointing to their own server, Mechanize follows the redirect. Because of the bug in #request_add_headers, the original Authorization and Cookie headers are re-injected and sent directly to the attacker-controlled server. The attacker can log these headers to capture the authentication bearer tokens or session cookies.

This behavior also occurs through HTML <meta> refresh tags found in scraped pages. If Mechanize parses a page containing <meta http-equiv="refresh" content="0;url=http://attacker.com">, it triggers an internal redirect mechanism via #response_follow_meta_refresh. In vulnerable versions, this flow does not isolate the origin, causing the agent to include global authentication headers when querying the attacker's web page.

The security impact of this vulnerability is classified as Medium with a CVSS v3.1 base score of 6.8. The primary risk is the loss of confidentiality of highly sensitive session and authentication secrets. Because Mechanize is frequently used to scrape websites, access APIs, or perform automated testing, these leaked credentials often represent critical user accounts or API keys.

The CVSS vector breakdown (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:N) highlights specific environmental factors. The attack vector is Network (AV:N), indicating that exploitation can occur over the internet. Attack Complexity is High (AC:H) because the attacker must find or control a redirection target that the Mechanize instance can be persuaded to fetch.

The Scope is Changed (S:C) because credentials belonging to one origin are transmitted to a different security domain. The impact is limited to Confidentiality (C:H) as the flaw allows reading the headers but does not directly modify data on the client or compromise system availability. However, the stolen credentials can subsequently be used to gain unauthorized access to target systems, escalating the total impact.

The most complete remediation is upgrading the Mechanize gem to version 2.14.1 or later. This release restructures the header lifecycles to ensure that global credentials are not persistently re-applied to redirect requests. Developers can update their dependency files to enforce this minimum version.

# Update Mechanize within the project environment
bundle update mechanize

If immediate upgrading is not possible, developers should avoid using the global Mechanize#request_headers= setter to assign sensitive information like API tokens and authorization headers. Instead, credentials should be supplied dynamically as argument overrides for specific, targeted #get or #post requests. This pattern prevents the agent from storing the secrets in its long-lived state.

Alternatively, automatic redirection can be disabled by setting agent.redirect_ok = false. Under this configuration, the application must catch redirection responses manually, inspect the target location, and explicitly verify that the destination belongs to a trusted domain before executing a separate, sanitized request.