LiteSpeed cPanel plugin: two takeover bugs, fully fixed only in v2.4.8+

Top/Articles/LiteSpeed cPanel plugin: two takeover bugs, fully fixed only in v2.4.8+

NewsPublished May 27, 2026Last updated July 24, 2026

Table of contents

Key takeaways

CVE-2026-48172, a CVSS 10 privilege escalation flaw in the LiteSpeed User-End cPanel plugin, is being actively exploited in 2026. Any cPanel user (including a compromised tenant on shared hosting) can run arbitrary scripts as root. CISA added it to the Known Exploited Vulnerabilities catalog. Mirai botnet variants and a ransomware strain are reportedly being dropped via the bug. Patch to plugin v2.4.7 or WHM plugin v5.3.1.0 immediately.

Two root-takeover bugs in this plugin. Fully closed only at v2.4.8 or later

LiteSpeed's User-End cPanel Plugin, deployed across a large share of shared hosting providers, picked up two separate server-takeover vulnerabilities in 2026: CVE-2026-48172 (maximum CVSS 4.0 score of 10.0) and, later, CVE-2026-54420 (CVSS 8.5). Both were exploited in the wild, and CISA added both to its Known Exploited Vulnerabilities (KEV) catalog. To have both closed, the plugin must be on v2.4.8 or later (with WHM Plugin v5.3.2.1 or later). The intermediate v2.4.7 only fixes the first bug and still leaves the second one (CVE-2026-54420) open, so stopping at v2.4.7 is not enough.

What these bugs allow is straightforward and severe. Any single cPanel user account on a shared hosting box — including an attacker's own paid tenancy or a customer account compromised through password reuse — can escalate to root. From there, every other site, mailbox, and database on the same physical server is reachable.

Who needs to act: hosting providers and VPS admins running cPanel + LiteSpeed whose plugin is still on v2.4.7 or earlier. Both bugs were seen being exploited in the wild at disclosure; for the first, The Hacker News reported Mirai botnet variants repurposed to run on Linux web hosts. This article walks through what each bug breaks, which version is safe, and how to check whether a box has already been hit. (Status as of 2026-07-23.)

A $5 hosting plan that lets you hold every neighbor on the box hostage

A CVSS-10 root takeover on shared hosting, from the attacker's economic perspective, is "a treasure chest with a comically low per-box acquisition cost just hit the market." Lining up the buyers on one side and the bystanders on the other shows why this CVE is already being weaponized.

The people who want root on a shared hosting box are not only nation-state crews going after corporate intranets. The most cash-motivated operators are cryptocurrency mining gangs, scam crews shopping for phishing-page hosting, ransomware operators who extort tens of thousands of dollars in exchange for decrypting site data, and botnet-as-a-service vendors who resell compromised boxes by the count. What they really want is a single server that hosts hundreds or thousands of tenant sites in one place. One successful root foothold gives them every tenant's control panel credentials, every email body, every database, the source code of payment pages, and customer lists in one sweep. This CVE turns a single cheap monthly plan into root over every neighboring site on the chassis, which is why Mirai variants — and, per press reporting, ransomware — are described landing on the same box. Hundreds of WordPress sites on the same chassis end up simultaneously seeded with mining scripts, then mutated into phishing pages, then finally encrypted by ransomware — a three-layer stack of damage playing out in the real world right now.

In industry terms, a cross-tenant root takeover on shared hosting is called "cross-tenant compromise," and it is the scenario every SaaS and hosting provider fears most. The LiteSpeed cPanel plugin exists precisely to expose LiteSpeed settings to each tenant under tenant-scoped privileges; with that separation broken, an attacker can pay for the cheapest hosting plan available and escalate to box-wide root from inside their own account. That root then reaches the cPanel backup system, the mail stack (Exim/Dovecot), every tenant's MySQL credentials, and TLS private keys — far enough to damage the hosting provider's brand at a reputational level.

A perfect-10 score measures the damage on one box, but the structure of shared hosting spreads the pain evenly across the rent roll: e-commerce store owners, small law firms, and local media outlets who rented space on the same chassis end up named in the provider's "to all tenants" apology email, listed as the source of skimmed card data, and handed a payment-processor shutdown notice — even though none of them missed a patch themselves. The very design that made shared hosting cheap ("split the cost across many tenants") flips into a joint liability contract for the breach.

What the LiteSpeed cPanel plugin is, and where it runs

A quick map of where this bug sits, so you can decide whether it touches you.

cPanel is the de-facto control panel that most hosting providers hand to their customers. It is the web UI tenants use to create mailboxes, add databases, switch PHP versions, and so on. LiteSpeed Web Server is one of the most-deployed web servers on the planet — W3Techs tracking puts it in the high single-digit to low double-digit percent range of the top 10M websites, particularly popular for accelerating WordPress.

The vulnerable component, the LiteSpeed User-End cPanel Plugin, is the glue that exposes LiteSpeed features (Redis cache toggling, page-cache settings, image optimization) to tenants from inside cPanel. If a hosting provider has deployed cPanel + LiteSpeed together, this plugin is almost certainly present.

In practical terms, that means any WordPress-focused shared hosting brand, low-cost cPanel VPS image, or budget reseller that runs LiteSpeed for its speed boost is in scope. Custom in-house control panels — which most large Japanese hosts use — are not affected.

What's broken: two different holes

This plugin ended up with two distinct bugs that each hand out root in 2026. They use different mechanisms and were fixed in different releases, so take them one at a time.

CVE-2026-48172: an admin function that runs anyone's script as root (v2.3–v2.4.4)

The first defect is small and easy to state. From LiteSpeed's advisory:

"Any cPanel user (including an attacker or a compromised account) may exploit the lsws.redisAble function to execute arbitrary scripts as root."

lsws.redisAble is supposed to be a benign administrative helper for enabling Redis cache on a site. The implementation, however, mishandles privilege separation: instead of dropping to the caller's permissions, the helper runs the requested action with the server's root privileges. A feature designed to expose Redis toggling to tenants effectively became "a button that runs arbitrary commands as root." In CWE terms this is CWE-266: Incorrect Privilege Assignment. Affected versions are v2.3 through v2.4.4, closed in v2.4.5 and later (v2.4.7 recommended at the time). CVSS is the maximum 10.0.

CVE-2026-54420: a symlink-following bug that escalates to root (v2.4.7 and earlier)

The second bug is separate from the first. It didn't exist when this article first went up: LiteSpeed shipped the fix on June 1, 2026, and the CVE was assigned on June 14. Crucially, v2.4.7 — which closes the first bug — does not close this one. That is the detail most likely to trip up operators.

The mechanism is UNIX symbolic-link following (CWE-61). A symlink is a "shortcut" that points at another file. If an attacker plants a shortcut aimed at a system file they normally can't touch, the plugin follows that shortcut and rewrites the target while still holding elevated privileges. Per Gotekky's writeup, on CloudLinux/CageFS shared hosting (which fences off what each tenant can see), a low-privilege tenant with FTP or web-shell access can use this to escalate to root and break the isolation between accounts. Different entry point from the first bug, same destination: the shared-hosting separation collapses and the box is rooted.

Plugin version	State	What to do
v2.4.8 or later (WHM Plugin v5.3.2.1+)	Both fixed	Nothing further
v2.4.5 – v2.4.7	CVE-2026-48172 fixed CVE-2026-54420 still open	Update to v2.4.8 or later
v2.3 – v2.4.4	Both affected	Update to v2.4.8 or later

So the current safe baseline is plugin v2.4.8 or later plus WHM Plugin v5.3.2.1 or later (v2.4.8 appears to be the latest as of 2026-07-23). The "just get to v2.4.7" guidance that circulated during the initial coverage is out of date now that the second bug exists.

How to check whether your server has already been hit (one command)

If you have root or sudo on the box, LiteSpeed publishes a one-line check against cPanel's request logs:

grep -rE "cpanel_jsonapi_func=redisAble" /var/cpanel/logs /usr/local/cpanel/logs/

Every exploitation attempt traverses the JSON API endpoint cpanel_jsonapi_func=redisAble, so any hit is, by construction, a suspect request. Any non-empty result should be treated as a likely root-level compromise: validate the source IPs, block the malicious ones, and pivot to full incident response under the assumption the server was rooted. A clean result narrows the window but does not rule out earlier rotated-out activity, so apply the patch and tighten monitoring regardless.

Exploitation status: both bugs seen abused in the wild

Both bugs were confirmed being exploited in the wild at disclosure, and CISA listed both in its Known Exploited Vulnerabilities catalog. The "there's no PoC yet, so we're fine" phase is long past for both — treat each as being actively abused in real environments.

For the first bug (CVE-2026-48172), The Hacker News reported that observed activity included Mirai-family botnet variants repurposed to weaponize Linux hosting servers as DDoS launchpads, plus a ransomware strain. Mirai originally hijacked CCTV cameras and routers to power large DDoS attacks; the same lineage running on a Linux host turns one hosting box into a launch base. One caveat on the ransomware: that comes from press reporting. On CISA's KEV catalog, both CVEs are marked "known ransomware campaign use: Unknown" — meaning CISA has not marked ransomware use as confirmed, which is worth stating precisely.

For the first bug, no public proof-of-concept exploit code had surfaced as of May 26. As Cybersecurity News notes, "the technical simplicity of the vulnerability has enabled threat actors to develop private exploits rapidly." Read that as: there is no PoC because no PoC is necessary. The second bug (CVE-2026-54420) was likewise seen exploited in the wild at disclosure; CISA added it to KEV on June 15, with forensic-preservation requirements (per BOD 26-04) attached for federal agencies.

Remediation: for server admins and for hosting tenants

The right action depends on which side of the wall you sit on.

▼ Hosting providers and VPS / dedicated server admins

Patch LiteSpeed User-End cPanel Plugin to v2.4.8 or later (with WHM Plugin v5.3.2.1 or later). That closes both bugs (CVE-2026-48172 and CVE-2026-54420). Stopping at v2.4.7 leaves the second hole open, so boxes previously marked "done" at v2.4.7 need to be bumped again to v2.4.8+. Follow LiteSpeed's June 1 release log.

cPanel itself issued an emergency security update on May 19, 2026 that automatically uninstalls the vulnerable plugin on update. If your automatic cPanel updates are running, the plugin may already be gone; force the path explicitly to be sure:

# Force-apply cPanel updates (will pick up the auto-uninstall logic)
/scripts/upcp --force

# If patching is not yet possible, remove the plugin manually:
/usr/local/lsws/admin/misc/lscmctl cpanelplugin --uninstall

After patching, run the grep check above on historical logs. If you see hits, work the incident as a confirmed root compromise — half-measures will not clean up an attacker who already owned the box.

▼ Shared hosting tenants

You cannot patch this yourself; the fix is your provider's responsibility. What you can do:

Confirm whether your hosting provider uses cPanel + LiteSpeed. (If your control panel URL contains :2083 or cpanel, you are on cPanel.)
Check your provider's status / security page for a CVE-2026-48172 / CVE-2026-54420 advisory (have they updated the plugin to v2.4.8 or later?). If silence, open a support ticket and ask which plugin version they are running.
Rotate every credential tied to that hosting account: cPanel password, WordPress admin, mailbox passwords, and any API keys stored on the server. Assume credential exposure if any other tenant on the same box was compromised.

Timeline: how both bugs came out

← Swipe to navigate

Why shared hosting makes this worse: one weak tenant can topple the whole box

What turns CVE-2026-48172 from "another LPE" into a hosting-industry crisis is the entry condition: the attacker only needs any single valid cPanel session. That can be the attacker's own cheap shared hosting account, or a victim tenant's account picked up via credential stuffing. Either way, the moment that single session exists, every other site on the same physical server is reachable.

Shared hosting's business model packs hundreds to thousands of tenants on one box, relying on OS-level permission separation to keep them apart. CVE-2026-48172 punches a hole through that separation by handing root to anyone who can call a JSON API endpoint. In effect: "another tenant on your server had a weak password" becomes "your site got rooted too."

This pushes the operational burden well past "apply patch." Hosting providers also need to think about tenant-wide disclosure, breach-notification timing, and the legal exposure that comes with a single-incident, many-victim posture.

What to actually do: get to v2.4.8 or later

This plugin picked up two different root-takeover bugs in 2026 (CVE-2026-48172 and CVE-2026-54420), both confirmed exploited in the wild and both on CISA's Known Exploited Vulnerabilities catalog. For admins the conclusion is simple: get the plugin to v2.4.8 or later (WHM Plugin v5.3.2.1+) and both are closed. Boxes stopped at v2.4.7 still carry the second one — bump them.

If you're a tenant, the one thing worth checking is whether your hosting provider runs cPanel + LiteSpeed. If they do, look for their advisory (have they moved to v2.4.8 or later?), rotate your credentials, and verify your most recent off-server backup.