GHSA-C6RP-P8XM-4Q9F
Vulnerability from github – Published: 2026-10-08 22:09 – Updated: 2026-10-08 22:09Summary
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.
{
"affected": [
{
"package": {
"ecosystem": "RubyGems",
"name": "mechanize"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.14.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-107399"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-522"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-08T22:09:03Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n\n`mechanize` applied no trust boundary to a `meta` refresh, so credentials set through `Mechanize#request_headers=` followed a refresh that pointed at another origin.\n\n## Details\n\n`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 \u2014 through stored content, an open redirect, or control of any page in the crawl \u2014 collected the same credentials as through an HTTP redirect, on a code path that had none of the redirect path\u0027s protections.\n\nThe refresh fetch passes an empty per-request headers hash, so only headers set through `Mechanize#request_headers=` were exposed.\n\nThis 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.\n\n## Impact\n\nAn 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.\n\n## Patches\n\nFixed 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.\n\n## Workarounds\n\nLeave `Mechanize#follow_meta_refresh` at its default of `false`, or avoid `request_headers=` for credentials when it is enabled.",
"id": "GHSA-c6rp-p8xm-4q9f",
"modified": "2026-10-08T22:09:03Z",
"published": "2026-10-08T22:09:03Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/sparklemotion/mechanize/security/advisories/GHSA-c6rp-p8xm-4q9f"
},
{
"type": "WEB",
"url": "https://github.com/sparklemotion/mechanize/pull/676"
},
{
"type": "WEB",
"url": "https://github.com/sparklemotion/mechanize/commit/02a1235842d6eda8d4a5a3d8f13aba2cecf52e4f"
},
{
"type": "WEB",
"url": "https://github.com/sparklemotion/mechanize/commit/84c74df87d15f5d119df268ba6aa79bc1e16a2c3"
},
{
"type": "PACKAGE",
"url": "https://github.com/sparklemotion/mechanize"
},
{
"type": "WEB",
"url": "https://github.com/sparklemotion/mechanize/releases/tag/v2.14.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Mechanize sends credential headers to another origin after a meta refresh"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.