PHP2Shell on CloudLinux and TuxCare: alt-php and Extended Support

As of 23 October 2026, CloudLinux says fixed packages for PHP2Shell (CVE-2026-109618 and CVE-2026-109619) are in its stable repositories for every PHP family it ships: alt-php on CloudLinux 7, 8 and 9, ea-php52 through ea-php85 for cPanel, and the system PHP packages. On CloudLinux 10, most alt-php versions come from the TuxCare ELS repository instead. CloudLinux 6 is "not confirmed yet."

The direct answer: if you run a CloudLinux server, do a regular package update (not a security-only one), restart PHP, and check the package changelog or version as shown below. A version number that looks old, such as 8.4.26-2, can still be fixed. If you are a customer on a CloudLinux shared host, your host does this for you; pick a supported PHP version in your control panel and ask the host to confirm the build serving your site. Our shared responsibility model guide explains where that line sits.

TuxCare is CloudLinux's extended-support brand. Its own website could not be read when this guide was written, so the TuxCare details here come from CloudLinux's post and TuxCare's CVE tracker.

The Three Kinds of PHP on a CloudLinux Server

A CloudLinux server can run several PHP builds side by side, from different package families. Patching one does not patch the others.

CloudLinux's advice applies to all three: "update each one that serves websites, then restart PHP-FPM or the web server."

Fixed Packages, as of 23 October 2026

From the CloudLinux PHP2Shell post (summary last updated 23 October 2026, 08:40 UTC, with a status entry at 13:10 UTC):

CloudLinux has since added builds with php.net's own numbers (alt-php82 8.2.35-1 to alt-php85 8.5.12-1, and matching ea-php builds on 23 October). Earlier fixed builds, such as alt-php85 8.5.11-5, "are already protected."

A note on timing: CloudLinux corrected an early 21 October update (the first alt-php fixes had gone to the TuxCare ELS repository) and reported the stable alt-php release complete at 01:19 UTC on 22 October. If you patched in the first hours, run the update again.

How to Update CloudLinux PHP

These are CloudLinux's documented commands. Run them as root, and use the line for your CloudLinux version.

ea-php (cPanel servers)

yum clean all && yum update "ea-php*" (CloudLinux 7)
dnf clean all && dnf upgrade "ea-php*" (CloudLinux 8, 9 and 10)
/scripts/restartsrv_httpd
/scripts/restartsrv_apache_php_fpm

cPanel's own side of this, including EasyApache 4 releases and the panel's internal PHP, is in our cPanel and PHP2Shell guide.

alt-php

yum clean all && yum update "alt-php*" (CloudLinux 7)
dnf clean all && dnf upgrade "alt-php*" (CloudLinux 8, 9 and 10)
apt-get update && apt-get upgrade (CloudLinux OS for Ubuntu)

Then restart your PHP services: Apache, PHP-FPM or LiteSpeed. If you added the ELS alt-php repository on CloudLinux 7, 8 or 9 as a stopgap on 21 October, CloudLinux says you can now disable it and update again:

yum-config-manager --disable php-els (CloudLinux 7)
dnf config-manager --set-disabled php-els (CloudLinux 8 and 9)

System PHP, and if the update finds nothing

A regular package update installs the fixed system PHP; restart PHP-FPM or the web server afterward. If any update finds nothing to install, CloudLinux says to check rpm -q cloudlinux-release, update that package if it is old (dnf update cloudlinux-release && dnf clean all), and try again.

How to Verify the Fix

This is where most people get tripped up. CloudLinux puts it plainly: "Most of our packages carry the fix as a backport, so their version numbers stay below PHP's: the fixed ea-php84, for example, is 8.4.26-2 and not 8.4.27. A scanner that compares version numbers may flag them."

So the check depends on the package:

• Backported alt-php and ea-php builds: look for the CVE IDs in the changelog.
  rpm -q --changelog alt-php85-common | grep -E 'CVE-2026-(109618|109619)'
  rpm -q --changelog ea-php84-php-cli | grep -E 'CVE-2026-(109618|109619)'
  Replace 85 or 84 with each version you have installed. Any output means the fix is in.
• Rebased native PHP (PHP 8.3 on CloudLinux 10, PHP 8.2 and 8.3 on CloudLinux 9, PHP 8.2 on CloudLinux 8): the changelog names no CVE, so a grep returns nothing even on a fixed build. Check the version with rpm -q php-cli. It should be 8.2.35 or 8.3.36 or later.
• Other native versions: rpm -q --changelog php-cli | grep -E 'CVE-2026-(109618|109619)'
• php.net-numbered builds (alt-php82 8.2.35-1 and up, ea-php82 8.2.35-1 and up): the version itself confirms the fix. CloudLinux gives rpm -q ea-php84-php-cli as an example (on Ubuntu: dpkg -l ea-php84-php-cli).

A package check shows what is installed, not what serves pages. Our guide on how to check your PHP version shows how to see the version a site actually runs, and the PHP2Shell version lookup tells you whether a given version or package build is a fixed one.

Restart Every PHP Process

PHP processes that were already running keep the old code until they are replaced. LiteSpeed needs special care: since version 5.3, its PHP runs detached and does not restart when the web server does. On cPanel, LiteSpeed uses the ea-php or alt-php packages above, but the PHP restart is LiteSpeed's. Our LiteSpeed and PHP2Shell guide covers it, and our guide to restarting PHP workers has the commands for every setup and how to confirm the restart happened.

TuxCare Extended Lifecycle Support: What Can Be Confirmed

TuxCare sells extended lifecycle support (ELS) for systems and runtimes past their official end of life. That matters here because PHP 8.1 and older get no new release from the PHP project, only minimal source-code backports for 7.4, 8.0 and 8.1. Here is what we could and could not confirm on 23 October 2026:

• Confirmed through CloudLinux's post: TuxCare ELS fixed packages "are released for alt-php, the distribution's own PHP, and PHP for Windows." CloudLinux 7's system PHP 5.4 fix is a TuxCare ELS package.
• Confirmed on TuxCare's tracker: the TuxCare CVE page for CVE-2026-109618 ("Updated on 21 Oct 2026") lists the products it tracks for this CVE, including CentOS 7 ELS, RHEL 7 ELS, Oracle Linux 7 ELS, Debian 10 and 11 ELS, Ubuntu 16.04 ELS, Amazon Linux 2 ELS and Windows.
• Not confirmed: the fixed package version for each of those products. The tracker's fix table loads by script and could not be read, and TuxCare's blog and documentation returned an access block.

Being on the affected list is not the same as being fixed. Ask TuxCare for the fixed package version for your product, then check the changelog on your server. Plesk, for what it's worth, recommends paid TuxCare ELS for PHP 5.6, 7.2 and 7.3 on Plesk servers.

Extended support buys time, not a plan. Even PHP 8.2 reaches end of life on 31 December 2026. Our security patching best practices guide covers planning upgrades.

Imunify360 Is a Virtual Patch, Not a Fix

Many CloudLinux servers also run Imunify360. With its web application firewall (WAF) enabled, it received rulesets 8.83 to 8.88 automatically, which block the publicly circulating exploit requests and tool. CloudLinux calls this "a virtual patch" that leaves "the vulnerable PHP code" as it is, and says "No rule blocks the out-of-memory path of CVE-2026-109618 yet." With the WAF disabled, or with ImunifyAV, there is "No coverage from these rulesets." On a cPanel server with Apache, cat /etc/apache2/conf.d/modsec_vendor_configs/imunify360-full-apache/VERSION shows the ruleset, and imunify360-agent update --force modsec-rules updates it if it is older than 8.88. Treat it as a layer on top of the PHP update.

If You Can't Update Yet

For CloudLinux 6, or any build you can't update today, CloudLinux points to PHP's interim settings. The main one for CVE-2026-109619 is session.upload_progress.enabled=0, set in php.ini, an FPM pool or the server configuration, followed by a restart of every worker. CloudLinux repeats PHP's warning: "Do not rely on ini_set() or FPM .user.ini for this."

On a PHP Selector server, set it at the server level, where an account can't override it. PHP also recommends keeping upload progress off after patching if you don't use it, because a separate, lower-risk issue (CVE-2026-115560) affects even fixed releases until PHP's next regular release. Every setting, and what each one can break, is in our PHP2Shell interim mitigations guide. None of them is a fix.

Conclusion

As of 23 October 2026, CloudLinux has fixed packages in stable for ea-php, alt-php on CloudLinux 7 to 9 and CloudLinux OS for Ubuntu, and its system PHP, with CloudLinux 10 alt-php coming from the TuxCare ELS repository and CloudLinux 6 still unconfirmed. Run a regular update, restart every PHP service, and verify with the changelog or, for rebased builds, the version. For TuxCare ELS, get the fixed version from TuxCare and check it on the server. If you manage a fleet of CloudLinux servers and want help verifying each one, our emergency PHP patching team can do it with you. Every PHP2Shell guide is in our PHP2Shell Resource Center.

Frequently Asked Questions