PHP2Shell: CVE-2026-109618 and CVE-2026-109619

Two remote code execution bugs in PHP itself, not in a framework or a plugin, and no login needed. If a server runs PHP for a website, this is the update to install today.

By David Kabel · Updated 2026-10-21 · 5 min read

What the two bugs are

CVE-2026-109618, RCE via out-of-memory corruption. When PHP runs out of memory at the wrong moment, request data can be left half initialised, and cleanup then treats it as valid. An attacker who can push a request into that state can corrupt memory.

CVE-2026-109619, RCE via stale global state. Some state that belongs to one request stays in a global after the request's memory is freed. The next request on the same worker can use it before normal initialisation resets it, which is a use after free. The advisory confirms two paths: early INI diagnostics and session upload progress, which is on by default and does not need the application to call session_start().

Ubuntu ships fixes for its packages as far back as PHP 5, so treat every version you run as affected. watchTowr, which published an FAQ the same day, reports exploitation in the wild. The PHP project's own announcement does not say that, so treat it as reported rather than confirmed.

Where the fix is

If you use the volunteer-run Remi repository, the PHP team said it would not have updates on release day and recommended distribution packages or a source build instead.

Check what you are running

# Which PHP is the web server actually running? The CLI can differ from FPM.
php -v
php-fpm8.4 -v                       # Debian/Ubuntu, adjust the version
dpkg -l 'php*-common' | awk '/^ii/ {print $2, $3}'
rpm -q php-common                   # RHEL family

# Is the risky default still on? (CVE-2026-109619 mitigation)
php -i | grep session.upload_progress.enabled

Check the FPM binary or the package version, not only php -v. On servers with several PHP versions installed side by side, the CLI is often not the one serving the site.

Update and restart

# Debian / Ubuntu
sudo apt update && sudo apt install --only-upgrade 'php8.*'
sudo systemctl restart php8.4-fpm   # every FPM version you run
sudo systemctl reload apache2       # if you use mod_php

# RHEL family
sudo dnf upgrade 'php*'
sudo systemctl restart php-fpm httpd

A package upgrade alone is not enough. Old FPM workers keep the vulnerable code in memory until they restart. In containers, pull the new base image and rebuild. A running container does not change because the tag on Docker Hub moved.

If you cannot update today

The PHP security team published stopgaps that close the confirmed attack paths. They are explicit that these reduce exposure and do not make a server safe:

; Stopgaps only, from the PHP security team. Not a fix.
; Put these in php.ini or the FPM pool (php_admin_value), not ini_set() or .user.ini
session.upload_progress.enabled = 0
post_max_size = 8M        ; 32M if the site takes uploads
; PHP 8.5 only:
fatal_error_backtraces = 0

Restart every worker after changing them. The team also suggests limiting request size, field count and multipart parts at the web server or proxy, and using a container or cgroup memory limit rather than RLIMIT_AS or RLIMIT_DATA, which can trigger the vulnerable allocation failure. Setting memory_limit=-1 removes the PHP-level memory limit failure for CVE-2026-109618, but an underlying allocation failure can still reach the bug.

Gotchas

• The CLI is not the web server. php -v can report a patched version while an older FPM pool from another package keeps serving requests. Check each FPM service.
• ini_set() and .user.ini do not apply the mitigation. The advisory says the session upload progress setting must be in place before request parsing, so use php.ini or the pool configuration.
• Hiding errors does not help. The advisory states that display_errors, error_reporting and the @ operator do not block the diagnostics path. Remove the invalid or deprecated per-request settings that trigger it.
• PHP 8.2 ends in December. The PHP project says 8.2 gets no security fixes after 31 December 2026. If you are patching 8.2 today, plan the move to 8.4 or 8.5 now.

How this was checked. On 21 October 2026 we read the PHP security announcement and the two GitHub advisories, the Debian security tracker entries for both CVEs, and Ubuntu's CVE page. We confirmed the Docker Hub update times for the php:8.5 and php:8.4 tags through the Docker Hub API. Not tested: the vulnerabilities themselves. We did not try to reproduce either bug.

Sources

1. PHP News Archive 2026, PHP project, security announcement and release notes, 21 October 2026
2. GHSA-w8hw-w9fx-j79w: RCE via OOM corruption, php/php-src
3. GHSA-6wmf-4rv5-p3rp: RCE via stale global state, php/php-src
4. CVE-2026-109618 and CVE-2026-109619, Debian security tracker
5. CVE-2026-109618, Ubuntu security
6. PHP Remote Code Execution FAQ, watchTowr