Two new CTI labs let you run the attack, then catch it in your logs.
By the Container 7 Team
PHP shipped fixes for PHP2Shell on October 21. Exploitation attempts started hours before that. The patch didn't close the story, it started a race. The flaw lives in PHP itself, and some of the versions it affects will never get an official patch.
What's happening
PHP2Shell is the name for two critical flaws in PHP's core engine, CVE-2026-109618 and CVE-2026-109619. The PHP security team rates both 9.2 on CVSS v4.0 and says an unauthenticated remote attacker can use them to run code on the server.
CVE-2026-109618 is the one our labs focus on. It's a memory corruption bug in how PHP handles running out of memory. If memory runs out while PHP is still building its internal request data, that data is left half-finished. Cleanup code trusts it anyway, and an attacker can turn that broken state into code execution.
The affected code goes back to PHP 5.4, and default installs are exposed. That covers PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. PHP says the risk is highest on mod_php, where an attack can trigger before any application code runs.
PHP released fixed versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35 (see the PHP security advisory).
Why it matters
PHP runs on roughly 70% of websites, including WordPress, Drupal, Joomla, and Magento. Because the bug sits in the interpreter, your application's own security doesn't help. Datadog's researchers found that app-level authentication can't block the attack.
Three things make this one harder than a normal patch cycle:
- Attempts came before the fix. Cloudflare and Patchstack reported exploitation attempts in the hours before the patches landed, some of them highly targeted.
- Discovery is getting faster. The researchers credited with finding PHP2Shell said they used AI models in their work. Attackers have access to the same tools, so the window between a patch and a working exploit keeps getting shorter.
- Some versions won't be fixed. PHP 7.4 through 8.1 only get minimal source backports from the PHP security team. PHP 5.4 through 7.3 are end-of-life and get nothing. They're still widely deployed.
So far there's no fully working public proof of concept and no confirmed compromises, but attempts are frequent. PHP2Shell wasn't in CISA's Known Exploited Vulnerabilities catalog as of October 21.
What to do and what to look for
Patching is the only full fix. Upgrade to a fixed release or your Linux distribution's patched package, then restart PHP so the fix takes effect.
If you can't patch a host yet, isolate it. Put it behind a web application firewall (WAF), limit who can reach it, and apply PHP's interim settings. Cloudflare has published WAF rules for the known exploit paths, and it says plainly that they don't replace patching.
Meanwhile, hunt for signs of an attempt:
- Bursts of out-of-memory errors in PHP logs, especially from unauthenticated requests
- PHP workers crashing or restarting more often than usual
- The web server user spawning shells or other unexpected child processes
- New or changed files in web roots, and outbound connections from web servers that don't normally make them
Get hands-on
We've released two labs so you can see PHP2Shell from both sides.
In the offensive PHP2Shell lab, you'll take the attacker's seat. You'll confirm a WordPress host is running a vulnerable PHP version, use the exploit chain to get remote code execution, and recover a token from the server. It's built for penetration testers and red teamers, and for the developers and engineers who run PHP and want to see what an exposed host gives away.
In the defensive PHP2Shell lab, you'll work as a security analyst. You'll review the logs from a real attack, learn the indicators of compromise it leaves behind, and work out how to use those signals to protect your own network. It's built for security analysts, incident responders, and threat hunters.
Both labs are live now for all customers on all tiers.
Community Manager