PHP2Shell: Two Critical PHP Flaws Allow Unauthenticated Takeover of Web Servers

PHP shipped emergency releases on 21 October to fix two remote code execution flaws that let an attacker run code on a web server without logging in. The pair, tracked as CVE-2026-109618 and CVE-2026-109619 and nicknamed PHP2Shell, are each rated 9.2 on the CVSS v4.0 scale. Exploitation attempts were already being recorded before the fixes were public.

The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP's advisory says updating is the only complete fix, and that every PHP worker has to be restarted after the update for it to take effect.

What the two flaws are

Both bugs sit in how PHP sets up and tears down a web request, which is why application code offers no protection.

• CVE-2026-109618, out-of-memory corruption. If PHP runs out of memory part of the way through setting up a request, internal request data can be left half-built. The cleanup code that runs afterwards may then treat that invalid data as valid.
• CVE-2026-109619, stale global state. Internal state that belongs to one request can survive after the memory behind it has been freed. A later request handled by the same PHP worker may then act on that leftover state before it is reset.

PHP's advisory describes a demonstrated exploit in which a single unauthenticated request triggers the attack before any application code runs. It rates installations using Apache with mod_php as the highest risk.

Who is exposed

According to watchTowr's analysis, every PHP installation that serves web requests is in scope: PHP-FPM, Apache mod_php, php-cgi, LiteSpeed and FrankenPHP. That includes sites built on PHP-based content management systems and e-commerce platforms as well as custom applications. Palo Alto Networks put the number of potentially vulnerable instances at 22.6 million.

Older PHP branches are the harder problem.

• PHP 8.2 to 8.5: fixed in the 21 October releases. PHP 8.2 reaches end of life on 31 December 2026.
• PHP 7.4, 8.0 and 8.1: no official release. The PHP security team published minimal source backports, and some Linux distributions and long-term support vendors ship patched packages.
• PHP 7.3 and older, including PHP 5: no fix at all. watchTowr confirmed these branches are affected. The only remedy is to move to a supported version.

The flaws also reach beyond web hosting. Palo Alto Networks confirmed that all PAN-OS and Panorama versions are affected and had not shipped fixed releases at the time of Help Net Security's 22 October update. Fortinet and Cisco said they were checking 12 and 31 products respectively and had not confirmed any as vulnerable.

Exploitation started before the patch

The disclosure did not go to plan. Details of the flaws leaked on social media on 20 October, ahead of the coordinated release, and PHP brought its security release forward to 14:00 UTC on 21 October.

Amazon Threat Intelligence said its MadPot honeypots recorded an exploitation attempt on 17 October, four days before the public advisory, from an IP address tied to a commercial anonymisation service. Amazon said it does not know how the attacker obtained the details early. watchTowr reported exploitation in the wild through its honeypot network from 21 October. Cloudflare said it saw tens of thousands of exploit attempts within 45 minutes of the news breaking, rising to millions by the evening of 21 October.

Reports still differ on how much of that activity succeeds against real systems. Bitdefender said it had seen no exploitation attempts in its own telemetry as of 22 October, and CISA had not added either CVE to its Known Exploited Vulnerabilities catalogue by that date.

Found with AI

The flaws are also notable for how they were found. According to Fortune, Calif, a California firm that does AI-assisted red-teaming, found the first issue on 1 August using an OpenAI model and reported it through OpenAI's Patch the Planet initiative to the PHP Foundation. Wiz found the vulnerabilities independently later in August. Wiz researchers said the underlying code had been in PHP for more than a decade, and that AI changed how quickly the weakness could be turned into a working exploit rather than whether it existed.

Kevin Beaumont, a security researcher, said the situation "will lead to a mass of incidents".

What to do now

1. Find every PHP installation, starting with internet-facing servers, and put those running Apache mod_php first. Include appliances and embedded systems that ship PHP inside them.
2. Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to your distribution's patched package, and restart every PHP worker afterwards.
3. On PHP 8.1 or older, ask your vendor for a backported package or plan an upgrade. On PHP 7.3 or older there is no patch to wait for.
4. If a server cannot be patched yet, restrict its exposure to the internet. The UK's NCSC advises taking unpatchable systems offline. Cloudflare has deployed web application firewall rules for known exploit paths, available on all plans including the free tier.
5. Treat configuration changes as a stopgap only. PHP's advisory lists setting session.upload_progress.enabled=0 in php.ini or the FPM pool (not through ini_set() or .user.ini) and, on PHP 8.5, fatal_error_backtraces=0. These block the confirmed paths but not other variants, and PHP says they do not make an installation safe.

Searchlight Cyber has released an open-source scanner, php2shell-scanner, that tests hosts for both flaws. Hosts that were exposed before patching should be checked for signs of compromise, since attempts began before the fix was available.