CVE-2026-107399: Mechanize sends credential headers to another origin after a meta refresh
Summary
mechanize applied no trust boundary to a meta refresh, so credentials set through Mechanize#requestheaders= followed a refresh that pointed at another origin.
Details
Mechanize::HTTP::Agent#responsefollowmetarefresh fetched the refresh target with no notion of a crossed origin, so @requestheaders were re-applied in full. An attacker who could place a meta refresh in a page the agent fetched — through stored content, an open redirect, or control of any page in the crawl — collected the same credentials as through an HTTP redirect, on a code path that had none of the redirect path's protections.
The refresh fetch passes an empty per-request headers hash, so only headers set through Mechanize#requestheaders= were exposed.
This requires Mechanize#followmetarefresh = true. It is false by default, so an agent in its default configuration is not affected. Crawlers commonly enable it.
Impact
An attacker who can place a meta refresh in any page the agent fetches captures bearer tokens and session cookies set through requestheaders=. Disclosure only; no integrity or availability impact.
Patches
Fixed in mechanize v2.14.1. A meta refresh that points at another origin is now subject to the same rule as an HTTP redirect: credentials and cookies are withheld from the request that follows it.
Workarounds
Leave Mechanize#followmetarefresh at its default of false, or avoid requestheaders= for credentials when it is enabled.
Other sources
The Mechanize library is used for automating interaction with websites. Prior to 2.14.1, Mechanize applies no origin trust boundary in Mechanize::HTTP::Agent#responsefollowmetarefresh when Mechanize#followmetarefresh is enabled. A page containing a meta refresh to another origin causes headers configured through Mechanize#requestheaders= to be reapplied to the refresh request, allowing an attacker who controls content in the crawl to capture bearer tokens or session cookies. The default configuration is not affected because followmetarefresh is false, and the exposure is limited to caller-supplied default headers. This issue is fixed in version 2.14.1.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
rubygems/mechanizeto a version that resolves this vulnerability.Fixed in 2.14.1 - Upgrade
Upgrade
mechanizeto a version that resolves this vulnerability.Fixed in 2.14.1 - Configuration
Leave Mechanize#follow_meta_refresh disabled (false), its default setting.
Mechanize follow_meta_refresh = false
Event History
Frequently Asked Questions
Who is exposed to credential leakage?
Applications using Mechanize before 2.14.1 are exposed only if they enable follow_meta_refresh and configure sensitive caller-supplied default headers through Mechanize#request_headers=. This can include bearer tokens or session cookies.
What does an attacker need to exploit this issue?
An attacker needs to control content encountered by the crawl and serve a page containing a meta refresh to an attacker-controlled different origin. The refresh causes configured request headers to be reapplied to that origin.
Is the default Mechanize configuration affected?
No. The default configuration has follow_meta_refresh set to false, so meta refreshes are not followed by default.
What should be done if an immediate upgrade is not possible?
Disable follow_meta_refresh and avoid placing bearer tokens, session cookies, or other sensitive values in Mechanize#request_headers=. Upgrade to Mechanize 2.14.1 when possible.