SURIQ
The word doing the heavy lifting in this advisory is "unauthenticated," and it is worth slowing down on. CVE-2026-18978 is a stored cross-site scripting flaw in LiteSpeed Cache, one of the most installed performance plugins on WordPress and active on millions of sites. Wordfence, which assigned the CVE, rates it 7.2. A comment can be crafted to carry a script that runs in the browser of anyone who later loads the page holding it. Whether a given site can be hit at all comes down to two comment settings, and most coverage will skip past them. Here is who is actually exposed, and what to do about it.
Which sites can actually be attacked
Two conditions have to be true at the same time. The site must let people who already have one approved comment post new comments without moderation, and it must have the require-name-and-email option switched off so anonymous comments are allowed. Miss either and the attack path closes.
The attacker first earns a single approved comment, the low bar WordPress uses to start trusting a returning commenter. After that, their comments publish straight to the page with no moderator in the loop, and with require_name_email disabled there is no identity friction left. Neither setting is the WordPress default, which pulls the exposed population well below the raw install count. It does not pull it to zero. Comment-heavy sites that loosened moderation to cut friction, the forums, the busy blogs, the membership communities, are exactly the ones that match.
How the sanitizer gets fooled
WordPress does not trust raw comment HTML. It runs comments through wp_kses, the allowlist filter that strips any tag or attribute it does not recognize. The flaw is a blind spot in that filter. A comment assembled from decimal numeric character references, the <-style codes a browser decodes back into real characters, and placed inside an allowed element such as <code>, slips past wp_kses because the filter does not read an attribute-like run of text inside element content as a real attribute. The filter sees inert text. The browser later decodes the same bytes into live markup, that markup reaches a LiteSpeed Cache code path that writes it into the page without escaping, and the script executes. The mechanism is the part a defender needs; the working payload is not, so it stays out of this post.
This is not a new class of bug. Numeric-entity tricks and allowlist confusion have defeated wp_kses before, and LiteSpeed Cache has carried several cross-site scripting issues across its history. An allowlist filter is only as good as its model of how the browser will later read the same bytes, and that model keeps having gaps. We have written up the same unauthenticated-comment-to-admin shape in the Bookly booking plugin, a full account takeover in Branda, and the way unpatched plugins get turned into webshells once one of them cracks.
The versions that matter, and whether anyone is exploiting it
Here is the state a defender needs in one place. Every LiteSpeed Cache release up to and including 7.8.1 is affected. The plugin's current version, 7.9, shipped on August 5 and sits past that range, so a site running 7.9 is not exposed and updating to it removes the flaw. At the time of writing there is no public proof-of-concept exploit, no report of exploitation in the wild, and the CVE is not on the CISA Known Exploited Vulnerabilities list. Wordfence marks the scope as changed, the tell that the injected script can act beyond the plugin's own context against the surrounding page.
Because the payload runs for whoever views the comment, the victim is not always a low-privilege reader. A moderator or an administrator who opens the post to read or approve comments runs it too, and that is the version of this bug worth taking seriously: a passing commenter reaching an admin session by way of a page the admin was always going to open.
Update to 7.9, then read your recent comments
Updating is the first move and the one that counts. Get every site off 7.8.1 or earlier and onto 7.9. If you rely on managed or automatic updates, confirm they actually applied rather than assume they did. Where you cannot update right away, close the path instead: turn the require-name-and-email option back on, or tighten moderation so previously approved commenters do not post unattended. Either one breaks the precondition.
Patching stops new injections. It does not remove a payload that was already stored while the site was exposed. If a site ran an affected version with loose comment settings, review recent approved and pending comments for encoded markup, especially content wrapped in <code> that decodes into tags, and delete anything that does not belong. If you find planted script, treat it as a possible session compromise for any administrator who viewed that page and rotate administrator credentials. For sites you monitor centrally, unexpected script-like content in comment records and a burst of comments from a single returning author are both worth an alert while the update rolls out.