PHP2Shell Attackers Got Real Shells on Real Servers. Now the Clock Is Running.

Key points

• On October 24, 2026, a researcher's honeypot servers recorded 35 working shells launched across three machines, the first confirmed real-world code execution tied to the PHP2Shell flaws.
• CVE-2026-109618 and CVE-2026-109619 affect every PHP installation that handles web requests, covering a large share of the world's websites.
• CISA added both flaws to its Known Exploited Vulnerabilities catalogue on October 26, 2026.
• Safe versions are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35, released October 21, 2026.
• No follow-on malware was observed in the honeypot sessions, but the attack chain was fully functional.

For weeks, security teams had watched hundreds of millions of probes hitting PHP servers. The probes were alarming. What nobody had confirmed, until the weekend of October 25, was whether any of them had actually worked.

That changed when Adel Karimi, a researcher at Perplexity who runs honeypots (decoy servers designed to look like real targets and record attacks), published his findings from October 24. Across three honeypots, attackers launched 35 shells, meaning they successfully opened a command prompt on his servers and could run any instruction they chose. Two source addresses did most of it: one produced three shells on a single machine, another spawned 32 across all three.

How did the attack work?

The attackers used a four-step chain of web requests. Some requests ate up PHP's available memory; others read back fragments of that memory; the final request used what it had learned to execute a shell command. The sequence matched a publicly available proof-of-concept exploit circulating online.

Karimi noted the limits of his findings. His honeypots ran Apache with mod_php using a single worker process, conditions that make exploitation easier than on most production servers. "The evidence demonstrates this chain on the intentionally favorable single-worker mod_php profile; it is not a measurement of exploit reliability on other worker counts or PHP builds," he wrote. No second-stage payload was downloaded during any of the sessions.

Marcus Hutchins, a principal researcher at security firm Expel, called the results "by far the highest quality confirmation of in-the-wild PHP2Shell exploitation I've seen so far."

What exactly is PHP2Shell?

PHP is a programming language that powers a large fraction of the world's websites, including systems built on WordPress and many custom platforms. CVE-2026-109618 corrupts memory when PHP runs out of it; CVE-2026-109619 exploits stale internal request state. Both allow an attacker to run code on a vulnerable server without a password or account, and both are rated critical.

PHP patched both flaws on October 21, before some attack attempts began. CISA, the US Cybersecurity and Infrastructure Security Agency, issued an alert the same day urging immediate patching. As of the morning of October 26, first reported by SecurityWeek, the agency had not yet formally listed the flaws as exploited in the wild, though it added both CVEs to its catalogue later that day.

We first covered these flaws on 21 October 2026, and our story "PHP flaws dubbed 'PHP2Shell' hit a European government, with AI doing the dirty work" showed how fast the window between disclosure and real compromise can close.

Affected configurations include Apache with mod_php, PHP-FPM, php-cgi, FrankenPHP, and LiteSpeed. CISA singles out Apache with mod_php as the highest-risk setup.

The thing worth watching now isn't whether exploitation is possible: Karimi's data settled that. It's whether operators of unpatched servers recognise that the probe-to-shell gap has already closed. Check which PHP version your hosting provider is running. Below the safe versions above, update immediately. Managed hosting users should ask their provider directly whether the patch is in place.