CVE-2026-109619: PHP stale request state reused by the next request, remote code execution

Exploited in the wild Critical 9.2 EPSS 100.0% PHP

PHP worker processes keep some global state (error, session, object and extension state) that points into a request's memory; after a fatal error or a late warning it is not reset, and the next request on the same worker can use the freed memory (use after free). An unauthenticated attacker can chain two requests to the same worker to get remote code execution: PHP confirmed this against Apache mod_php and, through session upload progress plus an application fatal error, against PHP-FPM. Fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35; CISA added it to the Known Exploited Vulnerabilities catalog on 26 October 2026.

Also known as “php2shell”.

• CVE-2026-109619CVE identifier
• 9.2CVSS 4.0 base score (critical)
• 2026-10-26added to CISA's exploited list (US federal deadline 2026-10-29)
• 100.0%EPSS: chance of exploitation in the next 30 days (higher than 100% of CVEs)
• 2026-10-21published

What do these terms mean? CVE · CVSS score · exploited (KEV) · EPSS · backported fix · all terms

Affected and fixed versions

Affected:

• PHP 8.2.0 through 8.2.34
• PHP 8.3.0 through 8.3.35
• PHP 8.4.0 through 8.4.26
• PHP 8.5.0 through 8.5.11
• Unsupported branches (PHP 8.1 and older) get no upstream release; NVD lists this CVE as affecting PHP from 5.4.0, and distros/LTS vendors ship backports (PHP published minimal source backports for 7.4, 8.0 and 8.1).

Fixed in:

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35

Am I affected?

php -v   # CLI binary; also check the binary actually serving web requests
dpkg -l 'php*' 'libapache2-mod-php*' | grep ^ii   # Debian/Ubuntu
rpm -qa 'php*' | sort   # RHEL/Alma/Rocky/SUSE
apk info -v | grep '^php8'   # Alpine
pkg info -x '^(php8|mod_php8)'   # FreeBSD
pkg audit -F   # FreeBSD: lists vulnerable packages from VuXML
apachectl -M 2>/dev/null | grep -i php   # is Apache mod_php loaded? (highest risk per php.net)
php -i | grep -E '^(memory_limit|session.upload_progress.enabled|fatal_error_backtraces) '

Patch it

Use the commands for your system. Distribution packages often keep an older version number with the fix backported, so compare with the fixed package versions in the table below, not only with the upstream version.

sudo apt update
sudo apt install --only-upgrade $(dpkg-query -W -f='${Package}\n' 'php8.*' 'libapache2-mod-php8.*' 2>/dev/null)
# expect php8.4 >= 8.4.27-1~deb13u1 (trixie) or php8.2 >= 8.2.35-1~deb12u1 (bookworm)
sudo systemctl try-restart 'php*-fpm.service' apache2.service

sudo apt update
sudo apt install --only-upgrade $(dpkg-query -W -f='${Package}\n' 'php*' 'libapache2-mod-php*' 2>/dev/null)
# 20.04 and older: fixes are in Ubuntu Pro/ESM (sudo pro attach first)
sudo systemctl try-restart 'php*-fpm.service' apache2.service

sudo dnf upgrade --refresh 'php*'
# RHEL 7 ELS: sudo yum update 'php*'
sudo systemctl try-restart php-fpm.service httpd.service

sudo dnf upgrade --refresh php-fpm php-cli

sudo zypper refresh
sudo zypper patch --category security
# openSUSE Tumbleweed: sudo zypper dup
sudo systemctl try-restart php-fpm.service apache2.service

sudo dnf upgrade --releasever=latest php8.4 php8.4-fpm (or the installed php8.x)

sudo pacman -Syu

sudo apk update
sudo apk upgrade
apk info -v | grep -E '^php8[2-5]-8'   # expect 8.2.35-r0 / 8.3.36-r0 / 8.4.27-r0 / 8.5.12-r0
sudo rc-service php-fpm84 restart   # use your suffix: php-fpm83, php-fpm85 ...

sudo pkg update
sudo pkg upgrade
sudo pkg audit -F
sudo service php_fpm restart
sudo service apache24 restart   # if mod_php is used

# official image: rebuild on a fixed tag (8.5.12, 8.4.27, 8.3.36, 8.2.35 or the moving 8.x tags)
docker pull php:8.4-fpm   # or your variant: -apache, -fpm-alpine, -cli ...
docker compose build --pull
docker compose up -d
docker compose exec <service> php -v

V=8.4.27   # or 8.5.12 / 8.3.36 / 8.2.35
curl -LO https://www.php.net/distributions/php-$V.tar.xz
sha256sum php-$V.tar.xz   # compare with https://www.php.net/downloads.php
tar xf php-$V.tar.xz && cd php-$V
php -i | grep 'Configure Command'   # reuse your old configure options
./configure <same options>
make -j"$(nproc)"
sudo make install
# then restart php-fpm / Apache / FrankenPHP / LiteSpeed workers

General update steps for every system are on the Linux and Unix & BSD pages; after updating, see which services to restart.

Fix status in Linux distributions

From the Debian security tracker, Ubuntu CVE tracker and Red Hat Security Data API, refreshed every few hours.

If you cannot patch yet

• Updating is the only reliable fix; PHP says there is no complete configuration-only mitigation.
• Set session.upload_progress.enabled = 0 in php.ini, the FPM pool (php_admin_flag[session.upload_progress.enabled] = off) or server config, not with ini_set() or .user.ini, and restart every worker. PHP recommends keeping it off even after updating until the next regular release (CVE-2026-115560, advisory of 23 Oct 2026).
• PHP 8.5 only: set fatal_error_backtraces = 0 and restart every worker (blocks the confirmed fatal backtrace path only).
• Remove invalid or deprecated INI settings applied per request (Apache php_value/php_flag in vhosts or .htaccess, PHP_VALUE/PHP_ADMIN_VALUE FastCGI params from nginx or mod_proxy_fcgi) that emit warnings before request startup; hiding them with error_reporting, display_errors or @ does not help.
• Fix attacker-reachable fatal errors and execution timeouts (uploads, imports, callbacks, cleanup). If performance allows, pm.max_requests = 1 limits each FPM worker to one request.
• Blocking multipart/form-data at the frontend is not listed by PHP for this CVE; AWS suggests blocking multipart file uploads as an interim control. It cuts the session upload progress path but not the INI-diagnostic or application fatal-error paths described by PHP.
• Also apply the CVE-2026-109618 mitigations; PHP asks admins to follow both advisories.
• PHP 8.1 or older that cannot be patched: CISA advises taking the system offline until it is updated.

Look for signs of exploitation

• POST requests containing PHP_SESSION_UPLOAD_PROGRESS in multipart form uploads (AWS, CISA SIGMA rule).
• PHP worker processes (php-fpm, apache2/httpd, php-cgi) starting shells or tools such as sh, bash, curl, wget or nc (CISA).
• With log_errors=On and error_reporting=E_ALL: warnings or deprecations repeated before scripts run, diagnostics during extension/server cleanup, fatal and uncaught errors and 'Maximum execution time exceeded' on attacker-controlled routes (PHP). A clean log does not prove safety.
• AWS saw exploitation attempts from 17 October 2026, four days before disclosure: start log reviews from that date.

Related vulnerabilities

• CVE-2026-109618
• CVE-2026-115560

Sources

• CVE-2026-109619 (CVE.org)
• CVE-2026-109619 (NVD)
• CISA KEV entry
• Debian security tracker
• Ubuntu CVE page
• Red Hat CVE page
• SUSE CVE page
• Alpine security tracker
• PHP security advisory: Critical remote code execution vulnerabilities, update now (21 Oct 2026)
• PHP 8.5.12 release announcement
• PHP 8.4.27 release announcement
• PHP 8.3.36 release announcement
• PHP 8.2.35 release announcement
• PHP 8 ChangeLog
• PHP informational advisory: Session upload progress (23 Oct 2026, CVE-2026-115560)
• GHSA-w8hw-w9fx-j79w: RCE via OOM corruption
• GHSA-6wmf-4rv5-p3rp: RCE via stale global state
• CISA alert: Critical Vulnerabilities in PHP Require Immediate Patching
• CISA SIGMA rule for php2shell
• AWS: Amazon threat intelligence identifies PHP2Shell exploitation prior to public disclosure

Page generated automatically from official sources on 2026-11-03 17:06 UTC and reviewed by an editor. Always confirm with your vendor's advisory.