Mechanize leaked credentials across origins on meta refresh

A security advisory published on 8 October 2026 says the Ruby library mechanize sent credential headers to a different origin when it followed an HTML meta refresh, handing bearer tokens and session cookies to whoever controlled the destination. The issue is tracked as CVE-2026-107399 and is fixed in mechanize version 2.14.1.

Mechanize is distributed through RubyGems and is used to fetch and navigate web pages automatically. According to the advisory, the library applied no trust boundary to a meta refresh, which is an instruction embedded in a page telling the client to load another URL. Credentials set through the Mechanize#request_headers= method followed that refresh even when it pointed at a different site.

The advisory explains that the method Mechanize::HTTP::Agent#response_follow_meta_refresh fetched the refresh target with no notion of a crossed origin, so the stored @request_headers were re-applied in full. That code path had none of the protections the library already applied to ordinary HTTP redirects. In effect, an attacker got the same result as through an HTTP redirect, but on the route that was not guarded.

An attacker needed only to place a meta refresh in a page that the agent fetched. The advisory lists three ways that could happen: stored content, an open redirect, or control of any page in the crawl. From there, the advisory says, the attacker "captures bearer tokens and session cookies set through request_headers=".

The exposure has limits. The advisory notes that the refresh fetch passes an empty per-request headers hash, so only headers set through the agent-wide Mechanize#request_headers= method were exposed, not headers attached to an individual request. The impact is described as disclosure only, with no integrity or availability impact.

The behaviour also required a non-default setting. The advisory says the bug only triggers when Mechanize#follow_meta_refresh is set to true. That option is false by default, so an agent in its default configuration is not affected. However, the advisory adds that crawlers commonly enable it, which is the circumstance in which the stored credentials would travel.

The fix in version 2.14.1 brings the two code paths into line. According to the advisory, a meta refresh that points at another origin is now subject to the same rule as an HTTP redirect, and credentials and cookies are withheld from the request that follows it.

For anyone who cannot upgrade immediately, the advisory gives two workarounds. The first is to leave Mechanize#follow_meta_refresh at its default of false. The second is to avoid using request_headers= to carry credentials when meta refresh following is switched on, which would mean attaching authentication per request instead.

The pattern is a familiar one for automated agents that browse the open web. Credentials held at the agent level are convenient, because every request the agent makes is authenticated without extra code. The cost is that the agent, not the developer, decides where those credentials go next, and that decision can be influenced by content the agent downloads. The advisory frames the fix precisely in those terms: the question is not whether to follow the refresh, but whether a crossed origin counts as a trust boundary. In mechanize before 2.14.1, it did not.