CVE-2026-107715 in Mechanize
Summary
by MITRE • 10/09/2026
The Mechanize library is used for automating interaction with websites. Prior to 2.14.1, Mechanize sends caller-supplied credential headers to a different host after an HTTP redirect. Mechanize#request_headers= is reapplied by Mechanize::HTTP::Agent#request_add_headers even after Mechanize::HTTP::Agent#response_redirect strips per-request headers, and the protected header lists omit Proxy-Authorization and Cookie2. An attacker who controls a redirect target can capture bearer tokens or session cookies supplied through request_headers= or the per-request headers argument, while Mechanize#cookie_jar and Mechanize::HTTP::AuthStore are not affected. This issue is fixed in version 2.14.1.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/09/2026
The Mechanize library serves as a critical tool for automating interactions with websites, particularly in scenarios requiring complex navigation through forms and redirects. A significant security vulnerability was identified in versions prior to 2.14.1 regarding how the library handles HTTP redirections when custom headers are present. The core of this flaw lies in the interaction between Mechanize#request_headers= and Mechanize::HTTP::Agent#request_add_headers. Specifically, after an HTTP redirect occurs, the mechanism intended to strip per-request headers via Mechanize::HTTP::Agent#response_redirect fails to fully clear all sensitive data. Consequently, caller-supplied credential headers are inadvertently reapplied by request_add_headers even when the target host has changed. This behavior creates a scenario where authentication credentials or session tokens meant for one domain can be transmitted to an entirely different, potentially malicious, destination.
The technical root cause involves specific omissions in the protected header lists managed during redirection. The implementation failed to exclude Proxy-Authorization and Cookie2 headers from being stripped before forwarding requests to new hosts. While Mechanize#cookie_jar and Mechanize::HTTP::AuthStore were correctly isolated and not affected by this flaw, the direct injection of credentials through request_headers= or per-request header arguments remained vulnerable. An attacker who controls a redirect target can exploit this misconfiguration to capture bearer tokens or session cookies that were originally intended for the initial host. This constitutes a classic case of credential leakage across trust boundaries, where sensitive authentication material is exposed due to improper handling of HTTP state during navigation flows.
From an operational impact perspective, this vulnerability enables unauthorized access and data exfiltration if an application relies on Mechanize to interact with untrusted or compromised redirect endpoints. The exposure of bearer tokens allows attackers to impersonate legitimate users across services that share the same authentication infrastructure. Similarly, the leakage of session cookies can lead to session hijacking attacks. This flaw aligns with CWE-200: Information Exposure and CWE-359: Exposure of Private Personal Information to an Unauthorized Actor under the Common Weakness Enumeration framework. In terms of attack vectors, it relates to ATT&CK technique T1583.004: Acquire Infrastructure: Domains, as attackers may set up redirect domains specifically to harvest these credentials during legitimate-looking navigation sequences initiated by vulnerable applications.
Mitigation for this issue is straightforward and involves upgrading the Mechanize library to version 2.14.1 or later, where the header stripping logic has been corrected to ensure that sensitive headers are not forwarded across different hosts unless explicitly intended. For organizations unable to upgrade immediately, implementing a strict allowlist of trusted redirect targets can prevent redirections to uncontrolled domains. Additionally, developers should avoid passing high-privilege credentials through generic request_headers= parameters when interacting with potentially untrusted URLs and instead rely on the library’s built-in authentication stores which were not affected by this specific flaw. Regular auditing of HTTP client configurations for proper header isolation during redirects is recommended as a broader security best practice to prevent similar information disclosure vulnerabilities in automated web interaction tools.