WP Fastest Cache CVE-2026-74916

The attack requires that the target WordPress site runs WP Fastest Cache at a version prior to 1.5.1 with page caching enabled (the plugin's core feature, enabled by default). No authentication is required; the attack is performed by an unauthenticated remote attacker. The practical impact depends on whether any WordPress theme or plugin on the target site renders tracking query parameter values into page output - if the parameters are silently discarded by all installed code, the cached page is functionally identical to the clean-URL version and no meaningful poisoning occurs. Exploitation is therefore most effective against sites using A/B testing plugins, personalization features, or any code path that reflects UTM/tracking parameters into HTML. The CVSS vector PR:N and AC:L confirm no privilege escalation or complex preconditions are required beyond basic network access.

The CVSS 3.1 score of 6.5 with AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N accurately reflects the low-effort, network-accessible nature of exploitation with no authentication barrier. The real-world impact is content-level cache poisoning: an attacker who can influence how a page renders for a given query string can inject that render into the cache for all visitors. The integrity dimension is the primary concern - malicious or misleading content served site-wide from a trusted domain. The publicly available POC from WPScan lowers the effective skill bar significantly; any operator running an unpatched instance of WP Fastest Cache should treat this as elevated operational priority. EPSS data was not provided, and the absence of a CISA KEV listing means active mass exploitation is not confirmed, but with a public exploit and a very large WordPress install base, opportunistic scanning is plausible. The confidentiality impact (C:L) is less clear from the description - it is possible attacker-specific session fragments could be cached and exposed, but this depends on site configuration and whether tracking parameters interact with authenticated content; this should be verified per deployment.

An attacker sends a crafted GET request to a target WordPress page appending tracking query parameters (e.g., ?utm_source=attack&utm_content=<injected-value>) that cause the page to render with attacker-influenced content - for example via a plugin or theme that reflects query parameters into page output. WP Fastest Cache stores this poisoned HTML under the clean canonical URL cache key. Every subsequent visitor requesting the clean URL is silently served the attacker's cached render from the plugin's page cache. A public POC is available from WPScan confirming this flow.