LiteSpeed Web Server Enterprise 6.3.7 has been released three times in six days, and every build carried a security change: build 0 on September 11, with three security fixes, then build 1 on September 15 and build 2 on September 16 with one further fix each. In between, on September 14, cPanel published an advisory on what it calls a critical privilege-escalation vulnerability: on shared-hosting servers, “a malicious low-privilege website user could potentially gain root-level access,” bypassing “expected account isolation controls, including CageFS.” A server updated to 6.3.7 on the day of the advisory is therefore not on the latest build, and LiteSpeed’s second email to customers said so in as many words: “Even if you updated following yesterday’s advisory, please apply this latest update.” Neither cPanel’s advisory nor LiteSpeed’s release notes identify which of build 0’s three security changes corresponds to the disclosed vulnerability.

What is known is short. cPanel writes that it “received notice” of the flaw, without saying from whom. The advisory carries no CVE identifier, no score and no description of the mechanism, and it does not say whether the flaw has been exploited. Its page is marked as updated since publication, with no indication of what changed. The one instruction both companies agree on is a command, and the practical question for anyone running LiteSpeed on shared hosting is not whether they ran it but when.

The same description went out from LiteSpeed itself. Beginning on September 15, customers posted copies and excerpts of the company’s emails, signed “LiteSpeed Team,” on LowEndTalk and the DirectAdmin forum. The first email matches cPanel’s advisory word for word in its description of the flaw and adds what the cPanel page does not carry: a severity line, “Critical,” the release log, and a note headed “Important Post-Upgrade Note.” That note says the release “includes an adjustment that permits tightly controlled, root-owned binaries to continue operating safely,” and asks administrators to “review your server for unusual CGI activity or piped logging behavior and verify that server-level logging continues to function normally.” 

The second email, posted on September 16, announces build 1 as “an additional update addressing another corner case in internal redirect URL validation” and, “because the original vulnerability could allow a malicious website user to bypass expected account-isolation controls,” asks all customers to “update again.” A build 2 announcement followed the same day. LiteSpeed has published no standalone security advisory describing the flaw on its website. Its public pages carry only the release announcements and terse changelog entries.

Acronis cPanel Backup Plugin: Exploited Privilege-Escalation Flaw on CISA’s List

Key facts

  • The warning: cPanel’s advisory of September 14 covers LiteSpeed Web Server Enterprise “versions prior to v6.3.7” and recommends “v6.3.7 or later.” A low-privilege website user could bypass account isolation, CageFS included, and gain root on a shared server. Enterprise only, OpenLiteSpeed not addressed, and one provider on LowEndTalk reported a support ticket asking whether OpenLiteSpeed is affected had gone unanswered for two days.
  • The side effect: forcing a version with -f -v removes the follow_stable marker. After that, a plain lsup.sh run, the form LiteSpeed recommends for cron, “will do nothing.” Notifications also “are not sent for new builds of the same version number.” Operators have to watch LiteSpeed’s build announcements or changelog, or check the installed build directly. The marker is restored with touch /usr/local/lsws/autoupdate/follow_stable.
  • The check: the installed build is the contents of /usr/local/lsws/BUILD. The command in both the advisory and LiteSpeed’s announcement, /usr/local/lsws/admin/misc/lsup.sh -f -v 6.3.7, installs the latest build of the version: build 2 as of September 17, but build 0 when cPanel published its advisory on September 14.
  • The gap: no CVE, no score, no exploitation statement, no workaround for servers that cannot update. The only guidance on what to look for afterward is the email’s line about “unusual CGI activity or piped logging behavior.”

Three Builds in Six Days

LiteSpeed’s changelog is the public record of what changed, and it is terse. Its security entries for 6.3.7, in full:

  • Build 0, September 11: “Enhance lscgid request authentication and validation.”
  • Build 0, September 11: “Apply stronger validation of internal redirect URL.”
  • Build 0, September 11: “Block setting of important internal-use environment variables from .htaccess.”
  • Build 1, September 15: “Address another corner case in internal redirect URL validation.”
  • Build 2, September 16: “Further harden lscgid.”

The 6.4.0 release candidate received the build 0 changes on September 14 and the lscgid hardening on September 16, with no RC2 entry matching build 1’s redirect fix, and LiteSpeed’s RC2 announcement asks users to “proceed with caution.”

The sequence matters because of how LiteSpeed updates reach servers. The company’s announcement of 6.3.7 says there “may be some delay between this announcement and the ability to auto-update,” and gives the manual command as the way not to wait. Forcing a version that way takes the server off the stable tier, and new builds of the same version send no server notification in any case, so a server updated with that command on September 11 or 14 would not receive builds 1 and 2 through a plain lsup.sh cron unless the follow_stable marker was restored or another update mechanism was in place. The check is the contents of /usr/local/lsws/BUILD, and as of September 17 the number to look for is 2.

None of this says that build 0 left the flaw open. cPanel’s advisory treats 6.3.7, which on September 14 meant build 0, as the fix for the disclosed vulnerability, defining affected systems as versions prior to it. What the public record does not explain is which of build 0’s three security changes addressed it, or whether builds 1 and 2 close additional variants of the same underlying issue. LiteSpeed describes them only as another redirect-validation corner case and further lscgid hardening, and its second email ties build 1 to “the original vulnerability” without saying how.

Ten IP Addresses Sent at Least 94,000 Attempts to Exploit a WooCommerce Plugin.

The Third Publicly Disclosed Root Path Through LiteSpeed Since May

This is the third publicly disclosed case since May in which a hosting account on a shared server could reach root through LiteSpeed software, and the first time the flaw is in the web server rather than in a cPanel plugin. The two earlier ones, both in LiteSpeed’s user-end cPanel plugin and both described by LiteSpeed as actively exploited:

  • May 21, CVE-2026-48172: “any cPanel user” could “execute arbitrary scripts as root.” Added to CISA’s Known Exploited Vulnerabilities catalog on May 26.
  • June 1, CVE-2026-54420: “a user with FTP or web shell access” could “escalate privileges to root on shared hosting servers running CloudLinux/CageFS.” Added to the catalog on June 15.

The September flaw differs on four points of public record. It has no CVE. It has no statement on exploitation either way. LiteSpeed disclosed it by email rather than in a security post, and its website headlines 6.3.7 as “Security improvements, bug fixes, and more!” and lists the three entries without describing a flaw. And it sits in the server that serves every site on the machine, not in a control panel plugin that can be uninstalled while a fix is awaited. For a shared hosting provider the immediate patching step is clear: read the build number on every LiteSpeed server, compare it with the latest build in LiteSpeed’s changelog, and update any server that is behind.

About the Data

Build dates and the wording of each security change come from LiteSpeed’s changelog and release announcements. The update script’s behavior and the location of the build number come from LiteSpeed’s documentation. What cPanel’s advisory says, and does not say, comes from the page as it stood on September 17. Copies and excerpts of LiteSpeed’s two emails were posted by customers on LowEndTalk and the DirectAdmin forum and are quoted from there. The May and June flaws come from LiteSpeed’s security posts and CISA’s catalog. Which of build 0’s changes addresses the disclosed flaw, and how builds 1 and 2 relate to it, has not been stated, and this article infers nothing beyond the public record.