Skip to main content
Sign in

CloudLinux Knowledge Base

  1. CloudLinux
  2. CloudLinux OS
  3. CageFS

CloudLinux 8: CageFS 7.6.40 breaks lsphp spawning on LiteSpeed Enterprise + Plesk (HTTP 503 outage)

Taha Ali
  • Updated

Issue

After CloudLinux packages (lve, liblve, alt-pylve, cagefs, cagefs-safebin, lve-utils, and related packages) are updated from the ".6" release set to the ".7/.40/.36" set on a CloudLinux 8 server running Plesk and LiteSpeed Web Server Enterprise, LiteSpeed can no longer spawn lsphp processes for any hosted domain. Every request to every site returns HTTP 503 Service Unavailable, while the Plesk panel itself (sw-cp-server) remains reachable, since it doesn't use the lsphp/CageFS/LVE spawn path.

Typical symptoms:

  • ps aux | grep lsphp returns zero running processes, regardless of traffic.
  • The LiteSpeed error log repeatedly logs entries such as:
  [ERROR] [uds://usr/local/lsws/extapp-sock/APVH_<domain>_Suphp.sock] Stuck in STARTING state for 33-40 seconds, something is wrong, retry!

or, with LSWS debug logging enabled:

  connection to [uds://...Suphp.sock] ... error: No such file or directory!
  Max retries has been reached, 503!
  • /var/log/messages shows cagefs-liblve[PID]: Act like CageFS is disabled (unable to acquire lock for user <username> uid <uid>).
  • The failure survives a full reboot and persists even with CageFS and LVE both explicitly disabled — it is not a transient, self-healing condition.
  • Manually invoking lsphp -v (without arguments) works fine as both root and an unprivileged hosting user, so the PHP binary itself is healthy.

This affects Plesk + LiteSpeed Enterprise servers specifically; cPanel servers use a different wrapper script and are not affected.

Environment

  • CloudLinux 8
  • Plesk Obsidian 
  • LiteSpeed Web Server Enterprise
  • CloudLinux Selector (suEXEC via cloudlinux_wrapper) 
  • Affected package versions (from the cloudlinux-rollout-19/21 channels):
    • cagefs 7.6.40-1
    • cagefs-safebin 7.6.40-1
    • lve 2.2-7
    • liblve 2.2-7
    • alt-pylve 2.2-7
    • lve-utils 6.6.36-1
    • lvemanager 7.11.43-1
    • cloudlinux-venv 1.0.11-1
  • Last known-good versions: cagefs/cagefs-safebin 7.6.38-1, lve/liblve/alt-pylve 2.2-6, lve-utils 6.6.35-1, cloudlinux-venv 1.0.10-1

Solution

A corrected build (cagefs 7.6.41-1) that resolves this issue has been prepared and is pending release. Until it is available, apply the following workaround:

  1. Downgrade the CageFS packages to the last known-good release:
# dnf downgrade cagefs-7.6.38-1 cagefs-safebin-7.6.38-1
# systemctl restart lsws
  1. Confirm lsphp processes are spawning again (ps aux | grep lsphp) and that hosted domains return HTTP 200.
  2. If any domain still returns 503 after the CageFS-only downgrade, downgrade the full package set that was updated together, then reboot:
dnf downgrade lve liblve alt-pylve lve-utils lvemanager cloudlinux-venv cagefs cagefs-safebin
  1. Prevent an unattended update (including one triggered indirectly by Imunify360's own package updates) from reinstalling the affected versions:
dnf versionlock add 'cagefs-7.6.40*' 'cagefs-safebin-7.6.40*'

Add matching entries for the full package set if step 3 was needed. As a redundant safeguard, add a matching exclude= line in /etc/dnf/dnf.conf. 5. Keep the versionlock in place until cagefs 7.6.41-1 is released, then remove the lock and update normally.

Cause

The regression was introduced by a security-hardening change first shipped in cagefs 7.6.40-1, which added argv sanitization to cloudlinux_wrapper (the script CageFS's post-install scriptlet installs into Plesk's CGI wrapper path). The change rejects any forwarded argument that starts with -, intended as defense-in-depth against CGI argv-injection attacks on lsphp (the CVE-2012-1823 class of issues, e.g. injecting -d auto_prepend_file=...).

LiteSpeed Web Server Enterprise legitimately passes flag-style startup arguments (such as -b uds://… and sometimes -n) when it spawns lsphp for Plesk's PHP Selector/suEXEC path. The new guard rejects those arguments and the wrapper exits before it can hand off to lsphp, so the per-user LSAPI socket is never created. Because LiteSpeed discards stderr from detached processes, the failure is silent beyond the resulting Stuck in STARTING / 503 pattern. The check is independent of whether CageFS or LVE containment is actually enabled, which is why the failure persists even with both disabled and survives a reboot.

The fix removes this argv guard from the LiteSpeed/Plesk wrapper while keeping it in place for the separate CGI wrapper, where the original CGI-argv attack surface actually applies. It is scheduled to ship in cagefs 7.6.41-1 (internally tracked as CLOS-5712).

Useful Links

Comments

0 comments

Please sign in to leave a comment.

Related articles