Package Instance

Mechanize ruby gem Command Injection vulnerability
## 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#save_as: 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 #save_as: since v2.1 (see 2bf7519)
* Mechanize::FileResponse#read_body: 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 https://docs.rubocop.org/rubocop/cops_security.html#securityopen for background
on why `Kernel.open` should not be used with untrusted input.

Authorization header leak on port redirect in mechanize
**Summary**

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](CVE-2022-27776) 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.