No fluff. Just the config that works.

PHP2Shell CVE-2026-109618 and its sibling CVE-2026-109619 are two unauthenticated remote code execution bugs in the PHP engine itself, not in WordPress, Drupal, or any plugin. If a box answers web requests with PHP, it was in scope. Both are rated CVSS v4.0 9.2, both were patched on October 21, 2026, and CISA added both to the Known Exploited Vulnerabilities catalog on October 26 after honeypots logged working shells. This post is the deep dive: what actually breaks inside PHP, why mod_php is the worst case, how the in-the-wild chain works, and how to check your own estate and hunt for a hit.

If you are here for the FortiGate IPS and FortiWeb signatures, that is a separate post: PHP2Shell mitigation with Fortinet. This one stays at the engine and host level.

Objective: understand the root cause of both CVEs well enough to judge exposure, verify the patch actually took, and hunt for compromise back to October 17, 2026.

Target audience: security engineers, Linux and web platform admins, SOC analysts, and SEs who have to explain to a customer why “we don’t run WordPress” does not get them off the hook.

PHP2Shell CVE-2026-109618 and CVE-2026-109619 at a glance

PHP 7.4, 8.0, and 8.1 received source-only backports with no compiled release, and PHP 5.4 through 7.3 have no fix at all, according to the Censys advisory. Distribution packages are a different story: Ubuntu, for example, shipped fixes for php7.0 on 16.04 ESM through php8.5 on 26.04, all while keeping their original upstream version strings (Ubuntu CVE page). That detail matters for verification later.

Prerequisites and architecture

Assumed knowledge

• How PHP sits behind a web server: Apache with mod_php (PHP runs inside the Apache child), PHP-FPM (a separate pool of worker processes behind nginx or Apache mod_proxy_fcgi), and the newer embedded runtimes such as FrankenPHP.
• That PHP workers are long-lived. One worker process handles many requests in a row, and per-request memory is thrown away between them. PHP2Shell lives in the gap between those two facts.
• Basic Linux log locations (/var/log/apache2, /var/log/nginx, /var/log/php*-fpm.log) and grep, awk, find.

Lab and environment

Every command below was written for Debian or Ubuntu paths with Apache mod_php or PHP-FPM 8.3. Swap the version number and paths for RHEL family hosts (/var/log/httpd, /var/lib/php/session, rpm instead of dpkg). Lab addressing in examples uses 198.18.0.0/15 for the internet-facing side and 10.0.0.0/16 for internal LANs.

The SAPI breakdown comes from the PHP advisories as summarized by Censys and Corgea.

How the bugs actually work

Figure 1: PHP2Shell request flow: request A plants stale state, request B on the same worker consumes it

CVE-2026-109618: an out-of-memory error that jumps out mid-sentence

PHP has always handled “Allowed memory size exhausted” the same way. The allocator raises a fatal error and calls zend_bailout(), which is a C longjmp() back to the nearest error handler. It does not care what the code it interrupted was halfway through doing. If some request structure was already published but not finished being built, it stays half-built. Request shutdown then reads it or branches on it.

The interesting part is where the attacker forces that OOM. PHP parses multipart/form-data bodies during php_request_startup(), before any script runs. The advisory lists three ways to drive that parser past memory_limit while staying inside the limits PHP believes it is enforcing (Corgea analysis):

1. A multipart request with no usable Content-Length passes the post_max_size check and keeps feeding decoded body data.
2. A single part can carry any number of headers, and PHP’s in-memory representation of them is much larger than the bytes on the wire.
3. Empty file controls do not count toward max_file_uploads but still build $_FILES metadata arrays, and nested field names multiply that work.

On Apache mod_php, request shutdown runs even when request startup fails, so the corrupted state is processed before PHP ever opens a file. That is why a stock “Hello World” page was exploitable. No vulnerable app required.

The memory leak that defeats ASLR

Session upload progress (session.upload_progress.enabled, on by default) can start session handling during multipart startup and store a session ID pointer in the worker global PS(id). If the OOM fires right then, the request heap is freed and PS(id) keeps pointing into it. On the next multipart request to the same worker, the upload-progress cleanup runs before normal session setup resets the pointer, and PHP URL-encodes whatever now lives at that address into the PHPSESSID response cookie (Corgea analysis, Varonis).

Two consequences. First, the attacker gets a chunk of worker memory back, which is exactly what is needed to locate libphp and beat ASLR. Second, that chunk can contain other users’ request data: passwords, tokens, API keys. This works even if the application never calls session_start(). A host that leaked memory without ever getting shelled still needs secret rotation.

CVE-2026-109619: stale globals as a producer and consumer

The second advisory generalizes the pattern. PHP keeps error, session, object, and extension state in worker globals that temporarily point into one request’s memory. Exploitation needs a producer that leaves request-owned state behind after a fatal error and a consumer in a later request on the same worker that touches it before initialization replaces it (Zend advisory, Censys).

Fatal interruptions that can strand state include OOM, parse and compile errors, uncaught errors, a failed require, and Maximum execution time exceeded. The confirmed consumers:

• Session upload progress. It reaches session and unserializer state (BG(unserialize)) before normal session initialization. This is the path most in-the-wild traffic used.
• INI diagnostics raised before request startup. On mod_php, .htaccess php_value and php_flag directives apply before php_request_startup(). A deprecation as ordinary as auto_detect_line_endings=1 is enough to touch the stale error state. On FPM, PHP_VALUE or PHP_ADMIN_VALUE passed from nginx does the same. Turning off display_errors or using @ does not help, because PHP touches the state before deciding whether to report.
• PHP 8.5 fatal error backtraces. With fatal_error_backtraces enabled, the stored backtrace is never reset at shutdown and the next request dereferences it.
• OPcache. Researchers also built a type-confusion chain where an allocation failure during script persistence leaves shared slots another worker reuses for a different type.

From dangling pointer to shell

Once the attacker controls what lands in the freed memory, PHP’s own cleanup does the rest. The published exploit forges a HashTable in reclaimed memory whose pDestructor pointer is set to zif_system, the C function behind PHP’s system(). When PHP destroys the stale session array, it calls that destructor, and the attacker’s command runs as the web server user (Corgea, Akamai).

The working chain seen on honeypots on October 24 was four HTTP requests: exhaust memory, read back an 800 KiB PHPSESSID heap dump, compute a live function address from it, then fire (The Hacker News, Corgea). Two source IPs produced 35 working shells across three Apache mod_php 8.4.26 sensors that weekend.

What the fix changed

All four branches took the same commit, titled “Avoid state corruption via bailout.” It does two things (Corgea analysis):

• OOM no longer longjmps mid-allocation. Exceeding memory_limit now queues a delayed error and sets the VM interrupt flag, so the fatal error is raised at the next safe point. A second, higher hard limit kills the process outright if a delayed error would let memory run away.
• Upload progress is fenced off before RINIT. The session upload-progress handlers now set a guard flag, bail out if session initialization fails, and only decode objects as incomplete classes, so no autoloader, __wakeup(), or __unserialize() can run that early.

Timeline

Sources for the timeline: Amazon findings via The Hacker News, TechTarget on the disclosure breakdown, BleepingComputer on the KEV addition, and the running updates in the Corgea write-up.

CVE-2026-115560: the one the patch does not cover

Two days after the emergency release, PHP disclosed a third RCE path that is still present in 8.2.35 through 8.5.12. It only applies when all three are true: session.serialize_handler is set to php_binary or php_serialize in config, the application switches it to php at runtime with ini_set() before session_start(), and session upload progress is enabled. Apps that never flip the handler at runtime are not exposed through this route. The mitigation is the same switch used for CVE-2026-109619: session.upload_progress.enabled = 0 (lilting.ch summary, Computing).

Step-by-step: check exposure, patch, and hunt

Step 1: Inventory every PHP runtime

Goal: find PHP you did not know you had: hosts, containers, and PHP embedded inside vendor appliances.

Action: query packages on every Linux host, the PHP inside every running container, and the base images in your repos.

# Debian / Ubuntu: every PHP package that serves web traffic
dpkg-query -W -f='${Package} ${Version}\n' \
  'libapache2-mod-php*' 'php*-fpm' 'php*-cgi' 2>/dev/null

# RHEL / Alma / Rocky
rpm -q php php-fpm php-common 2>/dev/null

# Running containers
for c in $(docker ps --format '{{.Names}}'); do
  printf '%-30s ' "$c"
  docker exec "$c" php -r 'echo PHP_VERSION, PHP_EOL;' 2>/dev/null || echo "no php"
done

# Base images in your repos
grep -rnE '^\s*FROM\s+\S*(php|wordpress|drupal|joomla)' --include='Dockerfile*' .

Verification: you have a list of hosts, containers, and images with a version next to each. Do not forget appliances: the NCSC-NL product tracker lists products from Cisco, NetApp, Broadcom, and others that embed PHP, and Oracle and Palo Alto Networks published their own advisories.

Step 2: Read the version the web SAPI runs, not the CLI

Goal: confirm the patched code is what Apache or FPM actually loads.

Action: check the SAPI binaries and the distro changelog. Distros backport fixes without bumping the upstream number, so the changelog is the source of truth.

# FPM binary version (name varies by version)
php-fpm8.3 -v

# Is mod_php loaded at all?
apache2ctl -M 2>/dev/null | grep -i php

# Debian / Ubuntu: look for the CVE IDs in the package changelog
apt changelog php8.3 2>/dev/null | grep -m4 -E 'CVE-2026-10961[89]'

# RHEL family
rpm -q --changelog php-common 2>/dev/null | grep -m4 -E 'CVE-2026-10961[89]'

Verification: either the upstream version is at or above 8.2.35, 8.3.36, 8.4.27, or 8.5.12, or the changelog names both CVE IDs. Ubuntu 24.04 reporting 8.3.6 is fine if the package is 8.3.6-0ubuntu0.24.04.13 or later.

Step 3: Score the risk knobs

Goal: know which hosts are worst case while you schedule patching.

Action: read the settings each SAPI uses by pointing the CLI at that SAPI’s ini file. Do not drop a phpinfo() page on a production site to do this.

# Apache mod_php settings
php -c /etc/php/8.3/apache2/php.ini -i | grep -E \
  '^(session.upload_progress.enabled|memory_limit|fatal_error_backtraces)'

# FPM pool settings
php-fpm8.3 -i | grep -E \
  '^(session.upload_progress.enabled|memory_limit|fatal_error_backtraces)'

# CVE-2026-115560 precondition: config sets php_binary or php_serialize...
grep -rn 'serialize_handler' /etc/php* /etc/apache2 /etc/nginx 2>/dev/null
# ...and the app switches it back to php at runtime
grep -rn "serialize_handler" /var/www --include='*.php' \
  --include='.htaccess' --include='.user.ini'

Verification: an internet-facing mod_php host with session.upload_progress.enabled => On => On is your first patch. Any hit on a runtime ini_set('session.serialize_handler', 'php') means upload progress stays off even after patching.

Step 4: Patch and restart every worker

Goal: get the fixed code into memory, not just onto disk.

Action: upgrade the packages, then restart Apache and every FPM pool. A reload that keeps old workers alive keeps old code alive.

sudo apt update
sudo apt install --only-upgrade 'php8.3*' 'libapache2-mod-php8.3'
sudo systemctl restart apache2
sudo systemctl restart php8.3-fpm

# Containers: rebuild, do not just restart
docker compose build --pull --no-cache
docker compose up -d

Verification: rerun Step 2. Then confirm no worker predates the restart with ps -o pid,lstart,cmd -C php-fpm8.3 and ps -o pid,lstart,cmd -C apache2.

Step 5: Interim hardening if patching has to wait

Goal: remove the demonstrated paths until the upgrade lands.

Action: set these in the main php.ini or with php_admin_value, never in .user.ini where a site owner can undo them, then restart every worker.

; CVE-2026-109619 and CVE-2026-115560: removes the upload-progress producer
session.upload_progress.enabled = 0
; PHP 8.5 only: removes the fatal-error backtrace producer
fatal_error_backtraces = 0
; CVE-2026-109618: removes the predictable OOM, trades RCE for DoS risk
; memory_limit = -1

memory_limit = -1 is commented out on purpose. It removes the OOM the confirmed exploit relies on, but it also removes your guard against a single request eating the box, so pair it with a body-size cap at the proxy and only use it if you understand that tradeoff. On FPM pools that can absorb the cost, pm.max_requests = 1 gives every request a fresh worker so there is no stale state to consume (Corgea). For the network layer, FortiGuard published IPS and FortiWeb signatures, which ship non-blocking by default; the exact config is in PHP2Shell mitigation with Fortinet, and the general approach is in virtual patching on FortiGate.

Verification: php -c /etc/php/8.3/apache2/php.ini -i | grep upload_progress.enabled returns Off => Off.

Step 6: Hunt back to October 17

Goal: decide whether a host that was exposed before patching was hit. Patching does not evict an attacker who is already in.

Action: look for the noise the exploit makes: OOM errors, worker crashes, bursts of 500s on POST, odd session files, and shells spawned by the web server.

# 1. OOM errors (count per day)
sudo zgrep -h 'Allowed memory size' /var/log/apache2/error.log* \
  | awk '{print $2, $3}' | sort | uniq -c

# 2. Worker crashes: Apache children and FPM children
sudo zgrep -h 'exit signal Segmentation fault' /var/log/apache2/error.log* | wc -l
sudo zgrep -h 'SIGSEGV' /var/log/php8.3-fpm.log* | wc -l

# 3. Sources sending POSTs that ended in HTTP 500
sudo zgrep -h '"POST ' /var/log/apache2/access.log* \
  | awk '$9 == 500 {print $1}' | sort | uniq -c | sort -rn | head

# 4. Session files changed since Oct 17 that are large or contain PHP code
sudo find /var/lib/php/sessions -type f -newermt 2026-10-17 -size +64k -ls
sudo grep -lE '<\?php|system\(|base64_decode' /var/lib/php/sessions/* 2>/dev/null

# 5. Shells or downloaders running under the web server
ps -eo pid,ppid,user,lstart,cmd --forest | grep -E -A3 'apache2|php-fpm' \
  | grep -E 'sh -c|/bin/(ba)?sh|curl|wget'

Verification: a clean host shows no OOM spikes on unusual days, no segfault clusters, no session files with PHP code, and no shell children under the web server. Any hit means treat it as compromised: isolate, image, rotate every secret the PHP process could read, and rebuild. Amazon specifically warned defenders to start log review at October 17, not the patch date (The Hacker News). The CISA SIGMA rule alerts on exactly check 5: php-fpm, php-cgi, httpd, apache2, frankenphp, or lsws spawning shells or download tools.

Verification and validation

After patching and hardening, a host should pass all of these:

$ php-fpm8.3 -v | head -1
PHP 8.3.36 (fpm-fcgi) (built: ...)

$ apt changelog php8.3 | grep -c -E 'CVE-2026-10961[89]'
2

$ php -c /etc/php/8.3/apache2/php.ini -i | grep upload_progress.enabled
session.upload_progress.enabled => Off => Off

$ ps -eo user,cmd --forest | grep -E -A3 'apache2|php-fpm' \
    | grep -cE 'sh -c|curl|wget'
0

Distro-built packages show their own version string in the first line; what matters is that the changelog count is non-zero. For outside-in confirmation, a PHP-version fingerprint from your attack surface tool should show no internet-facing service below the fixed releases. Remember many sites hide the X-Powered-By header, so absence of a version is not proof of a patch.

Troubleshooting and gotchas

1. The version number says vulnerable, but the package is patched (or the reverse)

Cause: distributions backport the fix into old version strings. Ubuntu 24.04 still reports PHP 8.3.6 after the fix, and Debian bookworm’s fixed build is 8.2.35-1~deb12u1 (Debian tracker for CVE-2026-109618, CVE-2026-109619). The reverse also bites: php -v reports the CLI package, while Apache may load a different build. Fix: trust the package changelog and the SAPI binary, as in Step 2, not a scanner’s version banner.

2. The ini change “did not work”

Cause: the setting went into .user.ini or a per-directory override, the wrong SAPI’s php.ini was edited, or workers were reloaded instead of restarted. Diagnose: php -c /etc/php/8.3/<sapi>/php.ini -i | grep upload_progress for each SAPI and compare worker start times with ps -o lstart. Fix: set it in the SAPI’s main php.ini or with php_admin_value, then do a full restart. Do not substitute RLIMIT_AS or RLIMIT_DATA for memory_limit; they make mmap() fail, which sends PHP straight back down the vulnerable longjmp() path.

3. Fully patched, still exposed to CVE-2026-115560

Cause: the October 21 releases do not fix the serialize-handler vector. Diagnose: the two greps at the end of Step 3. Fix: keep session.upload_progress.enabled = 0 on any app that switches session.serialize_handler at runtime until PHP ships the next release, or remove the runtime ini_set() from the app.

References

• Censys: php2shell advisory, CVE-2026-109618 and CVE-2026-109619
• Corgea: how PHP’s longjmp() out-of-memory path became pre-auth RCE
• watchTowr: PHP2Shell FAQ
• Palo Alto Networks Unit 42: threat brief on CVE-2026-109618 and CVE-2026-109619
• Zend PHP Security Center: CVE-2026-109619
• Debian security tracker: CVE-2026-109618
• Debian security tracker: CVE-2026-109619
• Ubuntu security notice page: CVE-2026-109618
• NCSC-NL: php2shell affected product tracker
• Oracle Security Alert: CVE-2026-109618 and CVE-2026-109619
• Palo Alto Networks: impact of PHP2Shell on Palo Alto Networks products
• Plesk: PHP2Shell in PHP shipped with Plesk
• Varonis Threat Labs: PHP2Shell, one upload, full server
• Akamai: understanding PHP2Shell
• The Hacker News: Amazon logged a PHP2Shell attempt four days before disclosure
• TechTarget: PHP2Shell disclosure unravels after leaks
• The Hacker News: CISA confirms active exploitation of PHP2Shell
• BleepingComputer: CISA confirms PHP2Shell exploited in attacks
• lilting.ch: CVE-2026-115560 only hits apps that switch serialize_handler at runtime
• Computing: PHP discovers new RCE flaw, rules out emergency fix
• InfoSecMonkey: PHP2Shell mitigation with Fortinet