{"id":"CVE-2026-107715","aliases":["DEBIAN-CVE-2026-107715","EUVD-2026-95321","GHSA-2mwr-xjcg-37j7","UBUNTU-CVE-2026-107715"],"status":"published","title":"Mechanize sends credential headers to another host after an HTTP redirect","description":"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.","severity":{"version":"3.1","score":6.8,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:N","level":"medium","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-12","score":0.00501,"percentile":0.43427,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-200","CWE-522"],"published":"2026-10-08T21:27:24Z","modified":"2026-10-28T02:30:55Z","fixes":[{"ecosystem":"RubyGems","package":"mechanize","fixed_in":["2.14.1"],"sources":["ghsa","osv"]},{"ecosystem":"Debian:14","package":"ruby-mechanize","fixed_in":["2.14.1-1"],"sources":["osv"]}],"affected":[{"source":"ghsa","ecosystem":"RubyGems","package":"mechanize","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2.14.1"}]}]},{"source":"osv","ecosystem":"Debian:12","package":"ruby-mechanize","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["2.10.1-1","2.10.1-1.1","2.14.0-1","2.14.0-2","2.14.1-1","2.8.5-1"]},{"source":"osv","ecosystem":"Debian:13","package":"ruby-mechanize","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["2.10.1-1","2.10.1-1.1","2.14.0-1","2.14.0-2","2.14.1-1"]},{"source":"osv","ecosystem":"Debian:14","package":"ruby-mechanize","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2.14.1-1"}]}],"versions":["2.10.1-1","2.10.1-1.1","2.14.0-1","2.14.0-2"]},{"source":"osv","ecosystem":"RubyGems","package":"mechanize","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2.14.1"}]}],"versions":["0.1.0","0.1.1","0.1.2","0.1.3","0.2.0","0.2.1","0.2.2","0.2.3","0.3.0","0.3.1","0.4.0","0.4.1","0.4.2","0.4.3","0.4.4","0.4.5","0.4.6","0.4.7","0.5.0","0.5.1","0.5.2","0.5.3","0.5.4","0.6.0","0.6.1","0.6.10","0.6.11","0.6.2","0.6.3","0.6.4","0.6.5","0.6.6","0.6.7","0.6.8","0.6.9","0.7.0","0.7.1","0.7.2","0.7.3","0.7.4","0.7.5","0.7.6","0.7.7","0.7.8","0.8.0","0.8.1","0.8.2","0.8.3","0.8.4","0.8.5","0.9.0","0.9.1","0.9.2","0.9.3","1.0.0","1.0.1.beta.20110107104205","2.0","2.0.1","2.0.pre.1","2.0.pre.2","2.1","2.1.1","2.1.pre.1","2.10.0","2.10.1","2.11.0","2.12.0","2.12.1","2.12.2","2.13.0","2.14.0","2.2","2.2.1","2.3","2.4","2.5","2.5.1","2.6.0","2.7.0","2.7.1","2.7.2","2.7.3","2.7.4","2.7.5","2.7.6","2.7.7","2.8.0","2.8.1","2.8.2","2.8.3","2.8.4","2.8.5","2.9.0","2.9.1","2.9.2"]},{"source":"osv","ecosystem":"Ubuntu:16.04:LTS","package":"ruby-mechanize","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["2.7.3-1"]},{"source":"osv","ecosystem":"Ubuntu:18.04:LTS","package":"ruby-mechanize","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["2.7.5-1","2.7.5-2"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"ruby-mechanize","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["2.7.6-1"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"ruby-mechanize","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["2.7.7-1","2.7.7-3"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"ruby-mechanize","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["2.8.5-1"]},{"source":"osv","ecosystem":"Ubuntu:26.10","package":"ruby-mechanize","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["2.10.1-1.1","2.14.0-2"]},{"source":"osv","ecosystem":"Ubuntu:26.04:LTS","package":"ruby-mechanize","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["2.10.1-1.1"]}],"products":[{"vendor":"python-mechanize","product":"mechanize"},{"vendor":"sparklemotion","product":"mechanize"}],"references":[{"url":"https://github.com/sparklemotion/mechanize/security/advisories/GHSA-2mwr-xjcg-37j7","tags":["x_refsource_CONFIRM","exploit","advisory","web","report"]},{"url":"https://github.com/sparklemotion/mechanize/pull/676","tags":["x_refsource_MISC","fix","web","report"]},{"url":"https://github.com/sparklemotion/mechanize/commit/02a1235842d6eda8d4a5a3d8f13aba2cecf52e4f","tags":["x_refsource_MISC","fix","web","report"]},{"url":"https://github.com/sparklemotion/mechanize/commit/94e0902867296be804f36eccbb47acf7d5018745","tags":["x_refsource_MISC","fix","web","report"]},{"url":"https://github.com/sparklemotion/mechanize/commit/ac49abf2869297d83c3b11bbfb8b18e63b588c95","tags":["x_refsource_MISC","fix","web","report"]},{"url":"https://github.com/sparklemotion/mechanize/releases/tag/v2.14.1","tags":["x_refsource_MISC","web","report"]},{"url":"https://github.com/advisories/GHSA-2mwr-xjcg-37j7"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/107xxx/CVE-2026-107715.json","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-107715","tags":["advisory"]},{"url":"https://security-tracker.debian.org/tracker/CVE-2026-107715","tags":["advisory"]},{"url":"https://github.com/sparklemotion/mechanize","tags":["package"]},{"url":"https://ubuntu.com/security/CVE-2026-107715","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-107715","tags":["report"]}],"sources":{"cve":[{"id":"CVE-2026-107715","title":"Mechanize sends credential headers to another host after an HTTP redirect","description":"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.","status":"published","published":"2026-10-08T21:27:24.651Z","modified":"2026-10-09T13:22:27.174Z","cvss":[{"version":"3.1","score":6.8,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:N","level":"medium","assessor":"cna"}],"cwes":["CWE-200","CWE-522"],"updated_at":"2026-11-02T13:45:25.313702Z"}],"euvd":[{"id":"EUVD-2026-95321","description":"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.","status":"published","published":"2026-10-08T21:27:24Z","modified":"2026-10-09T13:22:27Z","cvss":[{"version":"3.1","score":6.8,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:N","level":"medium"}],"updated_at":"2026-11-02T17:27:25.459601Z"}],"ghsa":[{"id":"GHSA-2mwr-xjcg-37j7","title":"Mechanize sends credential headers to another host after an HTTP redirect","description":"## Summary\n\n`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`.\n\n## Details\n\nTwo defects, both in `lib/mechanize/http/agent.rb`.\n\n**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.\n\n**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.\n\nCookies 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.\n\n## PoC\n\n```ruby\nagent = Mechanize.new\nagent.request_headers = { 'Authorization' =\u003e 'Bearer secret' }\nagent.get('https://example.test/redirects-to-attacker')\n# the request to the attacker's host carries \"Authorization: Bearer secret\"\n```\n\n## Impact\n\nAn 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.\n\n## Patches\n\nFixed in `mechanize` v2.14.1.\n\n- Credentials and cookies are withheld from a request that follows a redirect across an origin, from **both** header sources: the per-request `headers` argument and `Mechanize#request_headers=`.\n- `CREDENTIAL_HEADERS` gains `Proxy-Authorization`; `COOKIE_HEADERS` gains `Cookie2`.\n\n`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.\n\nHeaders 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.\n\n### What this fix does not cover\n\nOnly 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.\n\n## Workarounds\n\nSet `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.\n\n## Credit\n\nReported by @SnailSploit.","status":"published","published":"2026-10-08T22:09:00Z","modified":"2026-10-08T22:09:01Z","cvss":[{"version":"3.1","score":6.8,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:N","level":"medium"}],"cwes":["CWE-200","CWE-522"],"updated_at":"2026-11-02T14:41:30.097746Z"}],"nvd":[{"id":"CVE-2026-107715","description":"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.","status":"published","published":"2026-10-08T22:17:27.163Z","modified":"2026-10-09T16:40:29.8Z","cvss":[{"version":"3.1","score":6.8,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:N","level":"medium","assessor":"secondary"}],"cwes":["CWE-200","CWE-522"],"updated_at":"2026-11-02T14:12:55.142936Z"}],"osv":[{"id":"CVE-2026-107715","title":"Mechanize sends credential headers to another host after an HTTP redirect","description":"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.","status":"published","published":"2026-10-08T21:27:24.651Z","modified":"2026-10-28T02:30:55.752421496Z","cvss":[{"version":"3.1","score":6.8,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:N","level":"medium"}],"cwes":["CWE-200","CWE-522"],"updated_at":"2026-11-02T15:44:54.933106Z"},{"id":"DEBIAN-CVE-2026-107715","description":"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.","status":"published","published":"2026-10-08T22:17:27.163Z","modified":"2026-10-10T09:47:40.242536721Z","cvss":[{"version":"3.1","score":6.8,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:N","level":"medium"}],"updated_at":"2026-11-02T15:45:49.381767Z"},{"id":"GHSA-2mwr-xjcg-37j7","title":"Mechanize sends credential headers to another host after an HTTP redirect","description":"## Summary\n\n`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`.\n\n## Details\n\nTwo defects, both in `lib/mechanize/http/agent.rb`.\n\n**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.\n\n**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.\n\nCookies 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.\n\n## PoC\n\n```ruby\nagent = Mechanize.new\nagent.request_headers = { 'Authorization' =\u003e 'Bearer secret' }\nagent.get('https://example.test/redirects-to-attacker')\n# the request to the attacker's host carries \"Authorization: Bearer secret\"\n```\n\n## Impact\n\nAn 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.\n\n## Patches\n\nFixed in `mechanize` v2.14.1.\n\n- Credentials and cookies are withheld from a request that follows a redirect across an origin, from **both** header sources: the per-request `headers` argument and `Mechanize#request_headers=`.\n- `CREDENTIAL_HEADERS` gains `Proxy-Authorization`; `COOKIE_HEADERS` gains `Cookie2`.\n\n`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.\n\nHeaders 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.\n\n### What this fix does not cover\n\nOnly 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.\n\n## Workarounds\n\nSet `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.\n\n## Credit\n\nReported by @SnailSploit.","status":"published","published":"2026-10-08T22:09:00Z","modified":"2026-10-08T22:15:07.251994937Z","cvss":[{"version":"3.1","score":6.8,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:N","level":"medium"}],"cwes":["CWE-200","CWE-522"],"updated_at":"2026-11-02T15:46:34.700741Z"},{"id":"UBUNTU-CVE-2026-107715","description":"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.","status":"published","published":"2026-10-08T22:17:00Z","modified":"2026-10-17T12:58:01.702362472Z","cvss":[{"version":"3.1","score":6.8,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:N","level":"medium"}],"updated_at":"2026-11-02T16:55:59.130573Z"}]}}