LiteSpeed Enterprise Flaw Risks Root on Shared Hosts

A single compromised hosting account on a shared server is normally a contained problem — one tenant's bad day, not everyone's. According to cPanel, that assumption may not hold for sites running LiteSpeed Web Server Enterprise, where a low-privilege user could reach all the way to root and touch every other customer on the same machine.

cPanel published an advisory on September 14 describing a critical flaw in the web server that affects versions before 6.3.7, the release LiteSpeed shipped on September 11. Neither company has explained how the bug works, and as of the day after the advisory, no CVE identifier or severity score had been attached to it.

A tenant escape on shared metal

The economics of shared hosting depend on isolation. Dozens or hundreds of customer sites live on one physical server, and the platform's job is to make each account believe it is alone. cPanel's advisory says this flaw breaks that arrangement: an attacker holding one hosting account could use it to read or modify other tenants' sites and the server itself.

That is a different class of problem from a website being defaced. Root on a shared box means the attacker can reach configuration files, other customers' data, and the machinery that ties the accounts together. cPanel's warning describes both access and alteration, not just a leak.

The flaw is specifically tied to the Enterprise edition of LiteSpeed's web server. cPanel's advisory names only that edition and does not address OpenLiteSpeed, the company's open-source server, for which LiteSpeed had released no matching update as of September 15.

CageFS is not a wall here

Shared hosts lean on isolation layers precisely because the underlying server is common ground. cPanel said the flaw can bypass the controls meant to keep accounts apart, including CageFS. CageFS, a CloudLinux tool, gives every hosting account a restricted view of the file system so it cannot see its neighbors or the server's configuration files.

Because the flaw defeats that containment, the usual reassurance that a shared plan is safe as long as the provider isolates tenants does not apply to unpatched Enterprise installs. An account that should be boxed in can apparently step outside the box.

CloudLinux was among the parties The Hacker News contacted with questions about the flaw, along with LiteSpeed and cPanel. None of the three had explained the mechanism publicly at the time of the advisory.

What the vendors are not saying

LiteSpeed's announcement of 6.3.7 described it as a release with "Security improvements, bug fixes, and more!" Its changelog lists three security changes but does not mention a privilege-escalation flaw, and neither company has said publicly which change fixes the issue.

The advisory carries no CVE identifier or severity score, and a check of published CVE records on September 15 found none for the flaw. It also does not say whether the flaw has been exploited in the wild. That silence matters for defenders trying to judge urgency: without a CVE, tracking systems, scanners, and vulnerability feeds have nothing to key on, so the only signal that this is serious is cPanel's own advisory language.

cPanel's advisory does not say whether the 6.4.0 release candidates are affected either, leaving administrators on pre-release builds without a clear answer.

The fix, and why auto-update may miss it

Both cPanel and LiteSpeed give the same command to install 6.3.7: /usr/local/lsws/admin/misc/lsup.sh -f -v 6.3.7. The manual step is the point. LiteSpeed said there "may be some delay" before the release reaches auto-update, so administrators who wait for the update to arrive on its own may stay exposed longer than they expect.

There is a wrinkle for anyone forcing the version. LiteSpeed's update documentation says that forcing a specific version with this command stops the server from following its stable update tier. Administrators can resume automatic stable updates afterward by running touch /usr/local/lsws/autoupdate/follow_stable.

Reaching for 6.3.7 also runs into a practical oddity: as of September 15, LiteSpeed's download page still listed 6.3.6 as the stable release, alongside a July pre-release build of 6.4.0 (RC1) whose changelog does not list the three security changes. In other words, the version that closes the hole was not the one the download page was advertising as stable the day after cPanel's warning.

No workaround, no way to check

For hosts that cannot update immediately, cPanel's advisory and LiteSpeed's release notes offer no workaround. That leaves administrators with a hard choice: accept the manual update, or accept the risk on a server where one tenant could reach root.

There is also no guidance for determining whether a server has already been attacked. Neither document provides indicators of compromise or a method to check for prior exploitation, which means an operator who patches today has no built-in way to tell whether the door was already opened. The advisory is silent on both fronts.

Anyone whose provider runs LiteSpeed Enterprise on shared infrastructure should treat "we're on the latest available version" as a question worth asking directly, rather than a fact to assume.

Third root-level flaw since May

This is the third time since May that a flaw in LiteSpeed software on cPanel servers has been reported to grant a hosting account root access. It is the first in the web server itself.

In May and June, LiteSpeed disclosed two such flaws in its user-end cPanel plugin, CVE-2026-48172 and CVE-2026-54420. The company said both were being actively exploited and fixed both in the plugin. CISA later added both to its Known Exploited Vulnerabilities catalog, as The Hacker News reported in May and June.

The pattern is worth noting without overreading it: the two earlier bugs were in a plugin, this one is in the server. The earlier flaws had CVE identifiers and confirmed exploitation; this one currently has neither. The Hacker News has contacted LiteSpeed, cPanel, and CloudLinux with questions about the flaw.

What shared-host customers should press for

The practical exposure here falls on anyone whose site sits on a shared LiteSpeed Enterprise server — which, from the customer's side, is usually invisible. Tenants rarely know which web server their provider runs, let alone whether it has been updated to 6.3.7. That makes the update a provider-side responsibility, and the advisory is effectively a notice to hosting companies rather than to their customers.

For administrators, the sequence is narrow: update to 6.3.7 using the given command, then restore the stable update tier with the follow_stable touch command if they forced the version. There is no interim mitigation to reach for, and no way to confirm whether an intrusion already happened. Both gaps push toward treating the update as the only lever available.

For everyone else, the useful move is a question: which LiteSpeed version is my host running, and has it been patched? A provider that answers with a version number and a date is in a better position than one that answers with reassurance alone. This story is, so far, a single-vendor warning without independent confirmation of the flaw's mechanics, exploitation status, or severity scoring — which is itself a reason to ask rather than assume.