Mechanize EUVD-2026-95320

Exploitation requires that the consuming application has set caller-supplied credential headers - specifically an Authorization/Proxy-Authorization or Cookie/Cookie2 header via a per-request header or Mechanize#request_headers= - AND that the application follows a redirect from a host the attacker can influence. The concrete triggering condition is a same-host redirect that changes the scheme (HTTPS→HTTP cleartext downgrade) or the port (sending a caller-supplied Cookie to a different service on the same host); pre-fix Mechanize discarded headers only on a host change, not on scheme/port changes. Limiting factors that reduce realistic risk: the attacker must control or MITM the redirect response, the application must actually inject its own sensitive headers (default scraping without auth headers is not exposed), and cookies managed by Mechanize#cookie_jar are correctly scoped and are NOT leaked - only caller-supplied headers are. Impact is confidentiality-only (no integrity or availability effect).

This is a moderate-severity information-disclosure flaw (CVSS 5.9, CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N) whose real-world risk is tempered by the high attack complexity. The network vector and PR:N correctly reflect that no credentials are needed to trigger the bug, but AC:H is appropriate because exploitation depends on a specific sequence of conditions: the client application must set caller-supplied Authorization/Cookie headers AND must follow a same-host redirect that either downgrades HTTPS→HTTP or changes the port. The C:H/I:N/A:N profile matches the described impact - credential disclosure only, with no effect on integrity or availability. No EPSS score, CISA KEV listing, or POC is present in the supplied data, so there is no signal of active or imminent exploitation; status is 'no public exploit identified at time of analysis.' The signals are internally consistent (a credential-leak CWE-200 with confidentiality-only impact and high complexity), so this reads as a genuine-but-not-urgent defensive patch priority rather than a high-CVSS/low-real-risk false alarm, and importantly below a critical/emergency threshold. One nuance to verify: the description clarifies that cookies in Mechanize#cookie_jar remain correctly scoped and are NOT leaked - only caller-supplied headers are affected - which further narrows the population of vulnerable deployments to those explicitly injecting their own auth/cookie headers.

An application uses Mechanize with a caller-supplied Authorization or Cookie header to interact with a site; the attacker controls or influences that site's responses (or holds a MITM position) and returns a same-host redirect from https:// to http:// (or to a different port). Mechanize treats it as same-origin and re-sends the sensitive headers over cleartext or to an unintended service, letting the attacker capture the credentials. No public exploit code was identified in the supplied data.