Update, September 16: LiteSpeed has released a second fix, 6.3.7 build 1, closing another corner case in internal redirect URL validation. If you applied 6.3.7 after this article, you need to update again. Details and commands are in our follow-up post. All GillyTech servers are on the new build.
An advisory marked URGENT landed in our inbox this morning, September 15. LiteSpeed Technologies has patched a critical privilege escalation flaw in LiteSpeed Web Server Enterprise, the web server software running underneath a very large share of the world’s cPanel hosting, including ours. Every GillyTech server was on the fixed version within the hour. Then we wrote this post.
What the Flaw Actually Is
Privilege escalation means a user who is only supposed to be able to touch their own account finds a way to become root, the account that owns the entire machine. On a shared server, dozens or hundreds of unrelated websites sit side by side, kept apart by account isolation. This flaw let a malicious low-privilege website user climb out of their own account and take the whole box: every other site on it, every database, every set of credentials, and the server itself.
Neither LiteSpeed nor cPanel published the exact mechanism, which is normal while operators are still patching. The release notes point at three hardened areas. The first is lscgid, the small helper process LiteSpeed uses to run scripts as the correct user account (CGI is the long-standing method a web server uses to hand a request off to a separate program). The second is stricter validation of internal redirect URLs. The third is a block on setting internal-use environment variables from .htaccess, and that one is worth pausing on, because .htaccess is a file any hosting customer can write inside their own folder without asking anyone.
CageFS Did Not Hold
The part of the advisory that should get your attention is the isolation bypass. CageFS is CloudLinux’s per-account cage: each customer gets their own restricted view of the filesystem so they cannot see or reach anything belonging to their neighbors. It is the layer the shared hosting industry points at when you ask what stops one compromised site from spreading. LiteSpeed’s advisory says this issue bypasses expected account isolation controls, CageFS included.
That is the whole argument for defense in depth in one sentence. You do not run isolation because it is perfect. You run it because most attacks stop there. When one does not, the only thing left between you and a bad afternoon is how fast your host applies the patch.
Affected and Fixed Versions
- Affected: LiteSpeed Web Server Enterprise, every release before 6.3.7.
- Fixed: 6.3.7, released September 11, 2026.
- Not this advisory: OpenLiteSpeed and the LiteSpeed Cache WordPress plugin are separate products. If you run either one, this specific issue is not yours to fix.
- No CVE number yet. As of this morning there is no tracking identifier assigned, no published workaround, and no list of indicators to check for a prior compromise.
- Do not wait for automatic updates. LiteSpeed has said there may be a delay before auto-update reaches 6.3.7.
Mitigation: How to Patch Right Now
If you administer your own LiteSpeed Enterprise server, run the upgrade by hand as root:
/usr/local/lsws/admin/misc/lsup.sh -f -v 6.3.7Then confirm the version actually changed:
/usr/local/lsws/bin/lshttpd -vIf the output still shows anything below 6.3.7, you are still exposed. If you are on a plan where someone else administers the server, you do not run this. You ask them whether they already did.
The Post-Upgrade Check Almost Nobody Will Do
Buried at the end of the advisory is a note that the stable 6.3.7 release includes an adjustment that lets tightly controlled, root-owned programs keep running. Translated: the fix tightens what lscgid is willing to execute, and legitimate tools that ride on that path can break quietly.
After upgrading, look for unusual CGI activity and check piped logging, which is the arrangement where the web server hands each log line to another program instead of writing it straight to a file. Then confirm server-level logs are still being written at all. A server that patched successfully and stopped logging is a server you cannot audit later, which is exactly the day you will wish you could.
What Happened on Our Side
Advisory in, fleet upgraded to 6.3.7 and verified, article written. In that order, inside the same hour. That ordering is deliberate and it is becoming a habit around here. When cPanel disclosed CVE-2026-65643 last month we patched first and explained after. Same with CVE-2026-67402 in ConfigServer Firewall two weeks ago.
It is worth naming the pattern, though. This is the third flaw in the LiteSpeed product family since May that ends with somebody getting root, and the first one inside the web server itself rather than a companion plugin. Three in four months is not a reason to abandon LiteSpeed, which is still the fastest way to serve WordPress at this price point. It is a reason to treat patch speed as a feature you are paying for rather than a courtesy you hope for.
The Question Worth Asking Your Host
You do not need to understand lscgid to hold your host accountable. Send them one line: “When did our server go to LiteSpeed Enterprise 6.3.7?” A date and a time is an answer. “We are reviewing it with our vendor” is also an answer, just a different one. On a shared server, your exposure is not only your own site’s code. It is every other site sitting on the same machine, which is precisely what this flaw was good for.
Want your hosting handled by people who patch first and post second? GillyTech runs managed WordPress hosting and application hosting on infrastructure where security updates go out within the hour, not at the next maintenance window. Schedule a call and stop finding out about advisories from us.
