PHP2Shell: check, fix and mitigate

How to fix PHP2Shell on your platform

Updating PHP is the only complete fix. Install your vendor's security update, then restart every PHP process: running workers keep the vulnerable code in memory until they restart.

sudo apt update
sudo apt install --only-upgrade $(dpkg -l 'php*' | awk '/^ii/{print $2}')
sudo systemctl restart 'php*-fpm.service' apache2   # restart what you run
apt changelog php8.3-fpm | grep -E 'CVE-2026-10961[89]'   # verify

sudo dnf updateinfo list --cve CVE-2026-109618   # shows the fix for your stream
sudo dnf upgrade 'php*'
sudo systemctl restart php-fpm httpd

yum -y install https://extras.getpagespeed.com/release-latest.rpm
yum --enablerepo=getpagespeed-extras-php74 upgrade 'php-*'   # or: yum upgrade 'php74-php*'
systemctl restart php-fpm

sudo dnf upgrade 'php*'
sudo systemctl restart php-fpm   # SCL: systemctl restart php83-php-fpm

sudo apt update && sudo apt install --only-upgrade php8.3-fpm php8.3-cli
apt changelog php8.3-fpm | grep -E 'CVE-2026-10961[89]'

yum update 'ea-php*'      # or: dnf update 'ea-php*'
/scripts/restartsrv_apache_php_fpm

plesk installer --select-release-current --upgrade-installed-components

Mitigate PHP2Shell at the NGINX edge

NGINX cannot fix a bug inside PHP, but it decides what reaches PHP. We tested each of these controls on Rocky Linux 10 with NGINX 1.30 and PHP-FPM 8.3. Each was checked against the public proof-of-concept request shape and against normal uploads. Use them to buy time and to harden patched servers too.

1. Cap the request body size

This is the strongest single control. NGINX counts de-chunked bytes as they arrive and rejects an oversized body with 413 before PHP parses anything. In testing, the 5 MB proof-of-concept body was cut off at 1 MB, with this log line: client intended to send too large chunked body.

location ~ \.php$ {
    client_max_body_size 1m;          # the smallest size your uploads need
    fastcgi_request_buffering on;     # the default: never stream bodies to PHP
    include fastcgi_params;
    fastcgi_pass unix:/run/php-fpm/www.sock;
}

2. Reject chunked multipart uploads

Browsers always send Content-Length with form uploads, but the public exploit uses chunked encoding. Refuse that combination for PHP before NGINX reads the body:

# http {} context, for example /etc/nginx/conf.d/00-php2shell.conf
map $http_content_type      $p2s_multipart { default ""; "~*^multipart/form-data" "m"; }
map $http_transfer_encoding $p2s_chunked   { default ""; "~*chunked" "c"; }

# inside the PHP location {}
set $p2s_block "$p2s_multipart$p2s_chunked";
if ($p2s_block = "mc") { return 411; }

Tested results: a chunked multipart request got 411, while normal multipart and urlencoded posts got 200. This rule covers HTTP/1.1 only. HTTP/2 has no chunked encoding, and we did not test it there, so rely on the body cap for HTTP/2.

3. Turn off session upload progress the right way

A common suggestion is fastcgi_param PHP_VALUE "session.upload_progress.enabled=0". It does not work. In our test PHP still wrote upload_progress_* data to the session file. The setting has to be applied at the admin level:

; PHP-FPM pool, e.g. /etc/php-fpm.d/www.conf or /etc/php/8.3/fpm/pool.d/www.conf
php_admin_flag[session.upload_progress.enabled] = off

fastcgi_param PHP_ADMIN_VALUE "session.upload_progress.enabled=0"; also worked in testing. Prefer the pool setting: the advisory warns that per-request INI values from the frontend which raise a diagnostic are themselves a CVE-2026-109619 trigger. Audit what your NGINX sends:

grep -rn 'PHP_VALUE\|PHP_ADMIN_VALUE' /etc/nginx /etc/php-fpm.d /etc/php 2>/dev/null

4. Block the exploit fields with ModSecurity

For a request-body filter, the GetPageSpeed nginx-module-security package (ModSecurity v3) inspects multipart field names, including in chunked bodies. These rules returned 403 for a PHP_SESSION_UPLOAD_PROGRESS field, a 2,000-byte field name and a NUL byte, and 200 for normal uploads:

# /etc/nginx/php2shell.rules
Include /etc/nginx/modsecurity.conf
SecRule ARGS_NAMES "@rx (?i)^PHP_SESSION_UPLOAD_PROGRESS$" \
  "id:1000100,phase:2,t:none,deny,status:403,log,msg:PHP2Shell-upload-progress-field"
SecRule ARGS_NAMES "@gt 1024" \
  "id:1000101,phase:2,t:none,t:length,deny,status:403,log,msg:PHP2Shell-oversized-arg-name"
SecRule ARGS|ARGS_NAMES "@rx \x00" \
  "id:1000102,phase:2,t:none,deny,status:403,log,msg:PHP2Shell-nul-byte"

# nginx.conf (top level)
load_module modules/ngx_http_modsecurity_module.so;

# inside the PHP location {}
modsecurity on;
modsecurity_rules_file /etc/nginx/php2shell.rules;

The package's base modsecurity.conf already turns on strict multipart parsing, which rejected malformed and empty-name multipart bodies with 400. Install it with dnf install nginx-module-security from the GetPageSpeed repository. NAXSI (nginx-module-naxsi) can block the field name too, but it has no length check, so ModSecurity is the better fit here.

Temporary php.ini mitigations, and why they are not enough

If you cannot update today, the PHP security team lists these settings. Apply them administratively (php.ini or the FPM pool, not per request), then restart every worker. Each one closes a single known path. None of them is a fix.

; /etc/php.ini or /etc/php/*/fpm/php.ini until you can patch
session.upload_progress.enabled = 0
fatal_error_backtraces = 0   ; PHP 8.5 only

How PHP2Shell works

Both flaws are about PHP trusting memory it should not trust after a request is cut short. Neither needs a vulnerable application: the bug is in the engine and in request startup.

CVE-2026-109618: remote code execution via out-of-memory corruption

When PHP runs out of memory it calls longjmp() and abandons whatever it was doing. During multipart body parsing, some request memory is reachable before it is fully initialised. An out-of-memory error at that moment leaves it half-built, and the request shutdown code then reads it as if it were valid. An attacker who shapes the request controls that memory.

Attackers can reach the memory limit while staying inside PHP's apparent limits: a multipart body without a usable declared length can slip past the first post_max_size check, a single part can carry unlimited headers, and empty file fields still build metadata arrays. The fix replaces longjmp() with a deferred soft limit plus a hard _exit().

CVE-2026-109619: remote code execution via stale global state

A PHP worker keeps global state (error, session, decoder and extension state) that can point into one request's memory. If a fatal error or memory exhaustion interrupts an operation before its reset runs, the request heap is freed while that global still points at it. The next request on the same worker can touch the stale pointer before normal initialisation replaces it. This is a use-after-free, and with a prepared heap it becomes code execution.

The advisory confirms two consumers that run before initialisation. The first is session upload progress, which is enabled by default and works without the application ever calling session_start(). The second is any INI diagnostic raised before request startup, for example a deprecated value passed through Apache php_value, .htaccess, or a frontend's FastCGI PHP_VALUE parameter. Silencing errors with error_reporting, @ or display_errors does not help, because PHP touches the stale state before it decides whether to report anything.

Which PHP setups are exposed

Source: the PHP security team's analysis in the two advisories. "Conditional" means exploitable when the application or configuration supplies the missing step, not that the setup is safe.

Detect PHP2Shell exploitation attempts

The exploit is noisy before it is reliable: attackers usually need several requests to line up the heap, and failed guesses crash workers. Look for these traces.

Out-of-memory errors with no script location

grep -rh 'Allowed memory size of' /var/log/php*-fpm/ /var/log/php-fpm/ /var/log/httpd/ /var/log/apache2/ 2>/dev/null \
  | grep 'Unknown on line 0' | tail -n 20

PHP workers dying on segmentation faults

journalctl --since '2026-10-17' | grep -E 'php.*(SIGSEGV|signal 11|Segmentation fault)' | tail -n 20
grep -rh 'exited on signal 11' /var/log/php*-fpm* /var/log/php-fpm/ 2>/dev/null | tail -n 20

Crashing workers seen from NGINX

When a PHP-FPM child dies mid-request, NGINX logs it and returns 502. A burst of 502s on POSTs from one address is a strong signal:

grep -E 'upstream prematurely closed|Connection reset by peer\) while reading response header' /var/log/nginx/error.log | tail -n 20
awk '$6 == "\"POST" && $9 == 502 {print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

The public proof of concept sends chunked multipart POSTs with megabyte-sized field names and a PHP_SESSION_UPLOAD_PROGRESS field. Access logs do not record request size by default. Add $request_length to your log_format to spot oversized uploads in the future.

Shells spawned by the web server

ps -eo user,pid,ppid,etime,cmd --forest | grep -E -B1 '(sh|bash|python|perl|nc|curl|wget) ' | grep -E -A1 'php|httpd|apache'

Also look for outbound connections owned by the PHP user, new files in upload and cache directories, and strings like /dev/tcp/, fsockopen or mkfifo in recently changed PHP files. Clean logs do not prove a host is safe. If you cannot rule out a compromise, rotate its credentials and rebuild it.

PHP2Shell timeline

1. October 17, 2026Amazon's MadPot honeypots record an exploitation attempt, four days before disclosure.
2. October 20, 2026Details leak publicly and the PHP project announces an emergency security release for the next day.
3. October 21, 2026PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 ship with the two advisories. Source-only backports appear for 7.4, 8.0 and 8.1. Researchers publish technical write-ups, and CDN vendors roll out WAF rules.
4. October 22, 2026GetPageSpeed publishes patched PHP 5.6, 7.0, 7.3, 7.4 and 8.0 builds for CentOS 7. Public scanners appear, and attacks spread.
5. October 23, 2026This page last updated.

Need hands-on help?