How to update PHP on CloudLinux

Five steps, run as root

Patch every PHP family on the server

These are CloudLinux's own commands, gathered into one order. Sites stay on the version each account has chosen; nothing here changes which PHP a site uses.

1. 1

   List what is installed

   # alt-php: one -common package per installed version
   rpm -qa 'alt-php*-common' | sort
   
   # ea-php, on servers that run cPanel
   rpm -qa 'ea-php*-php-cli' | sort
   
   # The versions PHP Selector offers, with the path to each binary
   selectorctl --list

   A hosting server can hold many alt-php versions at once, and each one that can serve a site needs the fix. Keep this list: it is the checklist for step 5.

2. 2

   Make sure cloudlinux-release is current

   rpm -q cloudlinux-release
   
   # Older than CloudLinux's current list? Update it, then clear the cache
   dnf update cloudlinux-release && dnf clean all     # CloudLinux OS 8, 9, 10
   yum update cloudlinux-release && yum clean all     # CloudLinux OS 7

   CloudLinux found servers that could not see the fixed packages because this package was out of date. On 22 October 2026 it listed the current versions as 7.9-2.17 for CloudLinux OS 7, 8.10-16 for 8, 9.8-3 for 9 and 10-5 for 10.

3. 3

   Run a regular update, not a security-only one

   # CloudLinux OS 8, 9 and 10
   dnf clean all
   dnf upgrade 'alt-php*'
   dnf upgrade 'ea-php*'        # cPanel servers
   
   # CloudLinux OS 7
   yum clean all
   yum update 'alt-php*' 'ea-php*'
   
   # CloudLinux OS for Ubuntu 22.04
   apt-get update && apt-get upgrade

   Native php packages arrive with an ordinary full dnf upgrade (or yum update on CloudLinux OS 7). Avoid --security here: CloudLinux had not published advisory metadata for these packages, so a security-only run passes over them.

4. 4

   Restart PHP so the new build is the one serving

   # cPanel: Apache first, then cPanel's PHP-FPM service
   /scripts/restartsrv_httpd
   /scripts/restartsrv_apache_php_fpm
   
   # Any lsphp still running from before the update?
   ps -C lsphp -o pid,user,lstart,args

   The lstart column shows when each lsphp process began. Anything older than the update is still running the vulnerable code: see restarting lsphp below. On LiteSpeed Web Server, PHP is detached and needs its own restart, covered in the LiteSpeed guide.

5. 5

   Confirm each package carries the fix

   # Backported builds: the newest changelog entries name the CVEs
   rpm -q --changelog alt-php74-common | grep -E 'CVE-2026-(109618|109619)'
   rpm -q --changelog ea-php81-php-cli | grep -E 'CVE-2026-(109618|109619)'
   
   # Renumbered alt-php82 to alt-php85: read the version instead
   rpm -q alt-php85-common

   To check every alt-php version in one pass, count the CVE mentions in each changelog. A zero is fine only on a renumbered alt-php82 to alt-php85 build at or above 8.2.35-1, 8.3.36-1, 8.4.27-1 or 8.5.12-1; anywhere else it means that version is still unpatched.

   for p in $(rpm -qa --qf '%{NAME}\n' 'alt-php*-common' | sort); do
     printf '%s  ' "$p"
     rpm -q --changelog "$p" | grep -c -E 'CVE-2026-(109618|109619)'
   done

mod_lsapi and lsphp

Restarting lsphp under Apache

CloudLinux's mod_lsapi PRO is an Apache module that passes PHP requests to an lsphp parent process, which forks children to run them. The PHP2Shell flaw that leaves stale state in a worker makes this matter: a long-lived lsphp parent keeps old code and old memory until it is replaced.

Check whether an Apache restart reaches lsphp

# Does Apache keep lsphp alive across restarts? "Off" means it does
grep -rh 'lsapi_terminate_backends_on_exit\|lsapi_criu' /etc/apache2 /etc/httpd 2>/dev/null

lsapi_terminate_backends_on_exit is On by default, which stops lsphp whenever Apache restarts. Some servers set it Off to keep the opcode cache warm, and CloudLinux's documentation is explicit that lsphp then survives the restart. On those servers, use the cold restart CloudLinux's troubleshooting notes give:

service httpd stop; sleep 2; killall lsphp; service httpd start

Servers that use PHP-FPM rather than mod_lsapi follow the PHP-FPM restart guide; CloudLinux's documentation asks for PHP-FPM to be disabled wherever mod_lsapi is the handler.

The ALT-ELS repositories

Where alt-php updates come from now

CloudLinux is moving alt-php delivery to one repository scheme, called ALT-ELS, shared across its products and served from repo.alt.tuxcare.com. CloudLinux OS 10 already takes alt-php only from there, which is why most of its PHP2Shell fixes were listed in the ELS alt-php repository rather than in stable.

• Licence. CloudLinux's documentation says access depends on a valid licence and a registered machine. If the licence lapses, the server stops receiving PHP Selector updates.
• Tokens. On CloudLinux OS 10 the access token is linked into dnf's variables automatically, for PHP as /etc/dnf/vars/phpelstoken.
• CloudLinux OS 7, 8 and 9. Some servers added the repository (php-els) on 21 October to get fixed alt-php early. CloudLinux's last update asks them to keep it, since these releases will move to the same scheme.

# The machine must be registered with CLN for the repository to answer
ls /etc/sysconfig/rhn/jwt.token

# Switch the ELS alt-php repository back on if it was disabled
dnf config-manager --set-enabled php-els     # CloudLinux OS 8, 9
yum-config-manager --enable php-els          # CloudLinux OS 7

Troubleshooting

When the CloudLinux update stalls

For ea-php on servers without CloudLinux, see updating PHP in cPanel. Other distributions are covered from the Linux overview, including Ubuntu and Debian, containers in the Docker guide, and every other setup in the main update guide.