Bali, Indonesia
Home
About
Work
Blog
Insights
Insights

CloudLinux PHP CVE-2026-109618 and CVE-2026-109619: Why a Patch Does Not Always Change the PHP Version

October 23, 2026
0:00
CloudLinux has published security updates for two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619. The incident affects PHP packages delivered through several CloudLinux-supported channels, including alt-php, ea-php, and distribution PHP packages covered by TuxCare ELS or ESU. The operational lesson is easy to miss: installing a security fix does not always mean moving to a newer upstream PHP version. In CloudLinux's own words, some fixed packages contain a backported patch while retaining the PHP version that the package already shipped. That is why a server can be protected even when its command-line output still appears to show an older version.

What are CVE-2026-109618 and CVE-2026-109619?

These are PHP security vulnerabilities for which PHP.net released fixes in newer upstream PHP builds. CloudLinux's status update identifies the corresponding PHP.net fixed versions as:
  • PHP 8.5.12
  • PHP 8.4.27
  • PHP 8.3.36
  • PHP 8.2.35
The CloudLinux incident does not describe the vulnerabilities as a reason to upgrade every application to the newest PHP branch. It describes a package-release and remediation event: fixed builds are being published for the PHP versions and operating-system combinations supported by CloudLinux, cPanel EasyApache, and the relevant extended-support channels. That distinction matters in shared hosting. A server may provide multiple PHP branches at the same time, and changing a website's runtime version can introduce compatibility problems that are unrelated to the security fix. The safer first response is to update the vendor package for the runtime that is already in use, then verify what was installed.

What is the impact?

The impact is potentially serious because PHP commonly processes requests for public websites. A vulnerable PHP runtime can turn an otherwise ordinary web request into a security risk, depending on the vulnerability's trigger conditions and the application or hosting configuration around it. For CloudLinux and hosting administrators, the affected surface is broader than one php binary. It can include:
  • alt-php packages used by CloudLinux PHP Selector and hosted accounts;
  • ea-php packages supplied through cPanel EasyApache 4;
  • native distribution PHP packages on supported CloudLinux releases; and
  • PHP packages delivered through TuxCare ELS or ESU for selected older operating systems.
The incident also states that Imunify360's stable ModSecurity ruleset 8.84 blocks the known exploit pattern when the Imunify360 WAF is enabled. That is useful interim protection, but it is not a substitute for updating the PHP packages. WAF rules reduce exposure to a known request pattern; they do not replace a corrected runtime.

The important misconception: “The PHP version did not change, so the fix did not install”

This conclusion is not reliable for CloudLinux packages. CloudLinux maintains and packages PHP for its own operating-system and hosting ecosystem. It may apply a security correction to the PHP branch already installed on a server rather than immediately rebasing that package to the newest PHP.net version. This is called backporting: the vendor takes the relevant security change and applies it to an older supported code line. For example, CloudLinux reported that these packages were already protected even though their version numbers were lower than the PHP.net releases:
  • alt-php85 8.5.11-5, while PHP.net's fixed line is 8.5.12;
  • ea-php84 8.4.26-2.el8.cloudlinux.1, while PHP.net's fixed line is 8.4.27.
The number 8.5.11 by itself refers to the original PHP.net release history. It does not prove that a CloudLinux package with the same-looking PHP version is still the original, unpatched build. The package release and changelog carry important security information too. In other words:
A security patch is a code change. It is not necessarily a major, minor, or patch-level PHP version change.
The later CloudLinux update says that builds with PHP.net-aligned version numbers are also being released. That makes version comparison easier, but it does not invalidate the earlier backported packages. If the fixed package was already installed, the server was already protected against these CVEs and the later update only aligns the displayed version with PHP.net.

How to update alt-php and ea-php

Use the package manager appropriate for the operating system and package family. CloudLinux's status update recommends a regular package update, not an application-level PHP migration. For CloudLinux OS 7:
BASH
yum clean all
yum update "alt-php*"
For CloudLinux OS 8, 9, and 10:
BASH
dnf clean all
dnf upgrade "alt-php*"
For cPanel EasyApache 4 packages, use the matching package family:
BASH
# CloudLinux OS 7
yum clean all
yum update "ea-php*"

# CloudLinux OS 8, 9, and 10
dnf clean all
dnf upgrade "ea-php*"
On CloudLinux OS for Ubuntu 22.04, CloudLinux lists the regular package upgrade path:
BASH
apt-get update
apt-get upgrade
Do not replace alt-php with ea-php, or the other way around, just because the version output looks different. First identify which package family and PHP handler your websites actually use.

How to verify that the security fix is present

For an alt-php package, inspect the installed package changelog. For example:
BASH
rpm -q --changelog alt-php85-common \
  | grep -E 'CVE-2026-(109618|109619)'
For an EasyApache package:
BASH
rpm -q --changelog ea-php84-php-cli \
  | grep -E 'CVE-2026-(109618|109619)'
The package name must match the PHP branch and package family installed on the server. Checking php -v alone is not enough because it usually shows the language version, not the complete vendor release, package revision, or changelog. For native distribution PHP packages, CloudLinux recommends checking the package changelog as well. Some combinations can be verified by checking the package version directly—for example, PHP 8.2.35 or PHP 8.3.36 and later where those releases apply—while other combinations require looking for the CVE IDs in the changelog. If the update finds nothing, first check whether the cloudlinux-release package is current and whether the package manager metadata is stale. CloudLinux specifically notes that an outdated cloudlinux-release package can prevent the fixed repositories from being visible.

Do services need a restart?

A package update and a running process are separate things. If Apache, PHP-FPM, or LiteSpeed has already loaded the old PHP libraries into memory, restart the relevant service after updating according to your hosting stack. For cPanel's Apache and PHP-FPM services, CloudLinux lists:
BASH
/scripts/restartsrv_httpd
/scripts/restartsrv_apache_php_fpm
A restart is not a PHP version upgrade. It makes the already-installed corrected files active in processes that were started before the package update.

A practical response for hosting teams

A sensible response is therefore:
  1. Inventory which PHP families and branches are actually in use.
  2. Update the relevant alt-php, ea-php, native PHP, or ELS/ESU packages from the supported repository.
  3. Verify the package release and changelog, not only php -v.
  4. Restart the relevant PHP-serving processes when required by the handler.
  5. Keep the Imunify360 WAF ruleset current as a compensating control.
  6. Record the package versions and verification output for the incident or maintenance ticket.
Do not treat “the version number is older” as proof that a security update failed. Conversely, do not treat a successful package-manager command as proof that every PHP family on a multi-tenant server is fixed. The reliable answer comes from checking each installed package family and its vendor changelog. CloudLinux is managing and rebuilding PHP packages for its supported hosting environment, so the security state of a package is determined by the package metadata and applied patches—not by comparing one displayed version string with PHP.net's release table.

Sources