mechanize applied no trust boundary to a meta refresh, so credentials set through Mechanize#request_headers= followed a refresh that pointed at another origin.
Mechanize::HTTP::Agent#response_follow_meta_refresh fetched the refresh target with no notion of a crossed origin, so @request_headers 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#request_headers= were exposed.
This requires Mechanize#follow_meta_refresh = true. It is false by default, so an agent in its default configuration is not affected. Crawlers commonly enable it.
An attacker who can place a meta refresh in any page the agent fetches captures bearer tokens and session cookies set through request_headers=. Disclosure only; no integrity or availability impact.
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.
Leave Mechanize#follow_meta_refresh at its default of false, or avoid request_headers= for credentials when it is enabled.
{
"cwe_ids": [
"CWE-200",
"CWE-522"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-08T22:09:03Z",
"nvd_published_at": null,
"severity": "MODERATE"
}