LiteSpeed and LSAPI: Updating PHP

In short: A LiteSpeed PHP update concerns the lsphp packages through which LiteSpeed runs PHP via LSAPI. After the update, all lsphp processes must restart, and with LiteSpeed that does not always happen automatically with the web server. Check the package state and process start time before you classify the server as patched.

LiteSpeed, LSAPI and lsphp in brief

LiteSpeed Web Server and its free variant OpenLiteSpeed do not run PHP as a module but through their own interface called LSAPI. The PHP programs for this are called lsphp and usually come from dedicated package sources, per version such as lsphp83 or lsphp84. On panels such as cPanel, Plesk or CyberPanel, the panel's own PHP packages may also be involved.

PHP2Shell covers the vulnerabilities CVE-2026-109618 and CVE-2026-109619 in PHP itself, each rated CVSS v4.0 9.2. The PHP project explicitly lists LiteSpeed among the affected operating modes. The fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

LiteSpeed PHP update: record the inventory

First find out which lsphp versions are installed and which of them are in use. The following commands only read. Paths and package names are examples and depend on the installation and distribution.

# Installed lsphp versions (typical path)
ls -d /usr/local/lsws/lsphp*/ 2>/dev/null
for p in /usr/local/lsws/lsphp*/bin/lsphp; do echo "$p"; "$p" -v | head -1; done

# Package state (examples)
rpm -qa | grep -E '^lsphp[0-9]+' | sort
dpkg -l | grep -E 'lsphp[0-9]+'

# Running lsphp processes with start time
ps -eo pid,lstart,user,cmd | grep lsphp | grep -v grep

Match the list against the configuration: which virtual host uses which External App Handler? In the LiteSpeed interface you will find this under Server Configuration and the settings of the virtual hosts. You should still update or remove versions with no assignment.

Taking backports and package sources into account

If lsphp comes from a third-party source, its package state decides. If a panel or a distribution supplies PHP, its statement applies. In both cases a correction may be delivered as a backport without the displayed version number changing. So check the package provider's change notes and, if in doubt, have the state confirmed. The version number alone is no proof.

Restart: what matters with LiteSpeed

LiteSpeed can run PHP in what is called detached mode. In this mode, lsphp processes keep running independently of the web server so that websites respond faster after a web server restart. For a security update this is a pitfall: the web server has been restarted, but old PHP processes with the vulnerable code stay active.

# Restart the web server (path as an example)
/usr/local/lsws/bin/lswsctrl restart

# Then verify: are all lsphp processes newer than the update?
ps -eo pid,lstart,user,cmd | grep lsphp | grep -v grep

If an lsphp process shows a start time before the update, end it deliberately. LiteSpeed starts a new process with the updated code on the next request. Plan this step outside peak load times, because the first request per website may take somewhat longer afterwards.

Interim measures until the patch arrives

If no fixed package is available yet for an lsphp version, php.net recommends interim measures. They do not offer complete protection. Set the values in the php.ini of the respective lsphp version or in the server configuration, not in .user.ini and not via ini_set().

; php.ini of the affected lsphp version (path depends on the installation)
session.upload_progress.enabled = 0
post_max_size = 8M
upload_max_filesize = 6M

With an upload function, php.net gives post_max_size = 32M, with upload_max_filesize below it. On PHP 8.5, fatal_error_backtraces=0 is added. You set memory limits through cgroups, on CloudLinux for example through the limits provided there, not through RLIMIT_AS or RLIMIT_DATA. After that, all lsphp processes are restarted again. Further details: Immediate measures without a patch. The BSI recommends taking a web server off the network temporarily if the update is not possible immediately.

After the update

A patch closes the vulnerability, but it does not remove malware that has already been planted and does not prove that nothing happened beforehand. Keep the access logs from 20 October 2026 onward and check the websites for new PHP files in upload directories, foreign administrator accounts and unusual outgoing connections. Our security monitoring offers support with ongoing monitoring. On cPanel servers with LiteSpeed, it is also worth a look at cPanel and WHM.

Many LiteSpeed servers run under a hosting panel such as cPanel, Plesk, DirectAdmin or CyberPanel. The panel then determines where lsphp comes from and how updates are applied. In that case, carry out updates through the panel or its package sources and do not install in parallel from a second source, otherwise it becomes hard to trace which version is actually running. Also record which website runs with which lsphp version. On servers with many customer accounts, this list is the basis for informing account holders in a targeted way and for spot-checking after the update that the websites run without errors. Websites that require a PHP version that is no longer supported belong on a separate list, because no official update is coming for them.

How does PHP SOS help?

• We record all lsphp versions, package sources and handler assignments on your server.
• Through the PHP patch service, we update, end all old lsphp processes and document the evidence.
• Where no package is available yet, we set the interim values server-wide and limit memory via cgroup.
• We check the websites for traces of an attack and preserve the logs.

Frequently asked questions

Sources

• php.net: Security announcements
• PHP 8 ChangeLog
• php.net: Supported versions
• BSI (German Federal Office for Information Security)