PHP2Shell: Which PHP Versions Are Fixed and What to Do If You Can't Patch Yet

PHP released versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 on October 21 to fix two vulnerabilities that allow unauthenticated remote code execution, per the PHP project. Both are rated 9.2 on CVSS v4.0. Researchers call the pair PHP2Shell. The CVE numbers are CVE-2026-109618 and CVE-2026-109619.

The advisory covers nearly every way PHP serves web traffic. It lists PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed as affected. The first flaw is in out-of-memory handling, which can interrupt PHP while request data is half set up, after which cleanup treats the bad data as valid. The second lets internal state from one request survive into the next request on the same worker, through the session upload progress feature. PHP says mod_php setups face the most danger, because a single unauthenticated request can trigger the attack before any application code runs.

The end-of-life rows are the problem. PHP 8.1 and older no longer get releases from the PHP project. Its security team published minimal source backports for 7.4, 8.0 and 8.1, and Linux distributions and long-term support vendors got the patches in advance. Mallory, a security firm, counted about 884,000 internet-facing hosts whose banners reported PHP 8.1 or older on October 20, per The Hacker News. That is 59% of the roughly 1.5 million hosts that report a version at all. Banners prove nothing about a given host. They are still a rough map.

Attackers did not wait for the announcement. Amazon's threat intelligence team says its MadPot honeypots recorded an exploitation attempt on October 17, four days before disclosure, from an address tied to a commercial anonymization service, per Help Net Security. Amazon advises starting any investigation from October 17. Cloudflare's chief executive said the company saw thousands of attempts in the ten hours before the announcement and millions afterward, per The Register. Cloudflare has pushed WAF rules for known exploit paths to every plan, including free ones.

How much of that traffic works is unclear. Dataminr says observed activity is scanning and non-working exploits so far, with no known compromises, and most public proof-of-concept code crashes PHP workers instead of running code. CISA had not added either CVE to its Known Exploited Vulnerabilities catalog as of October 23.

PHP is also embedded in products people don't think of as PHP. Palo Alto Networks says all PAN-OS and Panorama versions are affected, with no fixed release yet at the time of its update. Fortinet and Cisco were checking dozens of products. Control panels and appliances that bundle their own PHP need their own updates.

What if a server can't be patched today? PHP lists interim steps and says they "do not make an installation safe." Set memory_limit=-1 where applications can't override it. Lower post_max_size to 8M without uploads or 32M with them. Turn off session.upload_progress.enabled in php.ini or the FPM pool, then restart every worker. Setting it with ini_set() or .user.ini does not count. The UK's National Cyber Security Centre goes further and suggests taking offline any system that can't be fixed right away.

There is a third advisory. On October 23 PHP described CVE-2026-115560, another session-handling flaw that needs a specific configuration, and it recommends session.upload_progress.enabled=0 until the next regular release.

For detection, watch for php-fpm, php-cgi, httpd or apache2 starting shells, interpreters or download tools, and check web roots and cron jobs for new files since October 17. Searchlight Cyber published an open-source scanner that tests a host for both CVEs. Our Artex piece on South Korea's bank hacks covers how quickly automated tools now turn a disclosure into attacks.