CVE-2026-8612: WWW::Mechanize::Cached RCE Vulnerability

CVE-2026-8612 Overview

CVE-2026-8612 affects WWW::Mechanize::Cached versions before 2.00 for Perl. The module deserializes cached HTTP responses from a world-writable on-disk cache, allowing local response forgery and potential code execution. Without an explicit cache backend, the module constructs a default Cache::FileCache under /tmp/FileCache and inherits the documented directory_umask of 000. The result is a cache root and subdirectories created with mode 0777 and no sticky bit. Local attackers can substitute frozen HTTP::Response blobs that flow through Storable::thaw on the next cache hit. The flaw is categorized as insecure deserialization [CWE-502].

Critical Impact

A local attacker with write access to /tmp/FileCache can forge cached HTTP responses and trigger arbitrary code execution in any victim process that loads classes with side-effectful STORABLE_thaw, DESTROY, or overload hooks.

Affected Products

• WWW::Mechanize::Cached Perl module versions prior to 2.00
• Perl applications using the default Cache::FileCache backend under /tmp/FileCache
• Downstream tools and scripts depending on WWW::Mechanize::Cached without an explicit cache backend

Discovery Timeline

• 2026-05-15 - CVE-2026-8612 published to NVD
• 2026-05-18 - Last updated in NVD database

Technical Details for CVE-2026-8612

Vulnerability Analysis

The vulnerability stems from insecure deserialization of attacker-controlled cache files. WWW::Mechanize::Cached stores HTTP response objects on disk using Storable serialization. On a cache hit, the module reads the serialized blob and passes it directly to Storable::thaw to reconstruct the original HTTP::Response object.

Storable::thaw is well-known as an unsafe deserializer when the input is not trusted. The frozen stream can reference any Perl class available in the victim process. Classes that define STORABLE_thaw, DESTROY, or overload hooks execute their own code as part of object reconstruction or garbage collection. An attacker who controls the serialized bytes therefore controls which classes are instantiated and which hook routines run.

Root Cause

The root cause is twofold. First, the module uses Storable::thaw on untrusted on-disk data without integrity validation such as an HMAC or signature. Second, the default cache directory is created with permissive permissions. Cache::FileCache documents a directory_umask of 000, and WWW::Mechanize::Cached does not override it. As a result, the cache root /tmp/FileCache and its subdirectories are created with mode 0777 and no sticky bit. Cache entries are named by sha1_hex of the request URL, which is predictable to any local user.

Attack Vector

A local attacker with shell access to the same host enumerates predictable cache filenames by computing sha1_hex of URLs the victim is expected to fetch. The attacker then writes a malicious frozen HTTP::Response blob into the corresponding cache file inside the world-writable /tmp/FileCache tree. When the victim process next calls get() for that URL, WWW::Mechanize::Cached reads the attacker file and passes its contents to Storable::thaw. Deserialization triggers any side-effectful hooks in classes already loaded by the victim process, escalating local file write into arbitrary code execution under the victim's user context. See the OpenWall OSS-Security Discussion for additional technical detail.

Detection Methods for CVE-2026-8612

Indicators of Compromise

• Existence of /tmp/FileCache with directory mode 0777 and no sticky bit
• Files inside /tmp/FileCache owned by a user different from the process invoking WWW::Mechanize::Cached
• Unexpected child processes or outbound connections spawned by Perl scripts that call WWW::Mechanize::Cached->get()
• Cache files with recent mtime changes that do not correlate with the victim user's HTTP activity

Detection Strategies

• Audit installed CPAN distributions for WWW-Mechanize-Cached versions below 2.00
• Inspect Perl code for WWW::Mechanize::Cached->new() calls that omit an explicit cache backend
• Alert on writes to /tmp/FileCache originating from accounts other than the legitimate consumer of the cache
• Flag any invocation of Storable::thaw against files in world-writable directories

Monitoring Recommendations

• Enable file integrity monitoring on /tmp/FileCache and similar shared cache locations
• Collect Linux audit logs for open and write events on the cache tree, correlated by UID
• Track process telemetry for Perl interpreters that spawn shells or network connections after cache reads

How to Mitigate CVE-2026-8612

Immediate Actions Required

• Upgrade WWW::Mechanize::Cached to version 2.00 or later from CPAN
• Remove any existing /tmp/FileCache directory and recreate the cache under a user-private path with mode 0700
• Audit all Perl code paths that instantiate WWW::Mechanize::Cached and supply an explicit cache backend with a restrictive directory_umask
• Treat any historical cache contents as untrusted and purge them before restarting affected services

Patch Information

The fix landed in WWW-Mechanize-Cached 2.00. Review the GitHub Patch for Commit and GitHub Pull Request #36 for the source-level changes. Release notes are available at the MetaCPAN Changes for Release.

Workarounds

• Pass an explicit cache object to the constructor with cache_root set to a user-owned directory and directory_umask set to 077
• Disable disk caching entirely for untrusted multi-user hosts and rely on in-memory caching
• Apply filesystem ACLs that restrict write access to the cache directory to a single service account
• Run Perl jobs that use WWW::Mechanize::Cached inside dedicated containers or chroots that do not share /tmp with other users

# Configuration example: instantiate with a private cache directory
perl -e '
  use WWW::Mechanize::Cached;
  use Cache::FileCache;
  my $cache = Cache::FileCache->new({
      namespace       => "mech",
      cache_root      => "$ENV{HOME}/.cache/mech",
      directory_umask => 077,
  });
  my $mech = WWW::Mechanize::Cached->new( cache => $cache );
'