CVE-2026-104006

SpeedyCache <= 1.4.2 - Unauthenticated Sensitive Information Exposure via Insecure Cache Configuration via Cache Write Gate Missing comment_author_* Cookie Check

2026-10-09 17:42
Kuba

Strategic Overview

Status
Patched in 1.4.3
Affected Version
<= 1.4.2
CVSS
3.7Low
Weakness type
CWE-524 · Use of Cache Containing Sensitive Information
CVE
CVE-2026-104006
View all SpeedyCache – Cache, Optimization, Performance vulnerabilities

At a glance

CVE-2026-104006 is a low-severity Use of Cache Containing Sensitive Information vulnerability in the SpeedyCache WordPress plugin, affecting versions <= 1.4.2. It carries a CVSS score of 3.7 (reachable over the network). Exploitation requires no authentication. The issue is fixed in version 1.4.3; sites on affected versions should update now. Disclosed October 2026, reported by Kuba.

Vulnerability Overview

The SpeedyCache – Cache, Optimization, Performance plugin for WordPress is vulnerable to Sensitive Information Exposure in all versions up to, and including, 1.4.2 via the 'comment_author_*, comment_author_email_*' parameter. This makes it possible for unauthenticated attackers to extract the full name and email address of returning commenters pre-filled into comment form input fields and persisted as the site-wide cached page by any unauthenticated attacker requesting the same public URL. The read-side handler in advanced-cache.php correctly skips cached delivery for requests carrying comment_author_* cookies, but this check is absent on the write path, meaning the cache poisoning is invisible to the victim commenter yet fully exploitable by any unauthenticated attacker with no cookies.

Technical Analysis

The vector marks this flaw as remotely reachable over the network, and no privileges on the target site, and no interaction from a victim user.

CWE-524: Use of Cache Containing Sensitive Information

The code uses a cache that contains sensitive information, but the cache can be read by an actor outside of the intended control sphere.

Remediation

Update to version 1.4.3, or a newer patched version

How does WordSec protect against this?

This one needs no account at all, which puts it outside what login hardening can reach; WordSec's login security narrows the account-level paths around it, and the firewall is what inspects the request itself. None of that substitutes for the fix: SpeedyCache 1.4.3 closes this, and updating the plugin is the step that ends it.

  • Login Security
  • Alerts

External References

Related records

Vulnerability data © Defiant, Inc., provided under the Wordfence Intelligence T&C