PHP2Shell: Which PHP Versions Fix It, Who Is Exploiting It, and What a Slow Patch Exposes

Tuesday, October 20, 2026, 3:20 p.m. UTC marks the day where two PHP vulnerability IDs are rated above 9. A Hacker News thread reported these a full day before anyone was supposed to see these vulnerabilities.

Seventeen hours later the first exploit attempt reaches the sensors of the Delft Threat Intelligence Lab, and by the time PHP ships its patched releases at 2 p.m. UTC on Wednesday, someone has already typed shell commands into a Delft honeypot. A shared host that took two more days to install those releases would have left every site on its servers exposed through the busiest hours of the attacks.

The suspects are two memory bugs inside PHP itself, booked together as PHP2Shell: CVE-2026-109618 and CVE-2026-109619. Neither one needs a login, a plugin or a careless line of application code, and the evidence against each starts with how it breaks.

Both CVEs are fixed in the same four releases, published together at 2 p.m. UTC on October 21, 2026. The php.net advisory lists every PHP installation serving web requests as affected, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, and rates mod_php highest because an unauthenticated request can start the attack before any application code runs.

Ask the build that serves web traffic, because a hosting server can carry many PHP builds side by side and the one your shell finds first may not be the one handing pages to visitors. The PHP selector in your hosting panel names the web build; on the command line, check the version and the upload progress setting the build reads.

php -v
php -i | grep session.upload_progress.enabled

The Delft Threat Intelligence Lab at TU Delft logged 35,076 PHP2Shell requests from 502 source IPs, spread over 232 networks in 60 countries, between 8:37 a.m. UTC on October 21 and 12:25 a.m. UTC on October 25. A third of those addresses (165) sent code or a downloader, and the busiest hour, 9 p.m. UTC on October 21, carried 2,116 requests from nine machines.

Their PHP error logs show how far the attempts got. Seventeen IPs drove PHP into the out-of-memory errors that leave a dangling pointer behind, and two of them reached the second step, where a worker reads that stale state. The droppers pointed at second stages, including a Mirai-derived DDoS bot, and 888 requests from 104 IPs carried session deserialization gadgets, among them chains built from Laravel, Monolog, Guzzle and Symfony classes that ship inside ordinary Composer projects.

Picture a shared host that installs the patched PHP build almost two days after PHP published the fix. Measured against Delft's data, that gap would cover the busiest hours of exploit traffic, including the 2,116-request peak at 9 p.m. UTC on October 21, and every site on the server would sit out the same window together, because one PHP build serves them all.

A careful host would also switch session upload progress off server-wide, the stopgap php.net recommends keeping even after patching, and restart every worker so the setting takes hold. Two commands tell you where your own server stands: when its PHP binary last changed, and whether any of Delft's senders appear in your logs.

stat -c '%z %n' "$(command -v php)"
awk 'NR==FNR{a[$1];next} ($1 in a)' delft-ips.txt access_log | wc -l

Method: we ran the second command on October 24, 2026, matching the 499 IPv4 sender addresses in Delft's published table against our site's access logs from September 30 to October 25, 2026. Request bodies are not logged, so a PHP2Shell payload cannot be seen directly.

It found a few lines from Delft's senders, all weeks before the leak and none carrying exploit traffic. After the leak none of them reached our site, and no request line or user agent in our logs named a PHP2Shell tool.

For a business on shared hosting, this is what we learned: your host decides when the patch is installed, so ask yours for the install time in writing and compare it with PHP's October 21 release.

php.net calls updating the only complete fix. Its interim settings buy time when a host or a frozen server makes that impossible today, and each one needs every worker restarted, because ini_set() and an FPM .user.ini apply too late to help. A follow-up informational advisory on October 23 recommends keeping upload progress off until the next bugfix release, to cover a third, less likely route tracked as CVE-2026-115560.

PHP 8.1 and older get no official release, only minimal source backports, so a site stuck on one of those branches faces a rebuild decision more than a patch decision. Our secure or replace check walks through that choice, the WordPress rebuild comparison covers what moving costs, and the threat data page tracks what reaches small business sites every week.

• PHP Group: Critical remote code execution vulnerabilities, update now
• php-src advisory GHSA-w8hw-w9fx-j79w: CVE-2026-109618
• php-src advisory GHSA-6wmf-4rv5-p3rp: CVE-2026-109619
• PHP Group: Supported versions and end-of-life dates
• Delft Threat Intelligence Lab: PHP2Shell in the Wild, live exploitation data

PHP is maintained by the PHP Group, whose security team published both advisories. The live exploitation dashboard is run by the Delft Threat Intelligence Lab at Delft University of Technology and refreshes every five minutes.

Sources: php.net, advance notice of the security release; php.net, critical remote code execution vulnerabilities advisory; php.net, informational advisory on session upload progress; Delft Threat Intelligence Lab, PHP2Shell in the Wild.