PHP CVE-2026-109618 and CVE-2026-109619: CloudLinux Package Status and Imunify360 Protection

What we know

PHP’s advisory describes two separate flaws, each allowing unauthenticated remote code execution:

• CVE-2026-109618 (GHSA-w8hw-w9fx-j79w): out-of-memory handling can interrupt PHP while internal request data is only partly initialized, and request cleanup may then treat the invalid data as valid.
• CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp): request-owned internal state can survive after its memory is freed, and a later request handled by the same worker may use that stale state before normal initialization resets it.

The fixed versions are 8.5.12, 8.4.27, 8.3.36, and 8.2.35. PHP states that updating is the only complete solution. The project first gave advance notice on 20 October. CERT-EU has also published an advisory.

Linux distributions and long-term-support vendors have their own packages, so check your vendor. PHP notes that the volunteer-maintained rpms.remirepo.net repository has no updates today and urges switching to distribution packages or building from source.

What Imunify360 does today

Imunify360 ships one WAF ruleset, maintained by Imunify’s analysts, to ModSecurity and Coraza (open-source web application firewall engines) and to LiteSpeed. Five releases carry rules for these CVEs, and servers with the WAF enabled receive them automatically:

• Ruleset 8.83 (21 October, 09:08 UTC) blocks the publicly circulating exploit request, which abuses PHP’s session upload progress handling, on ModSecurity (Apache and Nginx) and Coraza. This rule does not run on LiteSpeed, where a second rule only logs matching requests.
• Ruleset 8.84 (21 October, 13:07 UTC) blocks the public exploit tool by its signature, and blocks uploads that use the upload progress field but don’t come from a page of the same site. These rules run on every web server, LiteSpeed included.
• Ruleset 8.85 (21 October, 17:17 UTC) blocks further variants of the tool and logs other unusual upload requests.
• Ruleset 8.86 (22 October, 05:50 UTC) blocks more renamed versions of the tool and logs server responses that set a PHP session cookie containing a NUL byte.
• Ruleset 8.88 (23 October, on stable) adds a blocking rule, 77049357, for a serialized PHP object in the upload progress field, whatever the Referer.

Imunify360 also gives IP addresses that scan for or exploit these vulnerabilities a CAPTCHA challenge on the servers it protects.

The 8.84 rule for uploads from other sites can also stop a legitimate upload form hosted on another domain, or a browser that strips the Referer header. If a real upload page stops working, contact support.

This is a virtual patch: it stops known request patterns at the server edge while the vulnerable PHP code stays as it is. No rule blocks the out-of-memory path of CVE-2026-109618 yet. PHP says its own session-related mitigation covers the confirmed session paths and not other variants, and the same limit applies here. A request built to look like a normal upload from the site’s own pages may not match. Only the PHP update closes the flaws.

Am I protected?

What you should do

Step 1: Update PHP

Update to the fixed version for your branch: 8.5.12, 8.4.27, 8.3.36, or 8.2.35, or your vendor’s patched package. Hosting servers often run several PHP versions side by side, so update each one that serves websites, then restart PHP-FPM or the web server so the new build is loaded. Release notes are in the PHP ChangeLog. For CloudLinux packages, see step 3.

Step 2: Check the Imunify360 ruleset

Check that ruleset 8.88 or later has reached your servers. On Imunify360 hosts with the WAF enabled, it arrives without any action. To confirm, read the ruleset VERSION file as root. On cPanel with Apache, for example:

cat /etc/apache2/conf.d/modsec_vendor_configs/imunify360-full-apache/VERSION

Paths for Plesk, DirectAdmin, standalone servers, and LiteSpeed are in the Imunify360 ruleset version article. The release notes are in the Imunify WAF rules changelog. If the version is older than 8.88, update the ruleset and check again:

imunify360-agent update --force modsec-rules

Step 3: Update CloudLinux PHP packages

ea-php on cPanel EasyApache 4. Fixed packages for ea-php52 through ea-php85 are in stable for CloudLinux 7, 8, 9, and 10. Update them, then restart Apache and PHP-FPM:

CloudLinux 7:        yum clean all && yum update "ea-php*"
CloudLinux 8, 9, 10: dnf clean all && dnf upgrade "ea-php*"

/scripts/restartsrv_httpd
/scripts/restartsrv_apache_php_fpm

alt-php. Fixed packages are in stable for CloudLinux 7, 8, and 9 (alt-php 5.2 to 5.6, 7.0 to 7.4, and 8.0 to 8.5), for CloudLinux OS for Ubuntu 22.04 (alt-php 5.2, 5.6, 7.0 to 7.4, and 8.0 to 8.5), and for alt-php 5.2 on CloudLinux 10. The other alt-php versions on CloudLinux 10 come from the TuxCare ELS alt-php repository, where they are already available. Availability on CloudLinux 6 is not confirmed yet. A regular update installs the fixed packages, then restart your PHP services (Apache, PHP-FPM, or LiteSpeed):

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

If you added the ELS alt-php repository on CloudLinux 7, 8, or 9 as a temporary workaround, you can disable it and run the regular update again:

CloudLinux 7:     yum-config-manager --disable php-els
CloudLinux 8, 9:  dnf config-manager --set-disabled php-els

System php packages from the CloudLinux repositories. Fixed builds of the php packages that come with the operating system, outside alt-php and ea-php, are in stable for every affected version: CloudLinux 10 PHP 8.3, CloudLinux 9 PHP 8.0, 8.1, 8.2, and 8.3, CloudLinux 8 PHP 7.2, 7.3, 7.4, 8.0, and 8.2, and CloudLinux 7 PHP 5.4 (TuxCare ELS). A regular package update installs them. Restart PHP-FPM or the web server afterwards.

How to confirm the fix. 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. Look for the CVE IDs in the package changelog instead:

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)'

On CloudLinux 8 and 9, alt-php builds with the PHP.net version numbers are also in stable: alt-php82 8.2.35-1, alt-php83 8.3.36-1, alt-php84 8.4.27-1, and alt-php85 8.5.12-1. Earlier fixed builds, such as alt-php85 8.5.11-5, are already protected, so this only brings the version numbers in line with PHP.net.

For native PHP, PHP 8.3 on CloudLinux 10, PHP 8.2 and 8.3 on CloudLinux 9, and PHP 8.2 on CloudLinux 8 are rebased to the PHP releases, and their changelog names no CVE IDs. Check the version instead. It should be 8.2.35 or 8.3.36 or later:

rpm -q php-cli

For the other native versions, check the changelog for the CVE IDs:

rpm -q --changelog php-cli | grep -E 'CVE-2026-(109618|109619)'

If the update fails or finds nothing to install, check that the cloudlinux-release package is current:

rpm -q cloudlinux-release

If yours is older, update it, clear the cache, and run the PHP update again:

CloudLinux 7:        yum update cloudlinux-release && yum clean all
CloudLinux 8, 9, 10: dnf update cloudlinux-release && dnf clean all

Security advisory metadata (OVAL and UpdateInfo) is not published yet, so security-only update filters in yum and dnf do not list these packages. Use a regular update, as shown above.

Step 4: Reduce exposure until you can update

While you wait for a patched package, PHP lists interim measures that reduce exposure but do not make an installation safe. For CVE-2026-109619, set the upload progress option to 0 in php.ini, an FPM pool, or server configuration that applies before request parsing, then restart every worker:

session.upload_progress.enabled=0

Do not rely on ini_set() or FPM .user.ini for this. PHP says it blocks the confirmed session paths but not other variants. PHP’s advisory also lists measures for CVE-2026-109618, such as request-size limits at the web server or proxy. Read them in the advisory before applying, since some settings have side effects.

Where immediate patching is not possible, CERT-EU’s advisory also suggests isolating internet-facing PHP applications from public networks until a fix is applied.

We will update this post as more protection and packages ship. The status page has the full update history.

Why it matters on a hosting server

PHP runs WordPress, WooCommerce, Magento, Drupal, Joomla, and most of the rest of the shared-hosting stack, on servers that face the internet.

An unauthenticated remote code execution flaw needs no account on the target site: the attacker only has to reach a PHP endpoint. A public exploit tool is now in circulation and is being used for mass scanning. Sansec expected mass exploitation to follow the upstream release; Huntress and watchTowr reported no exploitation as of the morning of 21 October.