- Wiz Research reports flaws in core PHP that allow remote code execution without a login, patched on October 21, 2026. It says AI made the exploit practical.
- The case raises a question for security teams: how many risks were ranked low only because exploiting them took rare skill?
- Leaders should confirm PHP patch status across all hosts, including those inside hosting and vendor stacks, and ask what extra protection covers the gaps.
Many security teams rank bugs by how hard they are to exploit. A flaw that needs a rare skill and weeks of work goes to the bottom of the list. The PHP2Shell research, published by Wiz Research, tests that habit. The difficulty may have been doing some of the defending, and AI is changing how much it can be relied on.
What Wiz found
Wiz Research reports multiple vulnerabilities in core PHP, the scripting language behind WordPress, Drupal, Joomla and Wikipedia's MediaWiki. Its researchers say the flaws allow unauthenticated remote code execution and the reading of server memory.
The flaws sit in PHP itself, not in any one application. Wiz says even a simple 'Hello World' page on an affected version can be vulnerable. The company says the problem reaches back about ten years of releases, to PHP 5.4, and that each version since carries at least one of the bugs.
The researchers combined the bugs into one exploit script, php2shell. They say it ran code remotely, without logging in, on the latest container images of WordPress, Drupal and Joomla at the time of testing. PHP released patches on October 21, 2026.
How the flaw works
Wiz says all of the bugs come from how PHP handles fatal errors, especially running out of memory. When a request dies unexpectedly, PHP can leave corrupted internal state behind. The next job that the same worker process takes on may build on that leftover.
Wiz describes several cases. In one, PHP's handling of file-upload progress can leave a dangling pointer to freed memory. A later request makes PHP trust that pointer, and PHP then returns memory contents in a session cookie. This works even if the application never uses sessions.
In another, PHP keeps a record of the last fatal error. After an out-of-memory crash, that record can still point to memory from the old request. A third case involves OPcache, which shares compiled code between workers. A failed memory allocation can leave workers disagreeing about what a slot holds.
Wiz says the memory leak can expose passwords, tokens, API keys and certificates. It also says other variants exist beyond the four it reported. The PHP patch fixes the problem at its core and removes all variants in the patched release, according to Wiz.
The barrier that moved
Memory bugs like these are hard to turn into attacks. Wiz says an exploit that works on one setup may need substantial rework for another, because PHP versions and configurations differ. Before AI, it says, that manual work was hard to do and harder to scale.
Wiz says frontier AI models changed that. Throughout the project it used its own Wiz Atlas tool alongside two models, Gemini 4 Argon and GPT-5.6 Sol. With that help, Wiz says, building working exploits and tuning them for several different applications took hours. It also says one researcher did in a week what once took a world-class team months.
This is Wiz's account of its own work, and Wiz sells security products. Still, the argument is plausible. A flaw's age and complexity are weak guides to its risk once effort gets cheap. The same tools helped defenders find and verify the fix, Wiz notes.
Attackers moved fast too
404 Media reports that Cloudflare CEO Matthew Prince posted figures on the traffic. In the 10 hours before the public announcement, Cloudflare saw thousands of exploit attempts across its network. After the announcement, he said, attempts reached tens of thousands within 45 minutes, hundreds of thousands within two hours, and millions later.
These are Prince's figures as relayed by 404 Media, and they do not say how many attempts succeeded. They show probing began before the announcement and kept growing, to millions of attempts, after it.
The timeline also matters. Wiz reported the bugs to PHP on August 24. PHP acknowledged them on September 21 and shipped patches on October 21. Wiz also thanked Cloudflare, AWS, Google, Microsoft, Akamai, Fastly, Imperva, Vercel and Automattic for preparing mitigations for customers who cannot patch at once.
What this means for exposure
WebPulse cannot see which sites run which PHP version. Its September 2026 scan of the Tranco top 10,000 domains did detect a platform on 2,491 sites. WordPress ran on 719 of them (28.9%) and Drupal on 188 (7.5%). Together that is about 36% of the sites where a platform was detected.
Those are two of the three platforms Wiz used in its demonstrations, alongside Joomla. The scan says nothing about patch status. It shows how many prominent sites rest on software that depends on PHP.
What to ask your team
Start with inventory. Ask where PHP runs in your organisation, including hosting providers, vendor-managed systems and old servers that nobody owns. Ask which versions they run and when each will get the October 21 patch.
Then ask about the gap. Wiz says the patch is the only complete fix. For systems that cannot be patched yet, ask which provider mitigations are on and who confirmed it.
Wiz also names three warning signs to watch until patching is done. One is unusual file-upload traffic that is soon followed by out-of-memory errors or a run of HTTP 500 server failures. Another is session cookies that are unusually large or malformed. The third is PHP worker processes restarting for no clear reason. Ask whether anyone is looking.
Finally, review your risk register. Find the items rated low because they were hard to exploit. PHP2Shell suggests that rating deserves a second look.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Wiz.
