PHP2Shell: two critical PHP vulnerabilities and what to do now

Two critical PHP vulnerabilities that allow unauthenticated remote code execution (RCE) leaked before their embargo ended, and the PHP project shipped emergency security releases on 21 October 2026. Huntress calls the pair “PHP2Shell”, and they can be triggered before any of your application code runs. This post covers what is affected, how to patch, what to do if you cannot patch yet, and how to look for signs of compromise.

What happened

The PHP security team rates both issues as critical; according to Huntress, the CVSS v4.0 score is 9.2.

CVE	Advisory	In short
CVE-2026-109618	GHSA-w8hw-w9fx-j79w	Out-of-memory handling can interrupt PHP while internal request data is only partially initialised. Request cleanup may then treat the invalid data as valid.
CVE-2026-109619	GHSA-6wmf-4rv5-p3rp	Request-owned internal state can survive after its memory has been freed. A later request handled by the same worker may use that stale state before normal initialisation resets it.

The attack works over HTTP and requires no authentication. PHP says a single unauthenticated request to mod_php can trigger the attack before any application code runs. Full RCE was validated against mod_php with default input and memory limits, in a normal prefork setup with multiple workers. A successful attack means code execution with the privileges of the web worker.

Affected setups: per PHP, every installation that serves web requests is at risk, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. The risk is highest for mod_php.

Timeline

• 20 October: a Hacker News post claimed both flaws were headed for public disclosure. It was removed, but screenshots spread. watchTowr confirmed the leak.
• 20 October: PHP published an advance notice and scheduled the releases for 21 October at 14:00 UTC, saying it could release sooner if details went public.
• 21 October: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 were released.

Update (25 October): According to Datadog, AWS saw exploitation attempts on 17 October, before disclosure, and active exploitation and broad scanning have been reported since 21 October. Our PHP2Shell detection guide explains how to tell whether your server was hit.

As of 21 October, Huntress reports no exploitation across its customer base and no known public exploit code. Some sources claim attacks are emerging, but this has not been independently verified. A short exploitation video was posted and then removed. The picture can change quickly once details are public, so there is no reason to wait.

Which version to move to

Branch	Fixed version	Note
8.5	8.5.12	Preferred where feasible
8.4	8.4.27
8.3	8.3.36
8.2	8.2.35	Reaches end of life on 31 December 2026
8.1 and older	—	No longer updated by the PHP project

Minimal source-level backports were published for PHP 7.4, 8.0 and 8.1. Linux distributions and LTS vendors received the patches in advance, so a fixed package may arrive without a change in the upstream version number. Check your distribution’s security notice rather than the version string alone.

Updating, step by step

1. Build an inventory. List not only your own applications but also control panels, CMS platforms, PHP bundled inside vendor software, and container images. Put internet-facing systems first.

2. Confirm the version the web server actually runs. php -v on the command line can differ from the PHP behind your web server. If you use PHP-FPM, check that binary too:

php -v
php-fpm8.4 -v      # the name varies by distribution: php-fpm, php84-php-fpm…

3. Update packages and restart the workers. On a Debian/Ubuntu-based server:

sudo apt update
sudo apt install --only-upgrade 'php8.4*'
sudo systemctl restart php8.4-fpm   # with mod_php: sudo systemctl restart apache2

The restart matters: as long as old worker processes stay in memory, the fix is not active.

4. Rebuild container images. Move the base image to the fixed tag, rebuild, and roll the running pods. Do not rely on latest; verify the PHP version inside the image.

5. Ask your hosting provider. On shared hosting or a managed platform, get written confirmation of when the update was applied.

If you do not manage your own servers, or have no time to build the inventory, our Server & IT Management team can run this for you.

If you cannot update yet: interim mitigations

The PHP project is explicit: there is no complete mitigation; updating is the only safe choice. The settings below only narrow some known attack paths and buy time until you update.

For CVE-2026-109618:

• Set memory_limit=-1, preferably with php_admin_value in the FPM pool or the Apache configuration. It sounds backwards, but the goal is to close the in-PHP out-of-memory path that triggers the bug. Enforce memory limits at the container or cgroup level instead, and do not substitute RLIMIT_AS or RLIMIT_DATA.
• Keep post_max_size low: 8M if you do not need uploads, 32M if you do. Keep upload_max_filesize below it.

For CVE-2026-109619:

• Set session.upload_progress.enabled=0 and restart every worker. Do it in php.ini, the FPM pool or the server configuration; do not rely on ini_set() or an FPM .user.ini file.
• On PHP 8.5, also set fatal_error_backtraces=0.

An example FPM pool configuration:

; /etc/php/8.4/fpm/pool.d/www.conf — only until you update
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 4M
php_admin_flag[session.upload_progress.enabled] = off
; PHP 8.5: php_admin_flag[fatal_error_backtraces] = off

If you run an unsupported PHP version, put the server behind a VPN or WAF, or take it off the internet. Unofficial researcher patches are circulating, but their effectiveness has not been evaluated.

How to look for signs of compromise

At the time of writing there are no confirmed indicators of compromise (IOCs). The strongest signal Huntress suggests is PHP worker processes spawning unexpected child processes:

• Parent processes: php-fpm, php-cgi, php-cgi.exe, httpd, apache2
• Shells: sh, bash, cmd.exe, powershell.exe
• Interpreters: python, perl
• Download and network tools: curl, wget, nc, certutil.exe
• On the command line: /dev/tcp/, fsockopen, mkfifo
• Reconnaissance run from a web server: whoami, id, uname -a, ipconfig

On Linux servers without EDR, running Florian Roth’s process-watcher in observe mode is recommended. Sigma and YARA rules will follow once technical details are public.

If you suspect a compromise: isolate the server, preserve the web server and PHP logs, and look for new files and webshells in the web root, new cron jobs, scheduled tasks and new accounts. Our Cybersecurity team can help with incident response and forensics.

The lesson

PHP2Shell shows again that patch management is a security process, not a maintenance chore. There was less than a day between the leak and the fix. Prepared teams spent it updating; the others spent it working out where their servers were.

• Inventory: see which PHP runs on which server from one place.
• Supported-version policy: put PHP 8.2’s end of life on 31 December 2026 in the calendar now.
• Immutable images: pin versions in containers and automate rebuilds.
• Monitoring: alert when a web worker spawns a child process.

Our Secure Software & DevSecOps page explains how to build these steps into your delivery process.

Conclusion

PHP2Shell is a pair of critical flaws that can be triggered without authentication and before application code runs. The work is clear: update PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 and restart the workers, apply the interim mitigations if you cannot update yet, and keep unsupported servers off the internet. Then check your logs and process tree for signs of compromise.

To build your server inventory, plan the update or investigate a suspected compromise, get in touch.

Sources: PHP security announcement, 21 October 2026 and Huntress: PHP2Shell. Information is current as of 21 October 2026.

Bu yazı Türkçe olarak da mevcut — Türkçe oku →