CVE-2024-28000: How We Cleaned 30 Infected WordPress Sites in 12 Minutes

In June 2026, a managed hosting provider contacted us after a mass compromise hit one of their cPanel servers. The culprit: CVE-2024-28000, a privilege escalation vulnerability in LiteSpeed Cache — a plugin with over 5 million active installations. Thirty of the 34 WordPress sites on the server were compromised. Imunify360 found 2 PHP backdoor files. CleanShift found everything else.

This is the full story of how we detected, correlated, and cleaned the entire server in 12 minutes — and why legacy scanners left this hosting provider exposed for 3 days.

The Vulnerability: CVE-2024-28000

CVE-2024-28000 is a privilege escalation flaw in LiteSpeed Cache for WordPress. An unauthenticated attacker can exploit the plugin\u0026apos;s REST API to create a new administrator account — no credentials required. Once they have admin access, the attack chain is predictable:

• Step 1: Create a rogue admin account via the REST API endpoint
• Step 2: Log in and modify wp_options to inject redirect scripts and SEO spam
• Step 3: Upload a PHP backdoor to wp-content/uploads/ for persistent access
• Step 4: Install a cron job in the cron option to re-inject the malware on a schedule

Steps 3 and 4 are the insurance policy — even if you delete the PHP file, the cron re-creates it. Even if you delete the cron, the rogue admin account persists. This layered persistence is what makes database-aware scanning essential.

What Imunify360 Found (and Didn\u0026apos;t)

The server was running Imunify360 v8.13.5 with real-time AV scanning enabled. Here\u0026apos;s what it reported:

• Detected: 2 PHP backdoor files in wp-content/uploads/2024/ — standard webshells matching known YARA signatures
• Action taken: Both files quarantined automatically
• Server status: Reported as CLEAN after quarantine

The hosting provider saw the clean status and closed the ticket. But the clients kept complaining — their sites were still redirecting to spam domains, and Google Search Console was flagging SEO spam in their indexed pages.

What CleanShift Found

Three days after the Imunify360 "all clear," the provider installed CleanShift and ran a deep scan:

The results were stark. Across the 34 WordPress sites, CleanShift found:

• 30 sites compromised — not just 2
• 30 rogue admin accounts — one per compromised site, all created within a 4-hour window, all with the same email pattern (*@protonmail.com)
• 27 sites with wp_options injections — modified siteurl on 4 sites, hack_* prefixed options on 19 sites, and hijacked cron schedules on 23 sites
• 14 sites with SEO spam in wp_posts — hidden link injections in post content targeting pharmaceutical and gambling keywords

Cross-Site Correlation: The Force Multiplier

The most powerful aspect of CleanShift\u0026apos;s scan wasn\u0026apos;t just finding malware on one site — it was connecting the dots across all 34 sites on the server.

When CleanShift detected the rogue admin account on the first compromised site, it extracted the Indicators of Compromise (IoCs):

• The rogue admin\u0026apos;s email address pattern
• The user registration timestamp window
• The option name patterns used for injection (hack_*)
• The base64-encoded payload signatures

It then automatically checked every other WordPress database on the server for matching IoCs. This cross-site correlation turned what would have been 34 individual investigations into a single, coordinated detection sweep.

On a shared hosting server, this is critical. When one site falls to a CVE, the attacker almost always pivots to other sites on the same server — especially when they\u0026apos;re all running the same vulnerable plugin. Without cross-site correlation, you\u0026apos;re playing whack-a-mole.

The Cleanup: 12 Minutes, Zero Downtime

With all 30 compromised sites identified and all IoCs catalogued, cleanup was automated:

The CVE-2024-28000 playbook executed the following steps across all 30 sites simultaneously:

• Removed all rogue admin accounts from wp_users and wp_usermeta
• Deleted malicious wp_options entries — hack_* options, injected cron events, and restored siteurl/home to correct values
• Cleaned SEO spam from wp_posts — removed injected hidden links while preserving legitimate post content
• Deactivated LiteSpeed Cache on all sites until the plugin could be updated to the patched version
• Regenerated WordPress security salts in wp-config.php to invalidate all existing sessions
• Reset all admin passwords and notified site owners via email

Total time from scan initiation to full remediation: 12 minutes.

The Manual Alternative: 15+ Hours

For perspective, here\u0026apos;s what manual cleanup of this incident would have looked like:

• Identifying which of the 34 sites were compromised — checking each database individually: ~2 hours
• Manually running SQL queries against each of the 30 compromised databases: ~4 hours
• Cleaning wp_options, wp_users, and wp_posts on each site: ~6 hours
• Resetting credentials, updating plugins, and verifying each site: ~3 hours

That\u0026apos;s 15+ hours of skilled sysadmin time — and that\u0026apos;s assuming you don\u0026apos;t miss anything. One overlooked rogue admin or one undetected cron job means the malware returns within hours.

Lessons for Hosting Providers

This incident crystallized three key takeaways for shared hosting security:

• Database malware is the new normal. Attackers have figured out that hosting providers rely on file-based scanners. Storing payloads in wp_options is now the default strategy, not an edge case. If your security stack can\u0026apos;t read MySQL, you\u0026apos;re flying blind.
• Cross-site correlation is essential for shared hosting. A CVE affecting a popular plugin doesn\u0026apos;t hit one site — it hits every site on the server running that plugin. Detection and cleanup must operate at the server level, not the site level.
• Automated playbooks beat manual remediation. When 30 sites are compromised, the difference between 12 minutes and 15 hours isn\u0026apos;t just operational — it\u0026apos;s reputational. Every hour those sites serve spam, your customers lose SEO rankings and your hosting brand takes damage.

Don\u0026apos;t Wait for the Next Zero-Day

CVE-2024-28000 won\u0026apos;t be the last privilege escalation in a major WordPress plugin. The question isn\u0026apos;t whether it will happen again — it\u0026apos;s whether you\u0026apos;ll detect the database-level compromise when it does.

Install CleanShift on your server today at cleanshift.osg.co.in. Set up automated deep scans and get cross-site correlation out of the box. See what Imunify360 is missing — before your customers do.