LiteSpeed zero-day bypassed CageFS and enabled root access

A LiteSpeed zero-day reached production servers

LiteSpeed Web Server Enterprise has a zero-day vulnerability that attackers exploited in the wild. The flaw involves how LSWS handles Apache configuration. An attacker who first compromises a customer website can use it to bypass suEXEC and escape the CloudLinux CageFS environment that isolates hosting accounts.

After leaving CageFS, the attacker can reach root-level access on the server. That changes a single website compromise into a server-wide incident, putting other customer accounts and server credentials at risk.

There is no CVE assigned to this issue yet. The affected product is LiteSpeed Web Server Enterprise. OpenLiteSpeed is not affected.

What happened on the affected shared server

Hostinger disclosed the incident in its November 2026 incident report. According to the report, an attacker first entered through a vulnerable content management system on a customer website on November 5, 2026. The attacker then found and exploited the LiteSpeed vulnerability over the following days.

The incident affected one shared hosting server in Phoenix between November 5 and November 9. The attacker ran code or read credentials on about 400 accounts. Hostinger reported no evidence that its internal management systems, backup system, or Hostinger account login systems were compromised.

LiteSpeed released the fix on November 10, 2026.

Who needs to patch

Check every server running LiteSpeed Web Server Enterprise. This includes shared hosting nodes where CloudLinux CageFS provides per-account isolation.

The fixed versions are:

• LiteSpeed Web Server 6.3.7 Build 9 or later
• LiteSpeed Web Server 6.4.0 RC2 Build 7 or later

Build 8 is not sufficient. The version string can still show 6.3.7 after the update, so checking only the displayed version is not enough. Verify the build number in:

/usr/local/lsws/BUILD

The value must be 9 or higher for the 6.3.7 branch. If you are using the 6.4.0 release candidate branch, verify that the build is 7 or higher.

Do not treat an unchanged 6.3.7 version string as proof that the patch failed. Check the build file directly, then confirm that the running service uses the updated installation.

Patch safely

Start by inventorying your hosting fleet and identifying every node running LiteSpeed Web Server Enterprise. Include servers managed through different control panels or deployment processes, since a partial update leaves unpatched nodes exposed.

For each server:

1. Check /usr/local/lsws/BUILD.
2. Confirm that the build meets the fixed version for the branch you run.
3. Apply the LiteSpeed update using your normal, controlled package or deployment process.
4. Restart or reload LiteSpeed as required by your update procedure.
5. Check the build file again after the update.
6. Record the server, installed branch, build number, update time, and verification result.

If the server reports build 8, continue treating it as vulnerable. If you cannot verify the build, handle the node as unpatched until you can.

OpenLiteSpeed does not require remediation for this issue, based on the available details.

Investigate before and after patching

Patching closes the LiteSpeed vulnerability. It does not show whether an attacker already used it. If a server was running an affected build while customer websites were compromised, investigate it as a potential privilege-escalation incident.

Review the period beginning November 5, 2026, or the period when the vulnerable build was active on your infrastructure. Focus on:

• Websites with known CMS vulnerabilities or unusual file changes
• Processes running outside the expected account context
• Attempts to execute commands through Apache or LiteSpeed configuration files
• Unexpected root processes, shells, cron entries, systemd changes, or startup files
• New binaries, scripts, SSH keys, and administrator accounts
• Reads of configuration files containing database credentials or access tokens
• Outbound connections from web server processes
• Changes to CageFS, suEXEC, Apache, LiteSpeed, or control panel configuration
• Malware, web shells, and backdoors in customer directories

Preserve logs and other evidence before removing suspicious files where possible. If you confirm or strongly suspect root access, isolate the server from production traffic, rotate credentials that may have been exposed, and rebuild or restore it according to your incident response plan. A simple service restart is not enough after a root-level compromise.

Check affected customer accounts as well as the host itself. An attacker who reached root could access data beyond the account where the initial website compromise occurred.

Add layers around the patch

This is a patch-only LiteSpeed issue. A web application firewall or malware scanner cannot correct the vulnerable LSWS behavior. The permanent fix is to run a fixed build.

Layered controls still reduce the chance that an attacker reaches the vulnerable path and can help you find activity sooner:

Reduce the initial website compromise

Keep customer CMS installations, plugins, themes, and server-side applications updated. Add WAF rules for common web attacks, protect login pages against brute-force attempts, and remove unused applications and extensions. Limit administrative access to hosting panels and server management interfaces.

Detect malware and backdoors

Scan customer directories for web shells, injected code, modified system files, and persistence mechanisms. Schedule recurring scans and trigger additional scans after a suspicious file change or account alert.

BitNinja can provide layered server protection through malware and backdoor detection, alongside controls that help reduce common initial footholds such as malicious web requests and brute-force activity. It does not claim to block this specific LiteSpeed vulnerability. Keeping LSWS patched remains necessary.

Monitor for privilege escalation

Alert on unexpected processes, changes in process ownership, shells launched by web server workers, and commands that should not run from a customer account. Monitor changes to server configuration, scheduled tasks, startup locations, and privileged files.

A useful alert should include the account, parent process, command, user context, and time. Those details help separate normal hosting activity from an account escaping its expected boundary.

Prepare an incident response path

Know which team can isolate a node, rotate credentials, preserve evidence, restore customer data, and communicate with affected account owners. Keep clean backups available and verify that restoration procedures work before an incident occurs.

Document the exact LSWS branch and build on every node. During an active vulnerability, that inventory tells you which systems require urgent action and which ones need deeper investigation.

The operational lesson for hosting providers

CageFS isolation limits the impact of many account-level compromises, but it depends on the surrounding software stack. When a web server flaw lets code cross that boundary, the provider needs both a fixed server build and visibility into activity that follows the initial compromise.

Patch every affected LSWS Enterprise node to the correct build, verify /usr/local/lsws/BUILD, and investigate servers that were exposed before the update. Keep account isolation, WAF coverage, brute-force protection, malware scanning, and process monitoring working together so one vulnerable website is less likely to become a server-wide incident.