In the early 2000s, remote code execution exploits were abundant and also a kind of currency in the offensive security community. Some were published openly, others quietly traded, and many never saw the light of day. There were also plenty of fake or backdoored exploits circulating through IRC channels, mailing lists, and underground forums, sometimes designed to compromise the very people trying to use them.
Watching the PHP2Shell story unfold reminded me of those days, and even of an old exploit called PHPloit (fake 7350cowboy.c), still sitting in an archived GeoCities from 2002. Except this time, the clock is moving much faster.
PHP2Shell refers to two critical vulnerabilities in PHP itself, tracked as CVE-2026-109618 and CVE-2026-109619.
The research involved Calif, OpenAI, and Wiz. Ryan Austin from Calif identified critical issues using OpenAI’s GPT-5.6 Sol, while Wiz independently discovered overlapping vulnerabilities. The PHP maintainers led the fixes, supported by researchers and industry partners coordinating the response.
Technically, the vulnerabilities involve memory-management issues in PHP runtime. One class involves out-of-memory conditions interrupting internal operations and leaving data structures in an inconsistent state. Another involves request-owned state surviving after its backing memory has been freed, potentially allowing subsequent requests to interact with stale references. The consequences include memory disclosure and unauthenticated remote code execution.
What makes the story particularly interesting is its history. Stefan Esser was investigating related PHP memory-limit vulnerabilities back in 2004, and similar patterns were revisited over the years, including later bug reports and security audits. Having a bug like this survived many code reviews is a reminder of the times we are living.
The story has a pattern, the ability to explore codebases and turn complex findings into working exploits. AI helped researchers navigate unfamiliar code, generalize vulnerability patterns, identify promising execution paths, and iterate through failed hypotheses much faster. These are exactly the kinds of tasks that traditionally require substantial experience and time.
AI didn’t make PHP vulnerable, but it changed the economics of finding and exploiting vulnerabilities that were already there.
Then came the leak
Before the coordinated disclosure was completed, information about PHP2Shell began circulating publicly. Incomplete technical details, claims about exploitability, and demonstration material created a familiar situation: researchers everywhere trying to reconstruct a working proof of concept. As more information became available, the race accelerated.
There was also a slightly ironic moment in our own conversations. Brendan Dolan-Gavitt, from our research team, pointed out something interesting: people hunting for this particular vulnerability could very well discover additional bugs in the PHP codebase along the way. Vulnerability research rarely follows a straight line. One bug leads to another as researchers start looking at adjacent code paths, alternative triggers, and other ways to reach similar conditions.
Now imagine hundreds of researchers doing this simultaneously, many assisted by AI systems that can navigate source code, generate hypotheses, and test them continuously. The result is potentially a much broader exploration of an already vulnerable attack surface.
The long tail of the internet
There is another dimension to this story that makes PHP2Shell particularly challenging. For a long time, PHP was practically the default programming language of the web. WordPress, Drupal, Joomla, MediaWiki, and countless other applications were built on it. PHP enabled an entire generation of websites, from personal blogs to government portals, universities, NGOs, and institutional websites.
And many of those systems are still running. Some have been maintained continuously for decades, but others were developed years ago, deployed once, and left mostly untouched. Think about a small government website, a university department, or an NGO running an old content management system. It might serve a relatively simple purpose and receive very little attention.
And underneath that website there may be a PHP installation that is years out of date. PHP2Shell affects versions dating back to PHP 5.4, with exposure depending on the specific vulnerability and configuration.
The PHP team released security fixes on October 21, 2026, in versions 8.2.35, 8.3.36, 8.4.27, and 8.5.12. However, PHP 8.1 and older are no longer officially supported. Although source backports are available for some older branches, and certain vendors provide extended security support, many deployments will require substantial migration work.
In addition, updating PHP is not necessarily equivalent to updating an application. An organization may have custom code, abandoned dependencies, incompatible extensions, or legacy infrastructure that makes migration difficult. Because the vulnerability is in PHP itself, upgrading WordPress or Drupal doesn’t necessarily resolve the underlying issue.
The shrinking window for defenders
For years, defenders could sometimes rely on the complexity of exploitation as a temporary barrier. Building a reliable exploit, adapting it to different configurations, and making it work consistently against real-world targets was a time-consuming endeavor.
PHP2Shell is another reminder that this assumption is becoming increasingly fragile. AI is reducing the effort required to understand complex codebases, explore alternative exploitation paths, and adapt working techniques across environments.
The same capabilities are available to defenders, of course. We can use them to audit critical software, identify related vulnerabilities, validate patches, and improve our ability to prioritize exposure. The coordinated effort around PHP2Shell also demonstrates this opportunity: researchers, maintainers, infrastructure providers, and security organizations using AI-assisted research and coordinated disclosure to prepare fixes and protections before public release.
Offensive work can scale quickly once a promising technique is discovered, but defensive remediation still depends on asset inventories, application ownership, compatibility testing, maintenance windows, and human decisions. And the internet is full of systems where even identifying the responsible owner is difficult.
The challenge ahead is building a defensive ecosystem capable of responding at a speed that increasingly matches offensive research.
This creates a particularly difficult situation for defenders. We have a critical vulnerability in infrastructure used across an enormous portion of the internet, combined with millions of independently managed deployments and wildly different levels of operational maturity. The patch may be available, but that does not mean every vulnerable system can be patched overnight.
Exploiting is technical, but fixing is political. Much of the conversation sometimes relies on how fast it is to apply a patch.Even wild ideas involve using an exploit to deploy a patch, but at the end of the day, it's about the impact and resources required to apply a patch and make the applications compatible with it.
References and credits
- PHP2Shell — Research and Disclosure Hub
- Calif Research — php2shell
- Wiz Research — PHP2Shell Technical Analysis
- OpenAI — Patch the Planet: Global Response Coordination
- PHP — Official Security Advisory and Fixed Releases
- Cloudflare — PHP2Shell WAF Protections
- 7350cowboy.c — Historical Exploit Archive
Credit to Ryan Austin at Calif, Amy Burnett at OpenAI, and Sagi Tzadik, Shir Tamari, Nir Ohfeld, and Tomer Schwartz at Wiz Research, as well as the PHP maintainers and the wider security community involved in the response.