On October 21, PHP released emergency patches for php2shell, two flaws that make it possible to run code on a web server without authenticating. Almost every headline summed it up the same way: AI has found a bug that puts 70% of the web at risk.<\/p>\n
That’s true, but it’s the least interesting part. If you read the reports from those who discovered it, the story is a different one: a flaw with roots in 2004, warned about several times, and a researcher who knew exactly what to ask the model.<\/p>\n
php2shell groups together two vulnerabilities in the PHP core, CVE-2026-109618 and CVE-2026-109619, both with a CVSS v4.0 score of 9.2. They allow an attacker without credentials to run code on the server or read the process’s memory, which may contain passwords, tokens, or API keys.<\/p>\n
What makes them exceptional is where they are: in the interpreter itself, not in the application. It doesn’t matter whether a WordPress site, a Drupal site, or a simple “Hello, world” is well written. It affects any installation that serves web requests (PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, LiteSpeed), with vulnerable versions going back to PHP 5.4.<\/p>\n
The cause, in one sentence: when PHP runs out of memory or another fatal error interrupts its native code, it abandons the operation halfway through without cleaning up. Internal state is left pointing to memory that has already been freed, and the next request handled by that same process reuses it.<\/p>\n
The reaction shows the scale of the problem: Finland, the Netherlands, France, and Canada took government websites offline as a precaution on the day of the patch.<\/p>\n
The flaw didn’t come out of nowhere. Calif tells it as a genealogy, and that is the most valuable part of its report.<\/p>\n
memory_limit<\/code>). Those specific paths are fixed, but not the class of problem.<\/li>\n- 2020. Bug #78876 is reported: very long variables in multipart forms exhaust memory and leave temporary files undeleted. It is treated as something minor.<\/li>\n
- 2024. During PHP’s first external audit, carried out by Quarkslab with OSTIF and funded by Germany’s Sovereign Tech Agency, signs of the problem appear again. It is not shown to be exploitable, and it is not fixed.<\/li>\n
- 2026. Two teams, separately and only a few weeks apart, turn that lead into remote code execution.<\/li>\n<\/ul>\n
The PHP Foundation acknowledges that in 2024 it had several proposed fixes on the table and spent months without making a decision. The Foundation itself calls it a structural failure, due to the way it made decisions and to a lack of resources.<\/p>\n
How it was found in 2026<\/h2>\n
In July, OpenAI invited the company Calif to join its Patch the Planet initiative, which funds audits of open-source software using frontier models. Calif chose PHP without high expectations, because it had already been through many AI-assisted audits. Researcher Ryan Austin, who knew Esser’s work well, started from a hypothesis: perhaps relatives of that 2004 flaw were still alive.<\/p>\n
His method, as he describes it, was a guided conversation in four steps:<\/p>\n
\n- Trigger the failure at will. He asked the model for ways to exhaust memory with a single request. The most elegant one uses empty file uploads with deeply nested field names: a request body of less than 8\u00a0MiB ends up taking more than the default 128\u00a0MiB of memory.<\/li>\n
- Find where the interruption hurts. He asked the agent to review the memory manager, fatal errors, and request shutdown. The agent saw that a hash table function increments its counters before initializing the element. If memory runs out right at that point, the subsequent cleanup treats half-finished data as valid.<\/li>\n
- Generalize the pattern. They asked the model to turn that finding into a reusable search rule: publish a state, do something that can fail, and only then commit. With it, another variant appeared, in session upload progress tracking.<\/li>\n
- Take it to PHP-FPM. The first variants only worked against Apache with mod_php. For the most common setup today, they turned to PHP’s unserializer, an old acquaintance in the language’s security history, and to its shared state.<\/li>\n<\/ol>\n
Calif found the first paths to remote code execution on August 1, reported it on August 11, and sent a proof of concept on August 14. Wiz Research reached the same class of flaws on its own on August 19, using its Wiz Atlas system, Gemini 4 Argon, and GPT-5.6 Sol, and reported it on August 24. OpenAI’s security team added more attack vectors in September.<\/p>\n
What AI contributed, and what it didn’t<\/h2>\n
This, for me, is the underlying lesson. Austin insists that he used no special environment and no models beyond the public’s reach. What made the difference was knowing the target and its vulnerability history, and starting from a theory. His advice fits in three words: know your target<\/em>.<\/p>\nHe adds a very useful observation for anyone doing research with these tools. When looking for variants, models tend to start from the most recent and best-known bugs and move toward nearby code. They don’t usually start with obscure primitives from twenty years ago. Whoever knows that history can lead them there.<\/p>\n
Wiz puts the emphasis on the other half of the work: exploitation. Turning these flaws into a reliable exploit requires chaining bugs and adjusting to how each version and configuration organizes memory. Before, that meant a lot of manual debugging for each target. With the models, they adapted exploits to several applications in hours.<\/p>\n
According to their estimate, a single person did in one week what would previously have taken a top-tier team months.<\/p>\n
The two readings fit together. AI didn’t have the idea, but it made testing and exploiting it much, much cheaper. And that changes the math: a flaw too complex to be worth the effort is no longer protected by its complexity.<\/p>\n
The other side: those who maintain the software<\/h2>\n
The story has a less eye-catching and perhaps more important side. The security of PHP, which supports a large part of the web, depends on a small team funded by the PHP Foundation and some volunteer help.<\/p>\n
Since July, that team has published 15 CVEs and reviewed more than 100 reports that turned out to be invalid, duplicates, or impossible to reproduce. AI doesn’t only find real flaws: it also multiplies the noise that reaches maintainers.<\/p>\n
Coordinated disclosure didn’t fully hold up either:<\/p>\n
\n- October 20, around 15:00 UTC. The CVE identifiers circulate with an incorrect score and date, without technical details. PHP moves up its advance notice and shifts the patch from the 22nd to the 21st.<\/li>\n
- That same night. Calif mistakenly publishes a video of its proof of concept that reveals some details.<\/li>\n
- October 21, 07:41 UTC. More than six hours before the agreed time, Chainguard publishes images with the patch and breaks the embargo.<\/li>\n<\/ul>\n
The Foundation has already changed the way it works. Among other things, its security decisions are moving from consensus to majority vote, and it is asking companies that use PHP to fund its security.<\/p>\n
What to do now<\/h2>\n
If you manage servers running PHP, the only complete solution is to update.<\/p>\n
\n- Fixed versions: 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Version 8.1 and earlier have no official release; PHP published minimal source code patches for 7.4, 8.0, and 8.1.<\/li>\n
- Distribution packages: check your distribution’s security advisory. The version number may be different even if the patch is included.<\/li>\n
- Restart the processes: PHP-FPM, Apache, and any long-running PHP process. A process that isn’t restarted keeps running the vulnerable code.<\/li>\n
- Look for hidden PHP: products, appliances, and containers that include it, even if your main website doesn’t use it.<\/li>\n
- Temporary mitigations: disabling
session.upload_progress<\/code> or removing the memory limit are partial measures with side effects. They help buy time; they don’t replace the patch.<\/li>\n<\/ul>\nWhat it leaves us with<\/h2>\n
For those of us who work in network, system, and service security, and in secure communications, php2shell leaves three clear ideas:<\/p>\n
\n- Domain knowledge is still the decisive advantage. Models amplify those who know what to ask; they don’t replace that intuition.<\/li>\n
- Complexity is no longer a defense. A known but “hard to exploit” flaw should be treated as exploitable.<\/li>\n
- The bottleneck has shifted to maintenance. Finding flaws keeps getting cheaper; fixing them, coordinating them, and deploying them still depends on small teams with few resources.<\/li>\n<\/ul>\n
We recommend reading the original reports, especially Calif’s: it is a practical lesson in vulnerability research with AI.<\/p>\n
References<\/h2>\n\n- Calif \u2014 php2shell: A tale of two PHP remote vulnerabilities<\/a> (Ryan Austin)<\/li>\n
- Wiz Research \u2014 PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet<\/a><\/li>\n
- PHP Foundation \u2014 Today’s PHP Security Release, and How We’re Strengthening PHP Security<\/a><\/li>\n
- OpenAI \u2014 Patch the Planet: coordinated disclosure of critical vulnerabilities<\/a><\/li>\n
- PHP security advisory, October 21, 2026<\/a><\/li>\n
- Stefan Esser’s 2004 Bugtraq advisory<\/a><\/li>\n
- PHP bug #78876<\/a><\/li>\n
- Coverage: Simon Willison<\/a>, The Next Web<\/a>, Socket<\/a>, Unite.AI<\/a>, Decrypt<\/a>, Let’s Data Science<\/a><\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"
On October 21, PHP released emergency patches for php2shell, two flaws that make it possible to run code on a web server without authenticating. Almost every headline summed it up the same way: AI has found a bug that puts 70% of the web at risk. That’s true, but it’s the least interesting part. If […]<\/p>\n","protected":false},"author":8,"featured_media":3880,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[34],"tags":[],"class_list":["post-3878","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-tips"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t