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.