Intro
A hosting account that should be locked down now has a path to root on your shared cPanel server. That is what the current LiteSpeed Enterprise vulnerability does. cPanel published an advisory on September 14 warning that versions before 6.3.7 let a low-privilege website user break out of CageFS and run commands as the server root. If you share a machine with other clients, this is not a theoretical edge case. It is the difference between a compromised staging site and a fully owned server.
You might be tempted to wait for the auto-update pipeline to move the new build across your fleet. Do not do that. Both cPanel and LiteSpeed recommend running the manual update command today. LiteSpeed’s own documentation flags that there “may be some delay” before the release reaches auto-update, and as of September 15 the vendor’s download page still listed 6.3.6 as the stable build. That gap matters because attackers do not care about your auto-update schedule. I have sat on the phone with hosting customers who assumed their control panel would handle these patches automatically. This one will not.
The people at risk are straightforward. If you run LiteSpeed Enterprise on cPanel, and you host more than one customer or site on the same box, you are in the blast zone. The flaw targets the boundary between accounts, the very thing CageFS is supposed to enforce. A single poorly hardened WordPress install or a misconfigured PHP app could become the entry point. One account gaining root access on a shared server is as bad as it sounds. It means every other customer’s databases, credentials, and configuration files sit on the table.
What you need to do in the next few minutes is simple and non-negotiable. Run the force-update command on every Enterprise box you manage. Verify the version with lswsctl -v. Touch the follow_stable marker so your servers return to normal auto-update behavior afterward. Skip the rest of the housekeeping until after the command runs. I will walk through exactly what to expect and why the details around 6.4.0 release candidates matter in a moment, but the first step is getting the patch on the wire.
Background on the LiteSpeed Enterprise vulnerability
cPanel published its advisory on September 14, and the core message was blunt. Versions of LiteSpeed Enterprise prior to 6.3.7 contain a flaw that lets a low‑privilege hosting account bypass CageFS and escalate to root on a shared server. CageFS is the CloudLinux layer that gives each account its own restricted filesystem view. It is supposed to be the wall between one customer’s WordPress install and another customer’s databases, credentials, and configuration files. This vulnerability quietly removes that wall.
Neither cPanel nor LiteSpeed has assigned a CVE identifier to the issue, and no severity score appears in any published record as of September 15. That means you will not find a CVSS number attached to it in threat feeds yet. Both vendors have also refrained from describing the technical mechanism behind the bypass, and neither has confirmed whether the flaw is being exploited in the wild. LiteSpeed simply called 6.3.7 a release with “Security improvements, bug fixes, and more!” The changelog lists three security changes but does not label any of them as the fix for a privilege‑escalation or CageFS bypass issue. That ambiguity is going to matter later when administrators try to verify what exactly was patched.
The silence around exploit details is not unusual for a vendor under pressure, but the pattern here deserves a closer look. This is already the third time since May that a LiteSpeed flaw on cPanel servers has granted a hosting account root access. Two earlier vulnerabilities in the LiteSpeed cPanel plugin itself, tracked as CVE‑2026‑48172 and CVE‑2026‑54420, were actively exploited in the wild and subsequently added to CISA’s Known Exploited Vulnerabilities catalog. Those were plugin‑side flaws. This one lives inside the web server itself. That distinction makes it structurally worse. A compromised plugin is contained to one path. A compromised web server process touches every request flowing through it.
I do not know what drives the current release cadence at either company, but the gap between LiteSpeed shipping 6.3.7 on September 11 and cPanel issuing its advisory on September 14 is long enough for automated exploitation scripts to appear. When vulnerabilities like this sit unpatched even for a few days, the people who move fastest are the ones scripting targeted attacks against shared hosting infrastructures. They do not read advisory bulletins. They scan ports and launch payloads.
There is also no workaround listed in either advisory. If your server cannot be updated immediately, you are left with no documented mitigation and no indicators to check for whether a compromise has already occurred. That absence of guidance is frustrating, and it reinforces the point made in the previous section. You update now, and you treat any delay as a risk you are choosing to carry.
LiteSpeed Enterprise Flaw Could Let One Hosting Account Gain Root Access on a Shared Server (opens in new tab), The Hacker News, September 15, 2026.
What’s happening now with the LiteSpeed Enterprise vulnerability
Here is where things get slightly inconvenient. LiteSpeed published 6.3.7 on September 11. cPanel did not publish its advisory until September 14. That three-day window matters because automated exploitation tools do not read advisory bulletins, they just scan and shoot.
The real problem is what you see if you visit the LiteSpeed download page today. As of my checking on September 15, the page still lists 6.3.6 as the current stable release. It also lists a July pre-release build of 6.4.0-RC1. The newer 6.3.7 build has not been promoted to the stable slot in LiteSpeed’s own repository metadata, which is what most auto-update mechanisms consult. That is why both companies are telling administrators to run the manual command.
The command itself is simple enough: /usr/local/lsws/admin/misc/lsup.sh -f -v 6.3.7. I have run variations of this on boxes where the vendor auto-update pipeline was lagging behind a hotfix, and it works exactly as advertised. It forces the server to pull the tagged version from the repository rather than waiting for the next scheduled auto-update cycle. The -f flag overrides the normal stable-channel check, and -v 6.3.7 pins it to that specific release. That pinning is intentional. If you do not use it, the server may continue waiting for a stable promotion that is not coming soon, or worse, it could jump ahead to 6.4.0-RC1, which is an untested pre-release and absolutely not something you want running production traffic on a shared cPanel server.
There is one small but important follow-up step after running that command. LiteSpeed’s own update documentation states that forcing a specific version stops the server from following its normal stable update tier. To resume normal auto-updates, you need to run touch /usr/local/lsws/autoupdate/follow_stable. If you skip this step, the server stays locked to 6.3.7 and will not receive future stable releases automatically. I have seen this exact pattern trip people up before. They force the patch to survive an emergency, forget about the second command, and then wake up weeks later wondering why their server has not updated past an old build.
I do not know how long LiteSpeed will leave 6.3.6 listed as the stable build alongside the newer release. This kind of metadata lag happens more often than vendor communications admit. The safe move is to force the update now, confirm the running version with lswsctl -v, and then touch the follow_stable file so normal auto-update resumes.
What the LiteSpeed Enterprise vulnerability means in practice
A few questions keep coming up since the advisory dropped, and most of them come from sysadmins who are trying to figure out whether their specific setup is actually in danger.
Does this affect OpenLiteSpeed? No. The advisory names only the Enterprise edition, and LiteSpeed had not published a matching open-source update as of September 15. If you are running OpenLiteSpeed for personal projects or internal tools, this one does not touch you. The vulnerability lives in the commercial product, not the open-source fork.
Are the 6.4.0 release candidates affected? cPanel’s advisory does not say, and the 6.4.0-RC1 changelog does not list the three security changes that accompanied 6.3.7. I would not assume RC1 is safe simply because it is newer. Untested pre-releases on shared hosting servers are a bad idea regardless of which CVEs they patch. Stick with 6.3.7 until cPanel or LiteSpeed confirms otherwise.
How do I apply the fix and then resume normal auto-updates? Run /usr/local/lsws/admin/misc/lsup.sh -f -v 6.3.7 to force the patch, then run touch /usr/local/lsws/autoupdate/follow_stable to return to the stable update tier. I covered why both commands matter in the previous section. Skipping the second one locks you to an old build and leaves you exposed to whatever comes next.
Is there a workaround for servers that cannot update immediately? Neither the cPanel advisory nor LiteSpeed’s release notes provide a workaround, and neither company has published any indicators that a server has already been compromised. If you have a box you cannot take offline tonight, there is no documented mitigation. Patching is the only path. That is not a helpful position to be in during a active threat window, but it is the reality both vendors have communicated so far.
The practical takeaway is straightforward. Force the update on every Enterprise box you can reach right now. Verify with lswsctl -v. Touch follow_stable. If a server is unreachable or locked down for business reasons, treat it as unpatched until you can get to it. There is no middle ground here.
What to expect next
cPanel’s advisory and LiteSpeed’s release notes are deliberately vague today. That will not last. The two companies have not assigned a CVE or a severity score, and a search of published CVE records on September 15 returned nothing. Expect a formal identifier to appear in the coming days, likely paired with a CVSS score that reflects the root-level impact described in the advisory. Until then, the uncertainty is a liability. I would not assume a missing CVE means the issue is low risk. It usually means the tracking process is still catching up to the operational panic.
If independent researchers or threat‑intel vendors confirm active exploitation in the wild, the likelihood of CISA action rises sharply. The pattern is already set. The two earlier LiteSpeed‑on‑cPanel flaws, CVE‑2026‑48172 and CVE‑2026‑54420, moved from early‑access exploitation reports to CISA’s Known Exploited Vulnerabilities catalog within weeks. I have seen the same cadence before. Once proof‑of‑concept material surfaces, or once a vendor like CloudLinux publishes detection logic for the bypass, the government catalog tends to follow. You should prepare for that scenario now, not after the fact.
The bigger open question is technical. LiteSpeed’s announcement for 6.3.7 calls it a release with “Security improvements, bug fixes, and more!” and the changelog lists exactly three security changes. Neither cPanel nor LiteSpeed has said which of those three closes the CageFS bypass. That omission is unusual for a critical advisory. I suspect clarification will come within 48 hours, likely buried in a forum post or a short addendum to the original advisory. Until then, treat 6.3.7 as the fix and do not chase release‑candidate builds for production boxes.
Think of it like discovering a broken latch on your front door. The landlord sends a maintenance crew with a handful of new parts. You do not know which part actually solves the problem, but you do know the door is currently unsecured. You install the recommended part, lock down the perimeter, and wait for the follow‑up note. That is the posture you want right now.
Watch for a clarified advisory that names the exact change. If it matches one of the three documented security items, you can audit your own build logs and confirm the patch landed. If the fix turns out to be undocumented, the situation shifts. That would imply an older, unreported flaw was quietly corrected alongside the announced changes, which is a less transparent path but not impossible given the timeline. Either way, the immediate priority is the same. Run the force‑update command, verify the version, and touch follow_stable so the server returns to its normal update cadence. The advisory from The Hacker News (opens in new tab) makes it clear that neither vendor has offered a workaround, so delaying is not an option for any shared‑hosting environment.
Closing: concrete next step
Run /usr/local/lsws/admin/misc/lsup.sh -f -v 6.3.7 on every LiteSpeed Enterprise box you manage today. Do not wait for auto-update to catch up. The command forces the upgrade regardless of whatever the update tier thinks is current, and it will pull 6.3.7 even if LiteSpeed’s download page still shows 6.3.6 as stable. I have watched auto-update lag behind manually available releases before, and this pattern is not unusual.
Once the script completes, verify the installation immediately. Run lswsctl -v and confirm the output reads 6.3.7 or higher. If it does not, something went wrong with the fetch or the install. Check the script’s output log. Do not assume the patch landed because the command returned without error. I have seen the updater report success while leaving an older build in place after a partial download. A version check is free and takes ten seconds. It saves you from flying blind.
After you confirm the version, resume normal auto-update behavior. Run touch /usr/local/lsws/autoupdate/follow_stable. That single command tells the updater to return to its regular stable channel instead of remaining locked to the 6.3.7 pin you just forced. If you skip this step, your server stays stuck on 6.3.7 until someone remembers to touch the file again. I learned that the hard way on a low-traffic staging box, and it stayed three weeks behind on the next security bump because nobody checked.
Do this across every Enterprise instance, not just the primary web server. If you run LiteSpeed in proxy mode or as a static accelerator behind Apache, the same code path applies. The vulnerability targets the Enterprise binary itself, not a specific configuration role. I treat every Enterprise build on a cPanel stack as potentially exposed until I verify the version directly.
If you operate multiple accounts or manage boxes through a panel like WHM, log into each one and repeat the check. Shared hosting setups are where this matters most because a single compromised CageFS session can escape to root and touch any customer’s files. The advisory makes that threat model explicit. You do not need to hunt for signs of prior compromise right now. Neither cPanel nor LiteSpeed has published indicators, and chasing ghosts wastes time better spent on patching.
Get the command into your playbook, execute it, and move on. The vulnerability details remain scarce, but the fix is already in your hands.