php2shell lets an unauthenticated request run code on vulnerable PHP servers. Here’s what happened, why AI matters, and what you should patch today.
For years, turning a memory bug in PHP’s error handling into a working exploit was a job for a handful of specialists. This week, someone pulled it off against a live server, in a public challenge with bitcoin on the line.
php2shell, two critical remote code execution flaws in PHP itself, has dominated security feeds since the PHP project shipped emergency patches. The bugs aren’t new. What’s new is how quickly researchers, with frontier models in the loop, turned them into a working attack, and how much of the web runs on the runtime they live in.
TL;DR: a crafted HTTP request, with no login, can potentially make a vulnerable PHP worker run an attacker’s code. And because the flaws live in PHP itself rather than in any one framework or plugin, your application can be exposed even if your code is spotless.
What php2shell is and which PHP versions are affected
php2shell is two bugs, both rated 9.2 out of 10 on CVSS 4.0 (the Common Vulnerability Scoring System), found in PHP versions 5.4 onward. Both vulnerabilities are use-after-free flaws arising from PHP’s memory management and state-handling components. In a use-after-free bug, a program keeps using memory after it has released it, letting an attacker influence what ends up in that space.
| CVE | Description | Impact |
| CVE-2026-109618 | An out-of-memory error interrupts PHP while internal request data is only partly initialized | Remote Code Execution |
| CVE-2026-109619 | Request-owned state outlives the memory behind it, so a later request on the same worker touches freed memory | Remote Code Execution |
The flaws were reported by researchers at Calif and Wiz, among others. Every PHP setup that serves web requests is in scope: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The PHP team rates mod_php as the riskiest, because a demonstrated exploit fires before any application code runs. In practice, that means input validation, authentication checks, and any other defenses built into your application never get a chance to intervene.
Fixed builds are PHP versions 8.2.35, 8.3.36, 8.4.27, 8.5.12, or later. Patched PHP 7.x versions are still to be determined. Every PHP version below 8.2 is already end-of-life, so older installs may never receive an official fix – more on that in the last step of the checklist below.
There are already several public proof-of-concept tools. An online report from Palo Alto Networks mentions that over 22.6 million exposed instances are potentially vulnerable. That figure measures exposure, not confirmed vulnerability.
Why php2shell can’t wait for the next patch cycle
Critical CVEs land every week, and most deserve a calm ‘patch it in the next cycle’ approach. But php2shell doesn’t, for three reasons:
- Reach – PHP runs various websites. WordPress, Drupal, Magento, Laravel apps, and various internal tools nobody remembers deploying: all of it sits on the same runtime.
- Age – the vulnerable error-handling paths trace back to roughly 2012, with affected versions reaching back to PHP 5.4.
- No precondition – based on the commentary circulating so far, the exploit is believed to require no credentials or misconfiguration, although several publicly available exploits target specific PHP lab environments.
How AI lowered the bar for exploit development
The most interesting part of the story isn’t the bugs. It’s how they became exploitable.
The underlying weaknesses had been there for years, but turning them into a working attack required a chain of steps that only highly proficient exploit developers could pull off. Frontier models lowered that bar.
It’s worth being precise here. This wasn’t an AI wandering off and finding a bug on its own. Human researchers drove the work, using models to generate hypotheses and grind through verification, while PHP maintainers built and shipped the fixes.
The exploit itself is highly complex and demands a deep understanding of exploit development. Even so, various security researchers on LinkedIn argue that it’s an ‘easy exploit’ by today’s standards, because AI can produce a fully working proof of concept in hours or a few days. That is a security concern in its own right: malicious actors without deep technical knowledge can now use AI to write a working exploit.
StealMyBitcoin, the public test that proved it works
The most entertaining side plot was StealMyBitcoin, a public challenge that turned php2shell into a capture-the-flag (CTF) contest: whoever first exploited the PHP website would claim 0.02506816 BTC. The server ran PHP 8.4.26, with the private key to a Bitcoin wallet sitting on it.
After 17 hours with no winner, people started to question whether the server setup even exposed the bug, and heavy probing traffic knocked the site offline more than once.
Then 19.28 hours later, the site flipped to “Challenge won.” The winner, a researcher known as KillaBoi, published the full proof of concept on GitHub. It is a multi-stage chain. It sets off a precise memory corruption condition, leaks internal addresses to defeat ASLR (address space layout randomization, a defense that randomizes where code and data sit in memory), and forges PHP’s internal structures to take over execution.
How to protect your PHP servers right now
If you run PHP anywhere, this is today’s work, not next sprint’s.
1. Find every PHP install. Websites, APIs, admin panels, vendor applications, container base images. PHP often arrives bundled inside other products, so the owner may not be the team you’d expect.
2. Patch internet-facing systems first. Move to 8.2.35, 8.3.36, 8.4.27, 8.5.12 or later, or to your distro’s equivalent. Many distros backport fixes, so check their security advisories rather than trusting the version string alone. Restart every worker so the new build is actually running.
4. Watch for signs of compromise. Unexpected worker crashes, new files in web roots, and odd outbound connections from web servers all deserve a look.
5. Have an end-of-life plan. For servers on old, unsupported PHP that won’t get a patch, consider taking them offline until they’re upgraded or mitigated.
Patching fixes php2shell. It won’t fix the next one.
php2shell won’t be the last critical flaw buried in software everyone assumed was safe. What has changed is the time between disclosure and a working exploit. When AI can compress weeks of exploit development into days, ‘patch it in the next cycle’ stops being a plan.
That puts the pressure on knowing your estate before the next advisory lands: where your PHP and other runtimes live, who owns them, and how an attacker could chain a flaw like this into your systems.
