An unauthenticated stored cross site scripting vulnerability was disclosed in LiteSpeed Cache, affecting versions up to and including 7.8.1. The plugin is installed on more than seven million WordPress sites. If you run WordPress and care about speed, there is a meaningful chance this is on your site whether or not you remember choosing it.
Two words in that description carry the weight. Unauthenticated means no account is needed. Stored means the payload persists on your site and runs for other visitors later, rather than requiring someone to click a crafted link.
Why stored is worse than reflected
Most cross site scripting flaws are reflected. An attacker crafts a URL containing a payload, persuades someone to click it, and the script runs in that person's browser for that one request. It requires social engineering and it affects one victim at a time.
Stored cross site scripting removes both limitations. The payload is saved into your database and served to everyone who loads the affected page afterwards. No one needs to click anything unusual. They visit your site normally and receive the attacker's script alongside your content.
The delivery path here is comment content, which is the part that should concern you. Comments are, by design, a place where anonymous strangers submit text that later appears on your pages. That is the entire purpose of the feature.
What an attacker actually gets
Cross site scripting is often dismissed as a low severity annoyance about popup boxes. What it really provides is arbitrary JavaScript execution in your visitors' browsers, in your site's security context.
The realistic uses are unglamorous and effective. Session token theft, which yields an authenticated session without ever knowing a password. Silent redirection of visitors to a phishing or malware page. Injection of spam links that damage your search rankings and are difficult to trace. Keylogging on forms, including checkout and login forms.
If an administrator views an affected page while logged in, the script runs with their session. From there an attacker can create a new administrator account, and at that point the vulnerability is no longer the problem. Persistent unauthorised access is.
The damage we see most often is not dramatic. It is a script quietly added to every page that redirects a fraction of mobile visitors elsewhere, which is invisible to the owner on a desktop and has usually been running for weeks before anybody reports it.
Check your version, then check when it last updated
Open Plugins and find LiteSpeed Cache. If the version is 7.8.1 or lower, update it. That is the immediate action and it takes a minute.
The more useful question comes after. Look at when the plugin last received an update on your site, not when the developer last released one. Sites where updates are applied manually, or where auto updates are disabled for stability reasons, routinely run plugins that are one or two years behind while the dashboard quietly shows an update badge nobody looks at.
Then check whether you are actually using it. A surprising number of sites run a caching plugin installed during a long forgotten speed optimisation, on hosting that now provides caching at the server level. The plugin sits there doing very little, receiving no attention, and presenting an attack surface for no benefit. If nothing depends on it, removing it is better than updating it.
When we audit a site after a disclosure like this, the version number is rarely the surprise. What surprises people is finding automatic updates were switched off two years ago by somebody solving a different problem, and nobody has looked since. That is worth checking the same way we described in why an auto update broke a live site.
Comments are the part to reconsider
This vulnerability is delivered through comment content, which is a good moment to ask whether comments are earning their place on your site.
For most business sites they are not. The comment section on a company blog typically contains spam, a handful of genuine questions that would have been better as emails, and nothing else. It exists because it was on by default in 2011. Meanwhile it is an anonymous write path into your database, and it has been the delivery mechanism for a long series of vulnerabilities across many plugins.
If comments generate real discussion, keep them and moderate them. If they generate spam you clear out quarterly, turning them off closes an entire category of risk at no cost. We covered the adjacent version of this problem in contact form spam without real leads, and the reasoning is the same: an input nobody wants is still an input.
Why caching plugins keep appearing in these disclosures
It is not that caching developers write worse code. It is where a caching plugin sits in the request lifecycle.
A caching plugin runs early, before most of WordPress has loaded, because that is the entire point: serving a stored response without executing the full stack. It writes files, rewrites output, and makes decisions about which requests are equivalent. Code that runs before the platform's own protections are fully initialised has fewer safety nets underneath it.
Cache key handling adds a second class of problem. Deciding that two requests should receive the same stored response is a judgement, and getting it wrong can serve one visitor's content to another. That failure mode does not exist at all in a plugin that adds a contact form.
The practical conclusion is not to avoid caching plugins, which would be perverse. It is that plugins operating at privileged points deserve faster patching than the rest, and are worth reviewing before installing a second one that does the same job. We covered the wider selection question in auditing what you have installed.
Frequently Asked Questions
How do I know if my site was already exploited?
Look for content you did not create. Check recent comments for markup that should not be there, view the page source of posts with comments and search for unexpected script tags, and review the user list for administrator accounts you do not recognise. Also check whether visitors have reported redirects, since that symptom reaches customers before it reaches you.
I updated the plugin. Am I safe now?
You are protected against further exploitation of this flaw. You are not protected against a payload injected before you updated, because stored means it is already in your database. Updating closes the door; it does not clean the room. Review comment content on affected pages as well.
Does disabling comments fix it?
It removes this specific delivery path, which is worth doing if comments serve no purpose on your site. It does not patch the plugin, and it does not help if a payload was already stored. Update regardless, then decide about comments on their own merits.
Should I switch away from LiteSpeed Cache?
Not because of this. Every large plugin discloses vulnerabilities, and a responsibly disclosed and patched flaw is evidence the process is working. What matters is whether the developer patches quickly and whether you apply patches quickly. Switching plugins after every disclosure means permanently migrating between products that all have the same characteristic.
Why do vulnerabilities cluster in caching and security plugins?
Because of what they do. Caching plugins intercept requests, rewrite output, and write files. Security plugins inspect input and manage access. Both operate at privileged points in the request lifecycle, and code that runs early on untrusted input has more ways to be wrong than a plugin that adds a contact form.
Is a firewall or security plugin enough?
It helps and it is not sufficient. A web application firewall can block known payload patterns, which buys time on some flaws, but attackers adapt payloads and firewalls cannot understand the logic of every plugin. Treat it as a delay mechanism that gives you time to patch, not as a replacement for patching.
How fast do I actually need to update after a disclosure?
For an unauthenticated flaw in a plugin with millions of installs, the same day. Automated scanning begins almost immediately after disclosure because the target list is easy to build and the payoff is high. Anything slower than a few days is relying on not being noticed.
Talk to our team if you are responsible for a set of WordPress sites and are not confident every one of them is patched.