Mechanize leaked auth headers to redirect targets

The Ruby library mechanize sent credential headers to a different host after an HTTP redirect, according to a GitHub security advisory published on 8 October 2026. The flaw, tracked as CVE-2026-107715, affected any mechanize agent that set credentials through Mechanize#request_headers= or the per-request headers argument. The maintainers say the impact is disclosure only, with no integrity or availability impact. It is fixed in mechanize v2.14.1.

The advisory describes two defects, both in lib/mechanize/http/agent.rb. The first is that request_headers= bypassed the library's redirect protection entirely. The internal method that adds headers copied the agent's stored headers onto every request without checking the host, including the request issued after a redirect. The code that stripped credentials on a cross-host redirect only mutated the per-request headers hash and never touched the agent's own state. Because request_headers= is the documented way to set a default credential for every request, the advisory notes the irony: the header the code explicitly tried to protect, Authorization, was the one most likely to leak.

The second defect is that the strip list was incomplete. Only Authorization and Cookie were removed on a cross-host redirect, leaving Proxy-Authorization and Cookie2 in place.

The proof of concept in the advisory is three lines: create an agent, set an Authorization: Bearer secret header through request_headers=, then fetch a URL that redirects elsewhere. The request to the attacker's host carries the bearer token.

Credentials held in Mechanize#cookie_jar and in Mechanize::HTTP::AuthStore are not affected, the advisory says, because both are looked up per URI and so never follow a redirect to a foreign host. The exposure was limited to headers the caller set by hand.

An attacker would need to control the redirect target. The advisory lists several routes to that: an open redirect on the site being fetched, an attacker-supplied fetch URL, DNS rebinding, or a machine-in-the-middle position. Any of these would let the attacker capture bearer tokens and session cookies.

The fix withholds credentials and cookies from a request that follows a redirect across an origin, from both header sources. Proxy-Authorization has been added to the credential list and Cookie2 to the cookie list. The maintainers explain that they withhold Proxy-Authorization even though curl does not, because Net::HTTP tunnels https: requests with CONNECT, meaning a caller-supplied Proxy-Authorization travels inside the tunnel to the origin server rather than to the proxy. Callers who relied on the old behaviour will find those headers withheld.

The patch is deliberately narrow. Only the headers on the two named lists are withheld. A caller-supplied header that carries a credential under another name, such as X-API-Key, X-Vault-Token or any bespoke token header, still follows a redirect to another origin, matching the behaviour of curl's CURLOPT_HTTPHEADER. The advisory advises anyone setting such a header to disable redirect following on requests that carry it, or to scope it to a single request with a destination the caller controls.

For those who cannot upgrade immediately, the suggested workarounds are to set Mechanize#redirect_ok = false and handle redirects explicitly, or to avoid request_headers= for credentials and pass them per request only to hosts the caller intends to authenticate to. The issue was reported by a researcher credited in the advisory as @SnailSploit.