CVE-2024-28000: Critical Unauthenticated Privilege Escalation in LiteSpeed Cache (5 Million+ Sites)

In August 2024, security researchers disclosed one of the most serious WordPress plugin vulnerabilities of the year. CVE-2024-28000 is a critical, unauthenticated privilege escalation flaw in LiteSpeed Cache — a caching and performance plugin installed on more than 5,000,000 WordPress sites. Because it can be exploited by an attacker with no account and no password, and because it leads directly to a full administrator takeover, this is exactly the kind of bug that gets weaponized within days of disclosure. If you run LiteSpeed Cache and have not updated since mid-2024, your site may already be at risk.

This post explains what the vulnerability is, how it works in plain language, what it could do to a real site, and the exact steps to confirm whether you are exposed and lock things down.

CVE details at a glance

• CVE ID: CVE-2024-28000
• Plugin: LiteSpeed Cache (plugin slug: litespeed-cache)
• Vulnerability type: Unauthenticated privilege escalation (user ID spoofing)
• CVSS score: 9.8 (Critical) — vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
• Affected versions: All versions up to and including 6.3.0.1
• Patched version: 6.4 (LiteSpeed shipped 6.4.1 shortly after; install the latest available release)
• Active installs: 5,000,000+
• Reported by: John Blackbourn, via the Wordfence Threat Intelligence team

How the vulnerability works

LiteSpeed Cache includes a “crawler” feature that pre-builds and caches pages as if a logged-in user were viewing them. To do this, the plugin can temporarily simulate the identity of a real user account — a feature controlled by its Crawler Simulation Settings. The flaw is in how that role simulation was secured.

When the crawler runs, the plugin generates a secret hash value and stores it. On each request, LiteSpeed Cache checks two browser cookies: litespeed_hash and litespeed_role. If the litespeed_hash cookie matches the stored hash, the plugin trusts the litespeed_role cookie and calls WordPress’s wp_set_current_user() to treat the visitor as whatever user ID that cookie contains — including user ID 1, the original administrator.

In short: anyone who knows the secret hash can tell the site “treat me as the administrator,” and the site will believe them. No login required. The problem is that the secret hash was far too weak to keep secret:

• The hash was only six characters long and limited to roughly one million possible values, which is small enough to brute-force.
• The hash never expired, so an attacker could keep guessing slowly over time without it changing.
• The plugin used a loose comparison when checking the hash, making matching easier.
• If the site had debug logging enabled, the correct hash could simply leak into the debug log, removing the need to guess at all.

Once an attacker is being treated as an administrator, they can call the WordPress REST API user-creation endpoint (/wp-json/wp/v2/users) to register a brand-new administrator account that they fully control. From there, the site is theirs.

One important caveat: on some server configurations the crawler is disabled by default. On those sites the hash is never generated and the issue is not exploitable. But you should not rely on that as your defense — the only reliable protection is updating.

Real-world impact

A successful exploit gives an attacker administrator-level control of your WordPress site. That is essentially game over. With an admin account, an attacker can:

• Install malicious plugins or themes to establish a permanent backdoor that survives password changes.
• Inject spam, SEO link farms, or malicious redirects that send your visitors to scam or malware sites.
• Steal customer data, order records, or personal information stored in the database.
• Deface the site, lock out the legitimate owner, or use the server to attack other sites.
• Plant cryptominers or skimmers, especially damaging on WooCommerce and other e-commerce stores.

Because the flaw is unauthenticated and affects millions of sites, it is the kind of vulnerability attackers automate and spray across the entire internet. Researchers warned at disclosure that active exploitation was a near certainty, and similar plugin flaws have historically been mass-exploited within days.

How to check if you are affected

• Log in to your WordPress dashboard and go to Plugins > Installed Plugins.
• Look for LiteSpeed Cache and note its version number.
• If the version is 6.3.0.1 or lower, your site is vulnerable and needs to be updated immediately.
• If you cannot access the dashboard, you can check the version in the file wp-content/plugins/litespeed-cache/litespeed-cache.php via FTP or your hosting file manager.

While you are there, look for warning signs of a prior compromise: administrator accounts you do not recognize, unexpected new plugins, or unfamiliar entries in your user list. CVE-2024-28000 is most often exploited by creating a rogue admin user, so an unknown administrator is the clearest red flag.

How to fix it

The fix is straightforward: update LiteSpeed Cache to version 6.4 or later (use the newest available release). The patched versions properly restrict the role simulation feature so it can no longer be abused.

• In your dashboard, go to Plugins > Installed Plugins, find LiteSpeed Cache, and click Update Now. Then confirm the version reads 6.4 or higher.
• Consider enabling automatic updates for LiteSpeed Cache so future security patches apply without delay.
• If your site was running a vulnerable version while exposed, treat it as potentially compromised: review all administrator accounts and delete any you did not create, force a password reset for all users, rotate your security keys (salts) in wp-config.php, and scan for unfamiliar plugins or modified files.
• Turn off LiteSpeed Cache debug logging in production, since debug logs were one way the secret hash could leak.
• Run a malware scan with a reputable security plugin or your host’s scanner to catch any backdoors left behind.

Takeaway

CVE-2024-28000 is a textbook reminder that the most dangerous vulnerabilities are not always exotic — this one came down to a secret value that was too short, never expired, and could leak into a log. The lesson for site owners is the same as always: keep plugins updated promptly, enable automatic updates for trusted plugins where you can, disable debug logging in production, and routinely audit your administrator accounts. A caching plugin exists to make your site faster, but like any code with deep access to WordPress, it needs to be kept current. Patch quickly, watch your user list, and treat unauthenticated, critical-severity advisories as the emergencies they are.