Author: Core

On 21 October 2026 the PHP project released 8.5.12, 8.4.27, 8.3.36 and 8.2.35, fixing two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619 (CVSS v4.0 9.2). Both allow unauthenticated remote code execution, and the vulnerable component is not a plugin but the interpreter itself: every PHP site, from WordPress to custom code.

On a regular server the story is short: update the package and restart PHP. On hosting servers with ispmanager and CloudLinux it turned out to be more interesting. Over one night and morning we patched all our servers and stepped on almost every rake that neither the PHP advisory nor the panel documentation mentions.

This is not a retelling of the advisory but a list of what didn’t go by the book and how we solved it. If you run a server with ispmanager, especially on CloudLinux, check each point on your own system: some of these problems stay invisible until you look in the right place.

Temporary measures before the patches

Until packages are available you cannot fully close the vulnerabilities, only cut off the known attack paths. The public exploits that appeared before the release used the file upload progress handler, which runs on any multipart/form-data request, even if the site has no upload form at all.

We did two things:

1. Disabled session.upload_progress.enabled in all PHP versions. This is the PHP project’s own recommendation; almost nobody uses the feature, and sites are not affected. Important: the value must be set in php.ini or in the pool configuration, not via ini_set() or .user.ini, otherwise it applies too late.
2. Blocked multipart at the nginx level for all sites. In ispmanager every vhost includes /etc/nginx/vhosts-includes/*.conf, so a single file covers the whole server:

if ($http_content_type ~* "multipart") {
    return 403;
}

The price of the second measure: file uploads through forms, webmail attachments and imports in phpMyAdmin stop working. So this is a measure for hours, not days.

Two places that are easy to miss:

• The default server in /etc/nginx/nginx.conf. It catches requests by IP or with an unknown Host and, in ispmanager, proxies them to Apache, but it does not include vhosts-includes. Without a separate include there, an attack by IP bypasses the block.
• Apache on a public address. If Apache listens on a public IP rather than 127.0.0.1, a request can be sent straight to it, bypassing nginx. Check: ss -ltnp | grep httpd.

The CageFS trap: the panel setting never reaches the sites

During the day we disabled session.upload_progress.enabled the standard way: “Web server settings → PHP → version → settings”. The panel showed the value as saved. In the evening, a check from inside the CageFS cage showed it was still enabled for the sites.

The reason is how alt-php works on CloudLinux:

• ispmanager wrote the value into /opt/alt/phpXX/etc/php.d.all/session.ini, the ini file of the session extension;
• in alt-php the session extension is built in and is not loaded through PHP Selector, so nobody inside the cage reads that ini file;
• inside the cage PHP reads the main /opt/alt/phpXX/etc/php.ini and the user’s alt_php.ini from /opt/alt/phpXX/link/conf, which is a different directory from what root sees.

Hence the main lesson: check PHP settings as the user inside the cage, not as root:

su -s /bin/bash -c "/opt/alt/php83/usr/bin/php -r 'var_dump(ini_get(\"session.upload_progress.enabled\"));'" CLIENT_LOGIN

What worked:

1. Append the directive to the end of the php.ini each version actually loads (the path is shown by php --ini, line Loaded Configuration File).
2. Run cagefsctl --rebuild-alt-php-ini to rebuild the users’ alt_php.ini files.
3. Run cagefsctl --update: the native PHP inside the cage has its own copy of /etc/php.ini in the CageFS skeleton, and without updating the skeleton the change never reaches the sites.
4. Don’t forget the per-site php.ini files for CGI mode: ispmanager keeps them in /var/www/USER/data/php-bin*/php.ini.
5. Restart httpd and FPM.

One more detail: that same night at 03:37 something rebuilt the php.ini of every alt-php version from a template. If your change lives only in php.ini, back it up with a cron job that checks and restores the line until the patches arrive. We did exactly that, and cron did restore it several times, for example after the alt-php packages were updated.

The multipart block breaks the panel login

A couple of hours after the block went in, a client wrote that they could not log in to the panel: the login request got a 403 and the interface showed a loading spinner forever. Nobody had blocked the client’s IP.

The ispmanager panel runs on its own web server, ihttpd, on port 1500, and when you log in directly on that port nginx is indeed not involved. But if the nginx_proxy module is enabled, the panel is also reachable over 443 at https://HOST/ispmgr, and the login form is sent as multipart/form-data. Our block answered 403 in nginx, and the panel frontend cannot display that error.

The module is included only in the vhost of the panel host (/etc/nginx/modules-includes/nginx_proxy/), and all its paths go to ihttpd, not to PHP. So it is safe to make an exception for the combination of host and path:

set $cve_mp 0;
if ($http_content_type ~* "multipart") { set $cve_mp 1; }
set $cve_hu "$host:$uri";
if ($cve_hu ~* "^panel\.example\.com:/(ispmgr|mancgi|manimg|long|shell|notify)(/|$)") { set $cve_mp 0; }
if ($cve_mp = 1) { return 403; }

An exception by path alone, without the host, would be a mistake: a request to client-site/ispmgr would go to Apache, WordPress would rewrite it to index.php, and PHP would parse the multipart body. On the panel host this path is guaranteed to go to ihttpd.

Take the list of paths from the module itself (grep location /etc/nginx/modules-includes/nginx_proxy/*.conf), not from memory. And don’t test right after reloading nginx: the first requests may still be served by an old worker with the old configuration.

The forgotten Roundcube and phpMyAdmin

When the alt-php patches came out, we updated the packages and removed the block. Only then did we remember that webmail and phpMyAdmin in ispmanager run not on the PHP version you selected for the sites. Updating alt-php does not touch them.

Both applications are included through vhosts-includes, which means they are reachable on every domain on the server (/roundcube, /webmail, /phpmyadmin or a path with a random prefix). Which PHP runs them is shown by fastcgi_pass in these files:

grep -E 'location|fastcgi_pass' /etc/nginx/vhosts-includes/*roundcube*.conf /etc/nginx/vhosts-includes/*phpmyadmin*.conf

We found several variants across our servers:

Application	Via nginx	Via Apache
Roundcube /roundcube	native PHP-FPM (php-fpm.apache.sock) or isp-php74	isp-php74 via its own socket
Roundcube /webmail	native PHP-FPM	mod_php
phpMyAdmin	native PHP-FPM	mod_php

The second column matters as much as the first. Apache receives these requests in two cases:

• a request by IP or with an unknown Host goes through the nginx default server straight to Apache, where Alias /webmail and /phpmyadmin are global;
• the nginx configuration for /webmail and /phpmyadmin has error_page 404 @apache and error_page 502 = @apache. A URL with PATH_INFO such as /webmail/index.php/x does not match location ~ \.php$, gets a 404 and goes to Apache, where mod_php executes it.

On one of the servers the native PHP was 5.4 from CentOS 7, which will never receive fixes. While we were moving these applications to alt-php, the multipart block stayed only on their paths, and the sites already worked without restrictions:

if ($uri !~* "^/(roundcube|webmail|phpmyadmin)(/|$)") { set $cve_mp 0; }

During that time clients could not attach files in webmail, and they noticed almost immediately.

Why the version number doesn’t change on CloudLinux

CloudLinux released fixes for all alt-php branches at once, from 5.4 to 8.5, but not as 8.3.36 or 8.4.27. They are new builds of the existing versions: alt-php83-8.3.35-6, alt-php84-8.4.26-5, alt-php85-8.5.11-5 and so on. The patch is applied to the installed version, and only the package release number goes up.

So check scripts that compare PHP_VERSION with 8.3.36 will keep reporting “vulnerable” after the update. And clients who look at the panel will see the same numbers and ask why nothing was updated. There are two reliable indicators.

The package changelog. For the old branches CloudLinux additionally removed the upload progress handler entirely:

for p in $(rpm -qa --qf '%{NAME}\n' 'alt-php[0-9]*' | grep -E '^alt-php(5[4-9]|[78][0-9])$' | sort -V); do
  printf '%-10s %-16s ' $p "$(rpm -q --qf '%{VERSION}-%{RELEASE}' $p)"
  rpm -q --changelog $p | head -10 | grep -c 'CVE-2026-10961[89]'
done

Build Date in phpinfo(). The fixed builds show 21 October 2026, the previous ones earlier dates. This is what you can tell clients: anyone can check it without server access.

Native PHP has the same story from the other side. On RHEL 9 and its rebuilds the fixed 8.0 version is php-8.0.30-8.el9_8.1 (Red Hat advisory RHSA-2026:87151), and in the changelog the CVE numbers ended up attached to the last item of the list, which has a completely different description. Without the advisory it is easy to mistake this for a routine update.

The ispmanager packages (isp-phpXX) have a template changelog with a single 2019 entry. The indicators there are indirect: the build number (for us 1781 for 8.2-8.5, 1782 for 7.4, 1786 for 7.1) and a Build Date of 22 October.

Pitfalls of the update itself

dnf --best --allowerasing on an ispmanager server. On CloudLinux 9, dnf update printed a long list of conflicts: the repository contains native PHP 8.3.36 from a module stream, and dnf considers it the best candidate for the installed 8.0. But the ispmanager Apache module (isp-httpd-mod_php) strictly requires PHP 8.0.x, and coremanager-pkg-php and ispmanager-pkg-php, that is the panel itself, depend on it. The dnf hint to add --best --allowerasing is dangerous here: it would remove the panel packages. The conflict is harmless, and dnf ends with Nothing to do. To silence it until the 8.0 build arrives: dnf update --exclude='php,php-*'.

ispmanager has its own Apache PHP module. It is loaded from modules/isp-libphp8.so and belongs to the isp-httpd-mod_php package, not to the system php package. The fixes for these CVEs live in the PHP core, that is inside the module itself, and updating the php package does not change it. Check:

grep -rhE 'LoadModule\s+php' /etc/httpd/conf.modules.d/ /etc/httpd/conf.d/
rpm -qf /etc/httpd/modules/isp-libphp8.so
strings /etc/httpd/modules/isp-libphp8.so | grep -m1 -E '[A-Z][a-z]{2} [ 0-9][0-9] 20[0-9]{2}'

If the module was built before 21 October, every site in “Apache module” mode stays vulnerable. To find them: grep -lE 'SetHandler\s+application/x-httpd-php\s*$' /etc/httpd/conf/vhosts/*/*. We moved such sites to alt-php, and where that was impossible (an interface that needs access outside CageFS), we restricted access by IP.

Disabled PHP is worse than enabled PHP. Some former mod_php sites turned out to be static, so we disabled PHP for them. On one of them, next to the placeholder page, there were 61 files of an old site, and with PHP disabled their source code, including a config with the database password, was served as plain text. Before disabling PHP, check: find DOCROOT -name '*.php*' | wc -l.

SSH dropping in the middle of a transaction. Updating 160 alt-php packages took several minutes, and the connection dropped. Luckily the transaction completed, but you have to verify: dnf history list, dnf check (on CentOS 7: package-cleanup --problems, package-cleanup --dupes). Run long updates inside tmux.

Quiet ispmanager rebuilds. The fixed isp-php packages arrived one at a time over a day: first 8.2-8.5, then 7.4, then 7.1. For CentOS 7 the 7.4 build had not appeared at the time of writing. It makes sense to check dnf check-update 'isp-php*' several times a day.

How to move Roundcube and phpMyAdmin to alt-php

On the server with native PHP 5.4 we moved the service FPM pool apache to alt-php56 while keeping the same socket. That way the nginx configuration does not change, and rolling back means simply starting the old service. Choosing 5.6 over 7.4 was simple: Roundcube 1.4 and the old phpMyAdmin ran on 5.4, 5.6 is the closest, and CloudLinux released a backport for it.

Steps:

1. A dedicated ini directory. Outside CageFS, alt-php run by root loads only a minimal set of extensions; the rest live in php.d.all. We built a single extensions.ini from the required modules (session, json, dom, xml*, mbstring, intl, gd, mcrypt, zip, pdo, nd_mysql*). The CloudLinux ini files pull in their own dependencies, so duplicate extension= lines have to be removed.
2. An FPM config with an apache pool on /var/run/php-fpm.apache.sock, the same user, group and listen.owner, and an explicit session.save_path, because it was not set in the native php.ini.
3. A check before switching: PHP_INI_SCAN_DIR=… php -m without errors and php-fpm -t -y … reporting test is successful.
4. A systemd unit with Environment=PHP_INI_SCAN_DIR=… and ExecStart=… php-fpm --nodaemonize -y ….
5. The switch: rename /etc/php-fpm.d/apache.conf, restart the native FPM (it keeps the www pool), start the new one. A few seconds of downtime.
6. Point Apache to the same socket. In roundcube-webmail.conf and phpmyadmin-httpd.conf replace SetHandler application/x-httpd-php with SetHandler "proxy:unix:/var/run/php-fpm.apache.sock|fcgi://localhost/", and in roundcube-isp.conf replace the isp-php74 socket. Make sure SetHandler is inside <FilesMatch "\.php$">, otherwise static files will go to FPM too.

Removing duplicate extensions from step 1:

awk '/^[[:space:]]*(zend_)?extension[[:space:]]*=/ { k=$0; gsub(/[[:space:]]/,"",k); if (seen[k]++) next } { print }' $FILES > conf.d/extensions.ini

Checking which PHP actually runs on each path, including a direct request to Apache and PATH_INFO:

echo '<?php echo PHP_VERSION, " ", php_sapi_name();' > /usr/share/roundcubemail/_v.php
curl -s -H 'Host: nonexistent.invalid' http://127.0.0.1:8080/webmail/_v.php
curl -sk https://DOMAIN/webmail/_v.php/x
rm -f /usr/share/roundcubemail/_v.php

Every line should say 5.6.40 fpm-fcgi. After that the nginx block can be removed.

Two downsides of this approach: on the Apache path the open_basedir restrictions from the mod_php configs are lost, and roundcube-isp.conf is marked by ispmanager as overwritten on package updates. After panel updates, check that the sockets have not reverted and that /etc/php-fpm.d/apache.conf has not reappeared.

Checklist for an ispmanager server

If you run a server with ispmanager and are not yet sure you have fully closed PHP2Shell, go through this list:

• All alt-php branches in use are updated, and the changelog mentions CVE-2026-109618/109619 or the Build Date is 21 October 2026 or later.
• The isp-php* packages are updated and the php-fpm* services restarted (after a unit file change, run systemctl daemon-reload first).
• The OS native PHP is updated or serves nothing (check the pools in /etc/php-fpm.d/ and who connects to their sockets).
• The Apache module isp-libphp8.so was built after 21 October, or no site runs in “Apache module” mode.
• Roundcube and phpMyAdmin run on patched PHP both via nginx and via Apache.
• PHP settings were checked as the user inside CageFS, not as root.
• The CageFS skeleton is updated (cagefsctl --update).
• Temporary nginx blocks are removed, including the line in the default server in nginx.conf.
• Sites with PHP disabled contain no .php files.
• Clients know why the version number in the panel did not change.

The main takeaway from that night is simple: on a hosting server with a control panel, “update PHP” means not one package but five or six different PHP builds from three vendors (upstream via CloudLinux, ispmanager, the distribution), and some of them serve not the sites but the panel’s own applications. It pays to know in advance which PHP sits behind which path, before you need to find out at night.

Sources

• PHP: Security advisory, 21 Oct 2026
• CloudLinux KB: updated package availability
• CloudLinux blog: Imunify360 Ruleset 8.83
• Red Hat RHSA-2026:87151 (PHP 8.0, RHEL 9)
• ispmanager: PHP settings on CloudLinux
• OpenNet: PHP vulnerability (in Russian)