Any shared hosting customer can become root on the entire server. CVE-2026-48172 in the LiteSpeed cPanel Plugin achieved CVSS v4.0 10.0 — the maximum score — and is already under active exploitation. At Tech86, we tracked this vulnerability closely because it exposes a structural flaw in the shared hosting model: when any tenant can escalate to root, isolation between customers ceases to exist.
The bug: root for any tenant
The lsws.redisAble function in the LiteSpeed cPanel Plugin executes arbitrary scripts with root privileges. Any authenticated cPanel user can invoke it, regardless of their account's privilege level.
This is not a sandbox escape. Not limited escalation. It is root on the machine — the same root that accesses repositories, databases, and credentials of every other customer hosted on that server. The function should have validated permissions before executing. It did not. Any cPanel account, from the most basic plan to a reseller, had direct access.
The CVSS v4.0 vector is AV:N/AC:L/AT:N/PR:N/UI:N. In practical terms: network-accessible, low complexity, no special privileges required, no user interaction. In a shared hosting context, any cPanel account suffices — including the cheapest plan or an account compromised through phishing. The barrier between "my website" and "the entire server" simply did not exist for this function.
Active exploitation and timeline
The timeline shows how fast the ecosystem moved:
- May 19: David Strydom reports the vulnerability to LiteSpeed
- May 19: LiteSpeed ships a fix the same day
- May 21: Public advisory. Active exploitation confirmed. Automated scanners began hours after publication
- May 26: CISA adds to the Known Exploited Vulnerabilities (KEV) catalog with a June 16 patch deadline
The vendor responded fast — a fix shipped on the same day as the report. But patch distribution across the hosting ecosystem is not automatic. Hosting providers must manually update each server. Days after the advisory, servers were still running the vulnerable plugin. Opportunistic scanners hit every reachable host. One unpatched server is enough.
The window between the advisory (May 21) and the CISA listing (May 26) was five days. Five days with confirmed active exploitation and potentially thousands of unpatched servers. For companies on shared hosting, those five days represent an exposure window they cannot control — you do not manage the server, you do not apply the patch, you do not monitor the logs.
With root on the server, attackers can: access private repositories of all customers, dump credentials (hashes, API tokens, SSH keys, 2FA secrets), pivot to other systems on the network, modify code in any hosted repository, and deploy ransomware. One compromised tenant compromises everyone else on the same machine. The scale of impact is proportional to the number of tenants — on shared hosting servers, that can mean hundreds of sites affected by a single exploitation.
The patch and mitigation
The definitive fix requires two updates: WHM Plugin 5.3.1.0 and cPanel Plugin 2.4.7. Earlier versions provide only partial mitigation.
If patching immediately is not possible, the mitigation is to uninstall the User-End cPanel Plugin. This removes the lsws.redisAble function from the attack surface accessible to tenants. There is functionality loss, but a compromised host with root access is infinitely worse than a disabled plugin.
Auditing must cover the entire fleet. Fixing one server is not enough — in shared hosting environments, each exposed machine is an independent attack vector. For companies that do not manage their own servers, the only actionable step is to pressure the provider to confirm the patch has been applied and, ideally, to provide evidence that no compromise occurred before the fix.
The CISA deadline is June 16. For US federal agencies, this is mandatory. For Brazilian companies on shared hosting, the risk is the same — the vulnerability does not discriminate by jurisdiction.
Shared hosting breaks by design
This CVE is not an isolated incident — it is a symptom of a structural problem. Shared hosting depends on tenant isolation. When a bug escalates any tenant to root, the model breaks by design.
The premise of shared hosting is that multiple customers share the same kernel, the same filesystem, and the same web server process, trusting that user permissions and cPanel configurations prevent cross-access. A single privilege escalation bug invalidates that entire premise. And privilege escalation bugs are not rare — they are a recurring category of vulnerability in Linux systems.
The problem is not specific to LiteSpeed. Any component that executes privileged operations on behalf of untrusted users is a candidate for this type of flaw. In shared hosting, the attack surface is multiplied by the number of tenants. Each cPanel account is a potential entry point. Each plugin installed on the server is a potential escalation source.
If your company runs on shared hosting with LiteSpeed, you depend on two things you cannot verify: that your provider applied the patch, and that no other customer was compromised before the patch. The second condition is especially critical — if an attacker obtained root before the fix, they already have persistence on the server. Kernel-level backdoors are difficult to detect and can survive software reinstalls.
Real isolation is the answer
At Tech86, we help companies migrate from shared hosting to cloud-native infrastructure with real tenant isolation. Each environment runs in its own isolation layer — no shared root, no depending on your neighbor's patch.
Cloud hosting with container or VM isolation means a compromise in one environment does not propagate to others. One tenant's attack surface does not include the kernel or filesystem of the rest. When the next privilege escalation CVE appears — and it will — the blast radius is contained.
In practice, this means that even if an attacker finds an equivalent vulnerability in a cloud environment with real isolation, the damage is confined to a single tenant. The rest continue operating normally. No cascade effect. No collective compromise.
CVE-2026-48172 is a clear reminder: in shared hosting, your business security depends on your neighbor's security. If that dependency is not acceptable, it is time to consider infrastructure with real isolation.