Critical PHP Vulnerabilities (CVE-2026-109618 and CVE-2026-109619): Update Now

On 21 October 2026, the PHP project released fixes for two critical vulnerabilities that can allow unauthenticated remote code execution (RCE). If you run PHP on a VPS, VDS or dedicated server, nobody else can apply the update for you. Install the patched version as soon as it is available for your system.

Status of exploitation: The official PHP advisory describes a demonstrated exploit against mod_php, where an unauthenticated request triggers the attack before any application code runs. Some hosting providers also report active exploitation. The php.net advisory itself does not confirm attacks in the wild, but the safe assumption is that your server is a target.

The vulnerabilities

CVE What it is Details CVE-2026-109618 Remote code execution via out-of-memory (OOM) corruption GHSA-w8hw-w9fx-j79w CVE-2026-109619 Remote code execution via stale global state GHSA-6wmf-4rv5-p3rp

In plain terms:

• CVE-2026-109618: When PHP runs out of memory at the wrong moment, it can be interrupted while internal request data is only partly set up. Cleanup may then treat that invalid data as valid.

• CVE-2026-109619: Internal request state can outlive the memory behind it. A later request handled by the same worker may use that stale state before PHP resets it.

Both are rated 9.2 (critical) on the CVSS v4.0 scale. All PHP installations that serve web requests are at risk: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. Risk is highest for mod_php.

Full details are in the official PHP security advisory.

Fixed PHP versions

Branch Fixed in Notes PHP 8.5 8.5.12 Supported PHP 8.4 8.4.27 Supported PHP 8.3 8.3.36 Supported PHP 8.2 8.2.35 End of life on 31 December 2026, so plan an upgrade

PHP 8.1 and older no longer receive updates from the PHP project. If you run one of these versions, upgrade to a supported branch or check whether your distribution or vendor provides a backport. Minimal source-code backports exist for PHP 7.4, 8.0 and 8.1, but only for building from source.

What you should do

1. Create a snapshot or backup before updating.

2. Update PHP through your distribution's package manager or your control panel as soon as the patched version is available.

3. Restart PHP-FPM, Apache or your web server so every worker loads the new version. Without a restart, the old code keeps running.

4. Verify the version actually in use. Run php -v on the command line, and check a phpinfo() page served through your web server, because the CLI and the web server can use different PHP versions. Check every PHP version installed on the server.

5. If you cannot update immediately, apply the interim measures below. They only reduce exposure and do not make the installation safe. Updating is the only complete fix.

A typical sequence on a Debian or Ubuntu server looks like this (adapt it to your distribution and PHP version):

sudo apt update && sudo apt upgrade
sudo systemctl restart php8.4-fpm   # or apache2 / your web server
php -v

Interim measures if you cannot update yet

The PHP project is clear that there is no complete workaround. These steps lower the risk while you prepare the update.

For CVE-2026-109618 (OOM corruption):

• Set memory_limit=-1, preferably with php_admin_value in the FPM pool or Apache config, and make sure no pool, directory or application setting brings back a finite limit.

• Set a low post_max_size: 8M if you don't need uploads, 32M if you do. Keep upload_max_filesize below it.

• Enforce limits at the web server or proxy for decoded request size, input field count, multipart part count, header count and nesting depth. These must also apply to requests without a usable Content-Length.

• Use a container or cgroup memory limit as an availability boundary, ideally one that kills only the affected worker. Do not use RLIMIT_AS or RLIMIT_DATA, which can trigger the vulnerable allocation failure.

post_max_size = 8M
upload_max_filesize = 8M   ; must stay below post_max_size

For CVE-2026-109619 (stale global state):

• Set session.upload_progress.enabled=0 in php.ini, an FPM pool or server config that applies before request parsing, then restart every worker. Don't rely on ini_set() or .user.ini. This closes the confirmed session paths only.

• On PHP 8.5 only, set fatal_error_backtraces=0 and restart every worker. This closes the confirmed fatal-backtrace path only.

• Remove invalid or deprecated per-request settings that emit diagnostics before initialization. Hiding messages with error_reporting, display_errors or @ does not help.

• Fix attacker-reachable fatal errors and execution timeouts, including failures in callbacks, upload or import processing, and cleanup code.

Where to find patches for your setup

• cPanel/WHM and EasyApache 4: Run the cPanel update (in WHM or with /scripts/upcp), then restart PHP-FPM or Apache and verify the PHP versions in use. Release notes are at docs.cpanel.net.

• Plesk: Update Plesk Obsidian through the Plesk panel.

• CloudLinux (Alt-PHP): Follow the CloudLinux status page and the CloudLinux blog. CloudLinux also offers extended support for PHP versions that are no longer maintained.

• Linux distributions: Check the security advisories for your distribution (Debian, Ubuntu, AlmaLinux, Rocky Linux, RHEL and others).

• Third-party repositories: The volunteer-maintained rpms.remirepo.net did not have updates available at the time of the PHP announcement. The PHP project recommends switching to distribution packages or building from source.

Best practices

• Enable automatic security updates where possible, and review your panel's update settings.

• Remove PHP versions and applications you no longer use.

• Keep your CMS, plugins and themes up to date.

• Use a web application firewall and limit access to administrative interfaces.

• Check for signs of compromise: unknown files in web directories, new cron jobs, unusual processes, and spikes in load or outgoing traffic.

Quick checklist

• Backup or snapshot taken

• PHP updated to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (or upgraded off an unsupported branch)

• PHP-FPM, Apache or web server restarted

• Version verified with php -v and a web-served phpinfo() page

• Every installed PHP version checked

• Web directories, cron jobs, processes and outbound traffic reviewed

Sources: PHP security advisory, 21 October 2026, GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp.