WP Fastest Cache CVE-2026-74932

The target WordPress site must have WP Fastest Cache plugin version prior to 1.5.1 installed and active, with page caching enabled - the attack is ineffective if caching is disabled. The attacker must be able to send an HTTP request with an arbitrary Host header to the WordPress server, which is possible from any internet-accessible host unless the web server or an upstream WAF performs Host header validation before routing the request. The attacker must also operate a server at the hostname specified in the crafted Host header and serve JavaScript content from it. Exploitation is limited to pages not yet present in cache; an existing legitimate cache entry for the target page prevents poisoning until that entry expires or is manually purged. Victim users must browse to the poisoned cached page - no additional interaction is required beyond loading the URL. Per the CVSS vector (PR:N), no authentication is required on the attacker side. Exploitation is not limited to specific platforms, regions, or non-default configurations beyond plugin version and active caching.

The CVSS 3.1 score of 7.5 (AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H) accurately captures the unauthenticated, network-accessible nature of the attack, but the S:U (Unchanged scope) designation is arguably conservative - cache poisoning inherently spreads impact to subsequent visitors beyond the directly targeted system, which aligns more closely with S:C semantics and is reflected in the assessed vector below. AC:H reflects the real-world complexity: the attacker must win a race to poison the cache before the page is legitimately populated and must control a responsive server at the spoofed hostname. EPSS data is absent from this dataset, limiting probabilistic exploitation forecasting. No CISA KEV listing is present and no public proof-of-concept code has been identified at time of analysis. Despite these limiting signals, the potential for a single unauthenticated HTTP request to persistently compromise every subsequent visitor to a high-traffic page makes this a meaningful priority: blast radius scales directly with site traffic, the poisoned cache entry leaves no distinguishable trace in most application logs, and the attack requires no credentials. Organizations running WP Fastest Cache prior to 1.5.1 on public-facing WordPress sites should treat patching as urgent.

An attacker identifies a WordPress site with WP Fastest Cache installed and determines that a high-traffic page is not yet cached. They send an HTTP GET request for that page with the Host header set to their own domain (e.g., evil.com) and serve malicious JavaScript at the expected asset path on that domain. WP Fastest Cache builds and stores the HTML with script tags pointing to evil.com. Every subsequent visitor receives the poisoned cached page and unknowingly executes the attacker's JavaScript, enabling mass session token exfiltration or credential harvesting. No public proof-of-concept code has been identified at time of analysis.