SURIQ
The problem in WP Fastest Cache is not in the pages it serves. It is in how it decides which cached page to hand back. CVE-2026-74916 is an unauthenticated cache poisoning flaw in the WordPress caching plugin, which runs on more than a million sites. An attacker who has never logged in can get a page rendered under their own request stored in the cache, then served unchanged to every visitor who follows. The fix is version 1.5.1. Versions 0.8.7.7 through 1.5.0 are affected.
WPScan, which assigned the identifier, rates it 6.5 on the CVSS severity scale, a medium. There is no public exploit yet. The researcher who reported it, Amity Gilmour, agreed to hold the proof-of-concept until September 9, 2026, to give sites time to update. That deadline is the useful part of this story. You have a short, defined window before the working recipe is public.
How a caching bug becomes a cross-site scripting bug
A page cache exists to skip work. The first visitor makes WordPress build a page, the plugin stores the result, and it serves that stored copy to everyone after, until the entry expires. The question that decides everything is what counts as the same page. That is the cache key.
Marketing and analytics tools bolt extra parameters onto URLs so they can track where a click came from. WPScan's advisory does not publish the exact list, but these are the familiar campaign tags, the kind that start with utm_, and the click identifiers ad networks append. In the affected versions, WP Fastest Cache cached pages requested with those parameters but left the parameters out of the cache key. A request to a clean URL and a request to the same URL carrying a tracking parameter resolved to one cache entry.
That gap is the whole vulnerability. If any of those unkeyed parameters gets reflected back into the page HTML, an attacker can request the clean URL with a value they control, have that response cached under the clean URL's key, and turn it into stored cross-site scripting. The injected script is then served from cache to every later visitor, with no further action from the attacker. The classification WPScan used, CWE-349 (acceptance of extraneous untrusted data with trusted data), names it precisely: untrusted input rode into a trusted, shared cache entry.
The dates matter. WPScan published its advisory on August 26, 2026. The CVE record went public on September 1. The proof-of-concept is scheduled for September 9. Between now and then, the fix exists and the exploit does not, which is the best position to patch from.
Why a medium score understates the reach
A 6.5 reads as get to it eventually. Two things push this one up the list. It needs no authentication and no user interaction, so anyone on the internet can attempt it against an exposed site. And the payoff is not one victim. A poisoned cache entry serves to every visitor who requests that URL until the entry expires. On a base of more than a million installs, many of them public marketing pages that expect tracking parameters, the practical reach is wider than the number suggests. We made a similar point about a caching flaw in Directus that could serve one visitor's private data to the next. When the cache is the shared surface, one mistake reaches everyone downstream.
Update to 1.5.1, then purge the cache
Updating to 1.5.1 is step one, and on most sites the auto-updater has likely done it already. Confirm it: in the plugin list, WP Fastest Cache should read 1.5.1 or later. If you manage sites for other people, check each one rather than assuming.
Step two is the part the version bump does not cover. The patch changes how new requests are keyed, so fresh poisoning stops. It does not evict a page an attacker may have already cached under a clean URL. If a site ran an affected version while publicly reachable, purge the full page cache after updating so any entry created before the fix is rebuilt from a clean request. This is precautionary. Most sites will not have been targeted, but a purge costs a rebuild and closes the question.
If you cannot update at once, the interim move is to purge the cache and shorten its lifetime so any poisoned entry is short-lived, and to check whether your pages reflect raw query parameters into their HTML at all. That reflection is what turns the keying gap into script execution.
Would you even know?
Cache poisoning is quiet by design. The attacker's request looks ordinary, and the damage shows up in what everyone else is served, not in your own admin session, which may still load a clean page. There is no login event to alert on. What you can watch for is unexpected script or markup in cached HTML, spikes in requests to your own URLs carrying odd query strings, and reports from visitors of behavior you cannot reproduce. This detection blindness is the recurring theme in plugin-level web flaws. We saw it with an unauthenticated stored cross-site scripting bug in the Bookly booking plugin, and with how fast a fixed WordPress flaw can return to active exploitation, as with the Branda plugin account takeover.
The pattern worth remembering
Every cache is a bet that two requests are equivalent. Web cache poisoning is what happens when that bet is wrong, when something the attacker controls is treated as part of the trusted, shared response but left out of the key that decides reuse. Tracking parameters are easy to overlook because site owners add them on purpose. The lesson is not specific to one plugin. Any layer that caches, a plugin, a reverse proxy, a content delivery network, has to key on everything that can change the response. Patch WP Fastest Cache now, clear the cache once, and treat September 9 as the date the grace period ends.