Below is the complete guide for the recent critical PHP vulnerabilities
(CVE-2026-109618 and CVE-2026-109619 - unauthenticated remote code execution,
CVSS 9.2). All vendors (CloudLinux, cPanel, DirectAdmin, Plesk, Ubuntu, AlmaLinux)
have released patches, including backports for older PHP versions.
=================================================================
STEP 1 - IDENTIFY YOUR ENVIRONMENT
Check your OS:
cat /etc/os-release | grep -E '^(NAME|VERSION)='
Check which control panel you use (if any) and the installed PHP:
rpm -qa | grep -Ei '^(alt-php|ea-php|php)' | sort (RHEL-based)
dpkg -l | grep -Ei '(ea-php|alt-php|php)' | head -30 (Ubuntu)
=================================================================
STEP 2 - UPDATE (use the section matching YOUR setup)
--- A) cPanel on CloudLinux (most common) ---
yum clean all && yum makecache
yum update -y 'alt-php*'
yum update -y 'ea-php*'
/scripts/restartsrv_httpd
/scripts/restartsrv_apache_php_fpm
Verify (replace 74/83 with your versions - any CVE line = patched):
rpm -q --changelog alt-php74-common | grep -E 'CVE-2026-(109618|109619)'
rpm -q ea-php83-php-cli --changelog | grep -E 'CVE-2026-(109618|109619)'
--- B) cPanel on plain CentOS / AlmaLinux ---
yum clean all && yum makecache
/scripts/update-packages
/scripts/restartsrv_httpd
/scripts/restartsrv_apache_php_fpm
Verify:
rpm -q --changelog ea-php83-php-cli | grep -m1 CVE-2026-109618
--- C) cPanel on Ubuntu ---
apt clean && apt update
/scripts/update-packages
/scripts/restartsrv_httpd
/scripts/restartsrv_apache_php_fpm
Verify:
zgrep -E 'CVE-2026-109618' /usr/share/doc/ea-php83-php-cli/changelog.Debian.gz
--- D) DirectAdmin ---
IMPORTANT: the panel updating itself does NOT rebuild PHP. The correct order:
da update <- downloads new CustomBuild data incl. the patch files
da build versions <- shows pending PHP updates (* = backport, same version)
da build php <- rebuilds all configured PHP versions
(then check: ls /usr/local/directadmin/custombuild/patches/ | grep -i cve-2026)
Verify:
/usr/local/php83/bin/php -v <- build date must be 21 Oct 2026 or later
--- E) Plesk ---
Plesk PHP is updated through Plesk's own installer:
plesk installer --select-release-current --upgrade-installed-components --include-components=all
plesk repair web -y (if needed)
Plesk 8.2+ moves to 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12. EOL versions (7.4, 8.0,
8.1) keep the same version number - builds dated 21 Oct 2026 include the fix.
Plesk's own engine (sw-engine) is fixed in Obsidian 18.0.81 Update 4.
--- F) No panel - plain OS PHP ---
RHEL / AlmaLinux / Rocky / CloudLinux:
dnf clean all && dnf upgrade -y 'php*'
Ubuntu / Debian:
apt clean && apt update && apt upgrade -y
Verify:
rpm -q --changelog php-common | grep -E 'CVE-2026-(109618|109619)' (RHEL)
zgrep CVE-2026-109618 /usr/share/doc/php*/changelog.Debian.gz (Ubuntu)
=================================================================
STEP 3 - IMPORTANT NOTES (read these, they prevent 90% of confusion)
1) RESTART IS MANDATORY. Updating packages does not patch already-running PHP
processes. Without a restart (web server / PHP-FPM / LiteSpeed) you remain
vulnerable.
2) VERSION NUMBERS MAY NOT CHANGE. CloudLinux, Plesk and Ubuntu backport the fix
into the same version number (e.g. 7.4.33 stays 7.4.33). "php -v" cannot prove
anything - only the changelog/build date can.
3) "yum update" SHOWING "Nothing to do" USUALLY MEANS ALREADY PATCHED - not that
the update is missing. Verify with the changelog commands above.
4) If a version IS installed and still shows no CVE entries after updating,
send us:
- output of cat /etc/os-release
- output of the update command
- output of the verification command
and we will investigate immediately.
5) Real-time protection: on servers with Imunify360, WAF rulesets 8.83-8.85 were
delivered automatically and block the known exploit requests - keep the WAF
enabled. This is an extra layer, not a replacement for updating.
6) Long-term: PHP 8.2 reaches end of life on 31 December 2026 and 8.1/older are
already EOL upstream. Your vendor (CloudLinux/TuxCare) keeps patching them,
but plan gradual migrations to PHP 8.2+ going forward.
