RubySec

Providing security resources for the Ruby community

CVE-2026-107715 (mechanize): Mechanize sends credential headers to another host after an HTTP redirect

Mechanize sends credential headers to another host after an HTTP redirect

Published: October 08, 2026

SECURITY IDENTIFIERS

GEM

mechanize

SEVERITY

CVSS v3.x: 6.8 (Medium)

PATCHED VERSIONS

>= 2.14.1

DESCRIPTION

Summary

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.

Details

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.

Impact

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.

Credit

Reported by @SnailSploit.

RELATED