CVE-2026-109618: PHP out-of-memory handling corrupts request memory, remote code execution

Exploited in the wild Critical 9.2 EPSS 100.0% PHP

When PHP hits an out-of-memory error it aborts the request with longjmp(), which can leave request memory partly initialized; request cleanup then treats it as valid, which attackers can turn into remote code execution. An unauthenticated attacker can trigger the out-of-memory condition with crafted multipart POST requests, and with Apache mod_php this happens before any application code runs; PHP-FPM is also considered susceptible. 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-109618CVE 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 7.3.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 complete fix (PHP). The steps below reduce exposure but do not make a server safe.
• Set memory_limit=-1 in a way applications cannot override (php_admin_value memory_limit -1 in the FPM pool or Apache config), make sure no pool, directory or app setting restores a finite limit, and restart every worker. An underlying allocation failure can still reach the vulnerable path.
• Keep post_max_size low (PHP suggests 8M without file uploads, 32M with uploads) and upload_max_filesize below it; reduce max_input_nesting_level and enforce limits at the web server/proxy for decoded request size, input fields, multipart parts, headers per part and nesting depth, including for requests without a usable Content-Length.
• A container or cgroup memory limit (memory.max) can serve as an availability boundary, preferably killing only the affected worker. Do not use RLIMIT_AS or RLIMIT_DATA: they make allocations fail and trigger the vulnerable path.
• Blocking multipart/form-data at the web server or proxy is a partial measure only. PHP's advisory says: if the application does not use multipart form data, block such requests at the frontend before they reach PHP; AWS also suggests blocking multipart file uploads while patching is delayed. It removes the confirmed application-independent OOM triggers (multipart parsing), but PHP notes OOM can also be reached in application-specific ways, so it does not fix the flaw and breaks file uploads. Example for nginx (inside the PHP location): if ($content_type ~* "multipart/form-data") { return 415; }
• Also apply the CVE-2026-109619 mitigations (session.upload_progress.enabled=0 etc.); 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

• PHP error log entries 'PHP Fatal error: Allowed memory size ... in Unknown on line 0' (memory exhaustion before any script runs), used in CISA's SIGMA rule.
• POST requests with multipart/form-data bodies containing the field PHP_SESSION_UPLOAD_PROGRESS (CISA SIGMA rule, AWS).
• Unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses, unexplained PHP worker churn, and unusually large or malformed PHPSESSID cookies (Wiz).
• PHP worker processes (php-fpm, apache2/httpd, php-cgi) starting shells or tools such as sh, bash, curl, wget or nc (CISA).
• AWS saw exploitation attempts from 17 October 2026, four days before disclosure: start log reviews from that date.

Related vulnerabilities

• CVE-2026-109619
• CVE-2026-115560

Sources

• CVE-2026-109618 (CVE.org)
• CVE-2026-109618 (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.