PHP2Shell takes a server in one request; 2.6 million hosts are exposed

01One worker, many strangers: how a single request takes over

Picture how a PHP site serves traffic. The web server keeps a pool of PHP workers, long-lived processes that each handle request after request, often thousands before they are recycled. For every request a worker does three things. It sets up: reads the headers, cookies and uploaded body into memory and builds the request’s internal state. It runs the application’s script. Then it cleans up, freeing that memory so it is ready for the next stranger. PHP2Shell is two bugs in the first and third steps, so the application’s own login check and input validation never get a say.

In PHP’s words, CVE-2026-109618 is out-of-memory handling that “can interrupt PHP while internal request data is only partially initialized”, after which “request cleanup may then treat the invalid data as valid.” CVE-2026-109619 is request state that “can survive after its backing memory has been freed”, so “a later request handled by the same worker may use that stale state before normal initialization resets it.”¹ Engineers call the second a use-after-free.⁴ Memory is handed back and handed out again while an old pointer still trusts it, and an attacker who decides what gets written there next decides what the worker does with it.

PHP rates the risk highest under Apache mod_php, “with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs.”¹ The first confirmed compromise in the wild matched that profile exactly: a honeypot running Apache with mod_php on PHP 8.4.26, with a single worker.⁸ PHP has not published why mod_php is worse than PHP-FPM, and we will not guess at the internals. What matters is that a mod_php server needs nothing from the application to be taken.

02The race: probed four days early, listed by CISA in five

The disclosure did not go to plan. On 17 October Amazon’s MadPot honeypot logged an attempt from 103.216.220[.]92, an address Amazon tied to “a commercial anonymization network”. A spokesperson said there was “no evidence” the probe was benign.⁵ On 20 October PHP pre-announced a release for 21 October at 14:00 UTC, reserving the right to go earlier “should details of either vulnerability become public”.¹ The Hacker News reports that the coordinated date had been 22 October and was brought forward a day, and that the CVE identifiers and proof-of-concept code leaked ahead of time.⁵

Release day ran ahead of the release. Amazon saw its first attempt at about 02:00 UTC. ELLIO logged its first PHP2Shell request at 08:36 UTC, less than an hour after Chainguard published container images with the fix. ELLIO says Chainguard “unilaterally broke the embargo”; the PHP Foundation says Chainguard had received the patch in advance “so its users could update the moment the vulnerabilities were disclosed.”⁵ Cloudflare’s CTO said it was seeing attacks on both flaws before the patches shipped.⁷ The web host Pantheon had blocked more than 60,000 suspicious requests by that evening.⁵

03Why nobody can count the exposure, and the one thing every count agrees on

Four public counts appeared within a week, and the largest is 64 times the smallest. VulnCheck found 2,608,039 internet-facing PHP hosts and judged 2,607,985 of them, 99.998%, vulnerable or likely vulnerable.⁹ Modat counted 4.38 million internet-facing PHP services on 20 October.⁵ VirusTotal put exposed PHP hosts at over 5.1 million.⁷ Qualys found 167 million PHP package installs across more than 10,000 customers, 73% of them on internet-facing assets, and only 199,000 patched in the first 12 hours.⁴

They are not contradicting each other. A host is one internet address that answers a web request. A service is an address and a port, so a server answering on two ports counts twice. An install is a PHP package an agent found on a scanned machine, including internal servers, containers and machines carrying two PHP versions. And a version banner is not a vulnerability: VulnCheck counts the 1,133,000 hosts that show no version as likely vulnerable, and notes that Linux distributions backport fixes without changing the version string.⁹ The scanners overstate on a patched Debian box and understate wherever the banner is hidden.

That is the real problem. The PHP project fixed 8.2 to 8.5. For 7.4, 8.0 and 8.1 it published “minimal source-backports” for people who build PHP themselves; there is no release to install.¹ PHP 7.3 and older, PHP 5 included, get no fix at all.³ VulnCheck counts more than 700,000 internet hosts on PHP 3.x to 7.3.⁹ For those, the patch was never coming.

04The PHP you did not know you were running

Most organisations do not run PHP; they run something built on it. VulnCheck could identify the application on part of the exposed estate, and calls every figure a floor.⁹ WordPress alone is more than all the others combined.

The harder inventory is the PHP inside things you bought. Palo Alto Networks lists PAN-OS and Panorama 10.2, 11.1, 11.2, 12.1 and 12.2 as affected through the management web interface, both the HTTPS console and the XML API; GlobalProtect is not. Its first hotfixes were 10.2.18-h13, 11.1.16-h4 and 11.2.10-h16, with 17 more due between 27 and 30 October. Cisco lists Ultra-Reliable Wireless Backhaul, Expressway and Duo Access Gateway (fixed in 3.2.0) as affected, with 11 products and services under investigation. Fortinet’s FG-IR-26-186 has four products under investigation (FortiDDoS, FortiClient Cloud Services, FortiSOAR and FortiSOAR PaaS) and 43 not affected, FortiOS and FortiWeb among them.¹²

05What to do, in order

PHP’s release notes put it in one line: “There are no complete mitigations, updating is the only safe choice.”² Everything below follows from that.

1. Find every PHP. Start with what faces the internet: websites, portals and shared-hosting accounts, then appliance management consoles, then container images and their base layers, then anything a vendor hosts for you. Read the version from the package manager, not the banner, because distribution backports keep the old version string.⁹
2. Patch, then restart every worker. Move to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your distribution’s fixed package, and restart every PHP-FPM pool, Apache running mod_php, LiteSpeed and FrankenPHP process. A fixed binary on disk does nothing for a worker still running the old code in memory.³ Rebuild and redeploy images rather than patching running containers.
3. Decide about end-of-life PHP this week. On 7.4, 8.0 or 8.1: take a backported package from your distribution or an extended-support vendor, build PHP’s minimal source backport, or upgrade. On 7.3 or older there is no fix; upgrade or take it off the internet. While you decide, PHP’s interim settings (session upload progress off in php.ini, a low post_max_size, a container memory limit, then a restart) “reduce exposure to specific attack paths but do not make an installation safe.”¹ A web application firewall rule is a bridge too; Cloudflare described its own as temporary.⁷
4. Assume you were probed, and look. Anything internet-facing and unpatched after 21 October deserves the forensic triage CISA asks of federal agencies.¹¹ Look for new PHP files in web roots, since one recorded attempt tried to plant a web shell through PHP’s session upload-progress feature.⁹ Look for workers crashing on out-of-memory errors, and for outbound connections from web servers. Rotate session secrets and API keys held by affected applications, because the confirmed exploit read cookie data out of worker memory.⁸