What the advisory says

• On 20 October 2026, the PHP project announced an upcoming security release for two critical vulnerabilities.
• The fixes were released on 21 October 2026, in the four branches listed in the table below.
• Technical details are now being discussed publicly, and initial proofs of concept have begun to circulate. CERT-EU says this raises the likelihood that attackers are already exploiting the vulnerabilities.

Who is at risk

Every PHP installation that serves web requests is at risk. That includes PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The PHP project considers mod_php the highest-risk setup, because a demonstrated exploit can trigger the attack with one unauthenticated request, before any application code runs.

Many commercial and open-source products use PHP internally, so they can be affected even if they do not show a PHP installation. CERT-EU recommends checking the NCSC-NL repository for third-party software that embeds PHP.

Affected versions and fixed releases

The two vulnerabilities

CVE-2026-109618: memory corruption during out-of-memory handling

PHP enforces the memory_limit setting by aborting any request that exceeds it. This can interrupt PHP while internal request data is only partly set up, for example while a form-based file upload is being parsed. Request cleanup may then treat the invalid data as valid, and try to free memory that was never initialised. CVSS v4.0: 9.2.

CVE-2026-109619: stale global state

Internal state owned by one request can survive after its memory has been freed, for example after a fatal error. A later request handled by the same worker may then use that stale state before the normal reset runs. CVSS v4.0: 9.2.

Patch first: step by step

1. Find every PHP installation. Include PHP bundled with applications and vendor software, not only the system PHP.
2. Take a backup of the server or the site before you change anything.
3. Update to the fixed release for your branch: 8.5.12, 8.4.27, 8.3.36 or 8.2.35. CERT-EU notes that Linux distributions and LTS vendors received the patches in advance, so check your vendor for updated packages.
4. Restart every worker. Restart PHP-FPM, and Apache or Nginx. Apache with mod_php needs a full restart.
5. Confirm the version on each installation, and test the sites.

php -v

# Debian and Ubuntu
sudo apt update
apt list --upgradable 2>/dev/null | grep -i php

# AlmaLinux, Rocky Linux and RHEL
sudo dnf update 'php*'

# Restart the services that run PHP
sudo systemctl restart php-fpm
sudo systemctl restart httpd    # or nginx, or apache2 on Debian and Ubuntu

For control-panel steps, see our PHP critical security update guide, which covers cPanel and WHM with EasyApache 4 25.91, aaPanel, and CloudPanel.

For control-panel steps, the sections below cover cPanel and WHM, servers without a control panel, aaPanel and CloudPanel.

cPanel and WHM servers

1. In WHM, update cPanel & WHM to the latest release. cPanel has published EasyApache 4 25.91 (21 October 2026), which fixes both PHP vulnerabilities in ea-php74 through ea-php85.
2. Open WHM > Software > EasyApache 4 and build the PHP versions you use. Rebuilding is what installs the fixed PHP packages.
3. Open MultiPHP Manager to check the PHP version on each domain.
4. Check the cPanel version and PHP version over SSH as root:

# cPanel and WHM version (must match the release you installed)
/usr/local/cpanel/cpanel -V

# Default PHP version on the server
php -v

# Each EasyApache 4 PHP build (ea-php74 to ea-php85)
ls /opt/cpanel | grep ea-php

To run the cPanel update script from SSH, use the command below. Only run it if your WHM update has not already done so.

/scripts/upcp --force

Servers without a control panel

1. Inventory every PHP installation. Include PHP that ships inside applications or vendor software, not only the system PHP.
2. Update each one to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 using your distribution’s packages or your vendor’s packages.
3. Restart the services that run PHP (PHP-FPM, and Apache or Nginx). Apache with mod_php needs a full restart.
4. Confirm the version for each installation.
5. Isolate end-of-life PHP from the internet until you can upgrade it.

Example commands over SSH. Package and service names differ between distributions, so check them on your server first.

# Show the PHP version
php -v

# Debian and Ubuntu: refresh packages and list PHP updates
sudo apt update
apt list --upgradable 2>/dev/null | grep -i php

# AlmaLinux, Rocky Linux and RHEL: update PHP packages
sudo dnf update 'php*'

# Restart PHP-FPM and the web server (names vary by distribution)
sudo systemctl restart php-fpm
sudo systemctl restart httpd    # or apache2 on Debian and Ubuntu

# Confirm the version again
php -v

Use the package and service names your system shows, for example systemctl list-units | grep -i php. If a PHP version is not in your repositories, use your vendor’s packages instead of installing from source.

CloudLinux status (updated 22 October 2026)

This section follows the CloudLinux status updates of 22 October 2026, 09:21 UTC, which replace the earlier updates from 21 October. CloudLinux says its status changes often, so check its status page before you rely on this table. Native PHP, alt-php and ea-php are different packages. Use the commands for the package type you run.

Confirm the fix

• ea-php and alt-php: these packages carry the fix as a backport, so their version numbers stay below PHP’s. For example, ea-php84 is 8.4.26, not 8.4.27. Check the changelog for the CVE IDs:

rpm -q ea-php84-php-cli --changelog | grep -E 'CVE-2026-(109618|109619)'
rpm -q --changelog alt-php82-common | grep -E 'CVE-2026-(109618|109619)'

• Native PHP 8.2 and 8.3 (rebased): the changelog says only “rebase to 8.2.35” or “rebase to 8.3.36”, with no CVE IDs, so the changelog check returns nothing even on a fixed server. Check the version instead. It should be 8.2.35 or 8.3.36 or later:

rpm -q php-cli

• Security metadata: OVAL and UpdateInfo data for these packages is not published yet. Security-only filters such as yum --security and dnf updateinfo will not list them. Use a regular update, as shown above.

Imunify360 interim protection

Servers with Imunify360 and its WAF enabled receive rulesets 8.83, 8.84 and 8.85 automatically. On ModSecurity (Apache and Nginx) and Coraza they block the known exploit requests and the public exploit tool. On LiteSpeed, ruleset 8.84 blocks the exploit tool and upload progress requests that do not come from the site’s own pages. No rule blocks the out-of-memory path of CVE-2026-109618 yet. This is an interim mitigation, not a fix. Patch as well.

Platform-specific updates

EasyApache 4 packages (cPanel)

cPanel has published fixed packages: ea-php82 8.2.35, ea-php83 8.3.36, ea-php84 8.4.27 and ea-php85 8.5.12. The nightly cPanel update installs them if automatic updates are on. To install them now, run the commands below as root, then check the versions.

dnf update 'ea-php*'
/scripts/restartsrv_apache_php_fpm

# Check the installed EasyApache 4 PHP versions
dnf list installed 'ea-php*'

cPanel’s packages for PHP 8.1 and older do not include the fix. Move those sites to PHP 8.2 or later in WHM > MultiPHP Manager.

CloudLinux (alt-php)

If your PHP comes from CloudLinux alt-php, update it with:

dnf update 'alt-php*'

AlmaLinux, Rocky Linux and RHEL: the Remi repository

If your PHP comes from the Remi repository (rpms.remirepo.net), PHP says it will not have updates on release day. Switch to your distribution’s packages, or build from source.

Debian and Ubuntu

Update with the commands below. This also picks up updates from the ondrej/php repository if you use it.

sudo apt update && sudo apt upgrade

Docker and other containers

Pull the new PHP base image, rebuild the image and redeploy. A running container keeps the old PHP until you replace it.

Linux distributions and LTS vendors received the patches in advance, so most should have packages today. If yours is not available yet, check again later, then install it and restart PHP-FPM or Apache.

aaPanel servers

Take a server snapshot or confirm your current backups before you start.

1. Open App Store, then click Update App List.
2. Under Installed, find PHP 8.2 and PHP 8.3 (and any other PHP version you run).
3. Use the Update action for one version at a time.
4. Check the installation log, then confirm the resulting version.

php -v

CloudPanel servers

Take a backup or snapshot first. CloudPanel servers can be updated over SSH with the same package steps as servers without a control panel. Use the PHP packages from your operating system or vendor, as shown below.

1. Connect over SSH as root, or as a user with sudo.
2. Check the PHP version the server runs, then update the PHP packages to 8.5.12, 8.4.27, 8.3.36 or 8.2.35.
3. Restart PHP-FPM and Nginx.
4. Set the fixed version for each site in CloudPanel: open the site, go to the PHP Settings tab, select the version, and update.
5. Test each site, then check the PHP version again.

The per-site PHP setting is in the CloudPanel web interface. Check CloudPanel’s official documentation before you rely on any command-line steps for it.

If you cannot patch straight away: temporary mitigations

CERT-EU stresses that only an update fully fixes these vulnerabilities. The measures below reduce exposure to specific attack paths, and they do not make an installation safe. Apply them only until the update is in place and verified.

For CVE-2026-109618 (memory corruption)

• Set memory_limit=-1 in a way that applications cannot override, such as php_admin_value in the PHP-FPM pool or the Apache configuration. Check that no pool, directory or application setting puts a finite limit back.
• Set a low post_max_size: 8M for applications that do not accept uploads, or 32M where uploads are needed. Keep upload_max_filesize below post_max_size.
• Limit decoded request size, field count, multipart part count, header count and nesting depth at the web server or proxy. These limits must also cover requests without a usable Content-Length header.
• Use a container or cgroup memory limit as an availability boundary. Do not use RLIMIT_AS or RLIMIT_DATA, because they can trigger the vulnerable allocation failure.

For CVE-2026-109619 (stale global state)

• Set session.upload_progress.enabled=0 in php.ini, or in a PHP-FPM pool, then restart every worker. Do not rely on ini_set() or .user.ini, because they take effect too late.
• On PHP 8.5, set fatal_error_backtraces=0 and restart every worker.
• Fix fatal errors and execution timeouts that an attacker could reach, especially in upload and import processing.

Hiding diagnostics with error_reporting, display_errors or @ does not help.

Configuration snippets for the temporary workaround

Use these settings only until the update is installed. They reduce exposure to the known attack paths, but they do not make a server safe. Set them server-wide, in php.ini, a PHP-FPM pool, or the Apache configuration. Use php_admin_value and php_admin_flag, because ini_set() and .user.ini take effect too late to help. Then restart every PHP worker.

PHP-FPM pool

; e.g. /etc/php-fpm.d/www.conf
php_admin_flag[session.upload_progress.enabled] = off
php_admin_value[post_max_size] = 8M
php_admin_value[memory_limit] = -1
; PHP 8.5 only:
php_admin_flag[fatal_error_backtraces] = off

Then restart PHP-FPM, for example systemctl restart php-fpm. A reload may leave old workers running.

Apache with mod_php

# httpd.conf or the site's <VirtualHost>
php_admin_flag session.upload_progress.enabled off
php_admin_value post_max_size 8M
php_admin_value memory_limit -1

Then restart Apache. mod_php is the highest-risk setup, so update these servers first.

php.ini

session.upload_progress.enabled = 0
post_max_size = 8M
memory_limit = -1
; PHP 8.5 only:
fatal_error_backtraces = 0

A pool, directory or application setting can override php.ini. Check that nothing sets a finite memory_limit back. On cPanel, use WHM > MultiPHP INI Editor > Editor Mode and repeat the settings for each PHP version.

What these settings cost you

• post_max_size = 8M caps form posts at 8 MB. If a site takes file uploads, use 32M instead, and keep upload_max_filesize below it.
• memory_limit = -1 removes PHP’s per-request memory cap, so one runaway script can use all of the server’s memory. PHP recommends a container or cgroup memory limit as a backstop.
• Upload progress bars stop working, but uploads themselves still work.

Check that the settings took effect

Create a file with a random name in the site’s document root, containing the line below. Open it in your browser and check session.upload_progress.enabled, post_max_size and memory_limit. Delete the file as soon as you have checked, because it exposes details about your server.

<?php phpinfo();

php -i on the command line does not show the web settings, because the command line reads its own configuration.

End-of-life PHP (8.1 and older)

The PHP project no longer ships updates for PHP 8.1 and older. Some distributions and LTS vendors backport fixes, so contact your vendor. The PHP team has also published minimal source backports for PHP 7.4, 8.0 and 8.1, for organisations that build from source. The safer option is to move the site to a supported branch.

The community repository rpms.remirepo.net will not have updates on release day. The PHP team urges users to switch to distribution packages or build from source.

Isolate what you cannot patch

Where patching is not feasible, CERT-EU advises isolating internet-facing applications from public networks until the fix is applied and verified. Put the affected sites behind an access restriction, or take them offline until they are updated.

Support dates

What UnderHost has done

All UnderHost shared hosting and managed customer servers have been patched. If you run an unmanaged VPS or dedicated server, update it yourself using the steps above.

Sources

• CERT-EU security advisory 2026-018
• PHP project announcement
• NCSC-NL repository (third-party software that embeds PHP)

Need help with an update? Open a ticket through @CustomerPanel.