Summary
Mechanize sends credential headers to another origin after a meta refresh
Advisory details
Summary
mechanize applied no trust boundary to a meta refresh, so credentials set through Mechanize#request_headers= followed a refresh that pointed at another origin.
Details
Mechanize::HTTP::Agent#response_follow_meta_refresh fetched the refresh target with no notion of a crossed origin, so @request_headers were re-applied in full. An attacker who could place a meta refresh in a page the agent fetched — through stored content, an open redirect, or control of any page in the crawl — collected the same credentials as through an HTTP redirect, on a code path that had none of the redirect path's protections.
The refresh fetch passes an empty per-request headers hash, so only headers set through Mechanize#request_headers= were exposed.
This requires Mechanize#follow_meta_refresh = true. It is false by default, so an agent in its default configuration is not affected. Crawlers commonly enable it.
Impact
An attacker who can place a meta refresh in any page the agent fetches captures bearer tokens and session cookies set through request_headers=. Disclosure only; no integrity or availability impact.
Patches
Fixed in mechanize v2.14.1. A meta refresh that points at another origin is now subject to the same rule as an HTTP redirect: credentials and cookies are withheld from the request that follows it.
Workarounds
Leave Mechanize#follow_meta_refresh at its default of false, or avoid request_headers= for credentials when it is enabled.
References
- https://github.com/advisories/GHSA-c6rp-p8xm-4q9f
- https://github.com/sparklemotion/mechanize/security/advisories/GHSA-c6rp-p8xm-4q9f
- https://github.com/sparklemotion/mechanize/pull/676
- https://github.com/sparklemotion/mechanize/commit/02a1235842d6eda8d4a5a3d8f13aba2cecf52e4f
- https://github.com/sparklemotion/mechanize/commit/84c74df87d15f5d119df268ba6aa79bc1e16a2c3
- https://github.com/sparklemotion/mechanize/releases/tag/v2.14.1
Related vulnerabilities
All Supply chain →- MEDIUMCVE-2026-107715
Mechanize sends credential headers to another host after an HTTP redirect
- MEDIUMCVE-2026-85717
AsyncHttpClient re-sends client-wide realm credentials to a cross-origin redirect target
- HIGHCVE-2026-55553
urllib's cross-origin redirects preserve credential-bearing request headers, leading to potential credential leakage
- HIGHCVE-2021-41077
Between September 3 and September 10, 2021 a flaw in Travis CI's build activation process, tracked as CVE-2021-41077 and disclosed publicly on September 13, caused secure environment variables to be injected into builds they should never reach. Secret data normally restricted to the private context of a repository was unexpectedly shared with builds triggered by pull requests from forks of public repositories, contradicting the customer's .travis.yml configuration. As a result anyone could fork a public project, open a pull request, and simply print the build environment to read the upstream project's secret environment variables, exposing signing keys, access credentials, and API tokens across thousands of open-source projects. This was a secret-exfiltration-to-forked-builds class flaw; Ethereum's Felix Lange flagged it on September 7 and Travis CI silently patched it on September 10 with no initial post-mortem, prompting affected projects such as conda-forge to rotate roughly 70 feedstock tokens.
- MEDIUMGHSA-8wvg-r2j4-3737
Vikunja: Assignee email addresses disclosed to read-only project members via the task assignees endpoint
- MEDIUMGHSA-3hc7-r24j-rpwc
Vikunja: Cross-project task disclosure through subtask expansion