Security Advisories (1)
CVE-2026-8612 (2026-05-15)

WWW::Mechanize::Cached versions before 2.00 for Perl deserialize cached HTTP responses from a world-writable on-disk cache, enabling local response forgery and code execution. With no explicit cache backend, WWW::Mechanize::Cached constructs a default Cache::FileCache under /tmp/FileCache without overriding the backend's documented directory_umask of 000, so the cache root and its subdirectories are created mode 0777 with no sticky bit. Cache entries are named by sha1_hex of the request and read back through Storable::thaw on the next cache hit. A local attacker with write access to the cache tree can replace a victim's cache entry for a known URL with an arbitrary frozen HTTP::Response blob, causing the victim's next get() of that URL to return attacker controlled response bytes. Because the bytes are passed to Storable::thaw, a victim process that has loaded any class with a side-effectful STORABLE_thaw, DESTROY, or overload hook can be escalated to arbitrary code execution.

Changes for version 1.28 - 2004-03-13

  • THINGS THAT WILL BREAK YOUR CODE
    • The C<cache> parm to the constructor is no longer a set of parms to specify how the cache will be initialized. It must now be a fully-initialized cache object, probably in the Cache::Cache hierarchy.
    • Existing caches will not work, because I changed the directory that they get written to. It used to go into /tmp/FileCache/WWW::Mechanize::Cached, but now will go into /tmp/FileCache/www-mechanize-cached. This is so the Windows folks can use the module, too.
      • However, if you want to create your own cache object that writes to /tmp/FileCache/WWW::Mechanize::Cached, for compatibility, you can create it and pass it in.
  • ENHANCEMENTS
    • You can now specify your own Cache::Cache object to pass into the constructor.

Modules

Cache response to be polite UNAUTHORIZED