Mechanize EUVD-2026-95321

Exploitation requires BOTH of the following: (1) the application passes sensitive headers - Authorization/bearer tokens, Proxy-Authorization, Cookie, or Cookie2 session cookies - through Mechanize#request_headers= or the per-request headers argument (credentials managed via Mechanize#cookie_jar or Mechanize::HTTP::AuthStore are explicitly NOT affected); and (2) the attacker controls, compromises, or can coerce the redirect target so a response issues a cross-origin HTTP redirect (or, per the companion advisories, a cross-origin meta refresh). Limiting factors that reduce real-world risk: the flaw affects only Mechanize versions prior to 2.14.1; it does not trigger for same-origin redirects; it is inert unless the application actually sets credentials via these specific header-setting APIs; and it requires the attacker to influence a redirect destination rather than merely reach the service.

This is a genuine but conditional information-disclosure flaw (CWE-200) rather than a mass-exploitation priority. The input CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:N, score 6.8) is internally consistent with the description: no attacker privileges are needed (PR:N), but exploitation hinges on specific preconditions - the victim application must supply secrets through Mechanize#request_headers= or the per-request headers argument, AND the attacker must control a redirect destination on a different origin - which correctly drives AC:H, and the leak of credentials to a foreign host justifies the scope change (S:C) and C:H/I:N/A:N. No EPSS score, KEV entry, or SSVC decision data was provided in the input; the vulnerability is NOT listed in CISA KEV and no public exploit code was supplied, so exploitation status is 'no public exploit identified at time of analysis.' There is no signal conflict: a network vector paired with high complexity and a config-dependent trigger points to targeted, opportunistic abuse (e.g., a malicious or compromised site that Mechanize is pointed at) rather than internet-wide scanning. Net priority: moderate - patch promptly in Ruby applications that drive Mechanize against untrusted or redirecting endpoints while passing bearer tokens or cookies via request headers, but it is not an emergency for deployments that rely on Mechanize's cookie_jar or AuthStore, which the advisory explicitly states are unaffected.

A developer uses Mechanize (pre-2.14.1) to call an API, attaching a bearer token via Mechanize#request_headers= or the per-request headers argument. The target host (attacker-controlled, compromised, or coerced) issues an HTTP redirect - or a meta refresh - to an attacker origin, and Mechanize re-applies the credential/cookie headers to that cross-origin request, handing the attacker the Authorization bearer token or session cookie. No public exploit code was supplied with this analysis, but the mechanism is fully documented in the vendor advisory and fix diff (PR #676).