Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "3.7",
  "pubDate": "2026-10-10T07:16:40.410Z",
  "pubdate": "2026-10-10T07:16:40.410Z",
  "executiveSummary": "The SpeedyCache plugin for WordPress (versions 1.4.2 and below) contains a critical Sensitive Information Exposure vulnerability originating from insecure cache handling.\nThis vulnerability allows unauthenticated attackers to poison the site-wide cache with pages containing the personal information of previous commenters, specifically full names and email addresses.\nThe flaw stems from a discrepancy between the read-side and write-side cache logic in advanced-cache.php.\nWhile the plugin prevents cached delivery for users with specific cookies, it fails to exclude pages containing sensitive user-specific data from being cached during the write path process.\nConsequently, an unauthenticated attacker can force the server to save a cached version of a page populated with a legitimate user's pre-filled data, which is subsequently served to any other visitor accessing the public URL.\nThis represents a significant privacy risk, as attackers can exfiltrate personally identifiable information (PII) without requiring administrative privileges or elevated access, effectively turning the cache mechanism into an unauthorized data distribution channel.",
  "technicalDetails": "The root cause of this vulnerability lies in the implementation logic within advanced-cache.php, which governs the caching behavior of the SpeedyCache plugin. WordPress comment forms often utilize 'comment_author_*' and 'comment_author_email_*' cookies to pre-fill form fields for returning visitors. To prevent these personalized details from being cached and exposed, the plugin implements a check on the read-side handler that intentionally skips cached delivery for any request containing these specific cookies.\nHowever, this security control is absent from the write-side handler. When the cache engine processes a page generation request, it does not verify if the resulting HTML contains sensitive data retrieved from these cookies. Because the write path does not differentiate between anonymous requests and requests carrying user-specific information, it permits the server to store a version of the page containing a commenter's PII into the public, site-wide cache.\nThe attack flow proceeds as follows: First, an unauthenticated attacker identifies a public URL where the WordPress comment form is active. Second, the attacker interacts with or monitors the page while a legitimate user—who has their personal details pre-filled in their browser cookies—visits the same URL. Third, if the server generates a cached version while that user's data is embedded in the form fields, the plugin saves this document to the cache storage.\nOnce the cache is poisoned, the information is persisted and served to any subsequent visitor who requests the page, regardless of whether they have the original cookies or not. The attacker does not need to authenticate to the WordPress site; they only need to trigger a cache refresh or wait for the system to cache a version of the page that includes the pre-filled information. Because the cache delivery logic is decoupled from the user-specific state, the resulting exposure is global. This effectively turns the public-facing cache into an information leak vector, where PII is accessible to any network-exposed user browsing the site. The impact is a total loss of privacy for commenters, as their contact details are exposed to the general public until the cache is cleared or invalidated."
}