Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
mechanize applied no trust boundary to a meta refresh, so credentials set through Mechanize#requestheaders= followed a refresh that pointed at another origin. Details Mechanize::HTTP::Agent#responsefollowmetarefresh fetched the refresh target with no notion of a crossed origin, so @requestheaders 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#requestheaders= were exposed. This requires Mechanize#followmetarefresh = 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…
Recommended action: Upgrade to 2.14.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
mechanize leaked credentials to the redirect target when an HTTP redirect crossed to another host. Credentials set through Mechanize#requestheaders= leaked even when they were Authorization. Details Two defects, both in lib/mechanize/http/agent.rb. 1. Mechanize#requestheaders= bypassed the redirect strip entirely. #requestaddheaders copied @requestheaders onto every request unconditionally, with no host check, including the request issued after a redirect. The strip in #responseredirect mutated only the per-request headers hash and never touched agent state. Because requestheaders= 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. 2. The strip list omitted Proxy-Authorization and Cookie2. Only CREDENTIALHEADERS = ['Authorization'] and COOKIEHEADERS = ['Cookie'] were removed from the per-request headers hash on a cross-host redirect. Cookies held in…
Recommended action: Upgrade to 2.14.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Mechanize (rubygem) < v2.8.5 leaks the Authorization header after a redirect to a different port on the same site. Mitigation Upgrade to Mechanize v2.8.5 or later. Notes See https://curl.se/docs/CVE-2022-27776.html for a similar vulnerability in curl. Cookies are shared with a server at a different port on the same site, per https://datatracker.ietf.org/doc/html/rfc6265#section-8.5 which states in part: Cookies do not provide isolation by port. If a cookie is readable by a service running on one port, the cookie is also readable by a service running on another port of the same server. If a cookie is writable by a service on one port, the cookie is also writable by a service running on another port of the same server. For this reason, servers SHOULD NOT both run mutually distrusting services on different ports of the same host and use cookies to store security- sensitive information.
Recommended action: Upgrade to 2.8.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
This security advisory has been created for public disclosure of a Command Injection vulnerability that was responsibly reported by @kyoshidajp (Katsuhiko YOSHIDA). Impact Mechanize = v2.0, < v2.7.7 allows for OS commands to be injected using several classes' methods which implicitly use Ruby's Kernel.open method. Exploitation is possible only if untrusted input is used as a local filename and passed to any of these calls: - Mechanize::CookieJar#load: since v2.0 (see 208e3ed) - Mechanize::CookieJar#saveas: since v2.0 (see 5b776a4) - Mechanize#download: since v2.2 (see dc91667) - Mechanize::Download#save and #save! since v2.1 (see 98b2f51, bd62ff0) - Mechanize::File#save and #saveas: since v2.1 (see 2bf7519) - Mechanize::FileResponse#readbody: since v2.0 (see 01039f5) Patches These vulnerabilities are patched in Mechanize v2.7.7. Workarounds No workarounds are available. We recommend upgrading to v2.7.7 or later. References See…
Recommended action: Upgrade to 2.7.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.