mechanize leaked credentials to the redirect target when an HTTP redirect crossed to another host. Credentials set through Mechanize#request headers= leaked even when they were Authorization.

Two defects, both in lib/mechanize/http/agent.rb.

1. Mechanize#request headers= bypassed the redirect strip entirely. #request add headers copied @request headers onto every request unconditionally, with no host check, including the request issued after a redirect. The strip in #response redirect mutated only the per-request headers hash and never touched agent state. Because request headers= is the documented way to set a default credential for every request, the header the code explicitly protected — Authorization — was the one most likely to leak.

2. The strip list omitted Proxy-Authorization and Cookie2. Only CREDENTIAL HEADERS = ['Authorization'] and COOKIE HEADERS = ['Cookie'] were removed from the per-request headers hash on a cross-host redirect.

Cookies held in Mechanize#cookie jar and credentials held in Mechanize::HTTP::AuthStore are not affected. Both are looked up per-URI, so they never follow a redirect to a foreign host. The exposure was limited to headers the caller set by hand.

agent = Mechanize.new
agent.request headers = { 'Authorization' => 'Bearer secret' }
agent.get('https://example.test/redirects-to-attacker')
# the request to the attacker's host carries "Authorization: Bearer secret"

An attacker who controls a redirect target — through an open redirect on the site being fetched, an attacker-supplied fetch URL, DNS rebinding, or MITM — captures bearer tokens and session cookies from any mechanize agent that sets credentials through request headers= or the per-request headers argument. Disclosure only; no integrity or availability impact.

Fixed in mechanize v2.14.1.

Proxy-Authorization is withheld here although curl does not withhold it, because Net::HTTP tunnels https: requests with CONNECT, so a caller-supplied Proxy-Authorization travels inside the tunnel to the origin server rather than to the proxy.

Headers set through Mechanize#request headers= no longer reach a redirect target on another origin when they are credentials. Callers that relied on the previous behavior will see those headers withheld.

Only the headers in CREDENTIAL HEADERS and COOKIE HEADERS are withheld. A caller-supplied header that carries a credential under some other name — X-API-Key, X-Vault-Token, or any bespoke token header — still follows a redirect to another origin, matching the behavior of curl's CURLOPT HTTPHEADER. If you set such a header, do not enable redirect following for requests that carry it, or scope it to a single request whose destination you control.

Set Mechanize#redirect ok = false and handle redirects explicitly, or avoid request headers= for credentials and pass them per-request only to hosts you intend to authenticate to.

Reported by @SnailSploit.