AI Found Critical Flaws in PHP. What Site Owners and Developers Should Do Now

What happened

On October 21, 2026, the PHP team released a patch for two critical bugs in the core of the language. They are tracked as CVE-2026-109618 and CVE-2026-109619, and together they are nicknamed PHP2Shell.

PHP matters because of how much of the web runs on it. Wiz says it powers about 70% of all websites. WordPress, Drupal and Joomla are all built on it. Wiz showed that someone with no login could run their own code on a server running the latest container images of all three. The bugs are in PHP itself, so those three are only examples.

Wiz says every PHP version from 5.4 onward is affected by at least one of the two bugs. PHP 5.4 came out in 2012. How old the weakness really is depends on who you ask. One write-up says 14 years. The security firm Calif says the root of it may go back to a memory-limit problem found in 2004.

How the bugs were found

Several teams found these independently: Wiz, Calif and OpenAI. They coordinated with the PHP team before the public release.

Calif found the first dangerous bug in early August while using AI to re-check PHP's attack surface. Wiz says it used its own tooling together with frontier models from Google and OpenAI.

In plain words, the bug is about what happens when PHP hits a fatal error in the middle of a request. Some cleanup code treated data that was only half set up as if it were valid. That leads to memory corruption, and memory corruption can be turned into code execution.

The part that stayed with me

People had seen this before.

A bug report from 2020 described a very long variable causing PHP to run out of memory and fail to clean up temporary files. A security audit in 2024 ran into the same out-of-memory problem. Nobody could show that it was exploitable, so it was not treated as a security bug and it was not fixed.

That is the real story. The bug was visible for years. What was missing was proof that it could be used for an attack, and getting that proof was slow and expensive.

On the Wiz podcast, the researchers say that turning a memory corruption bug into a working exploit used to take human researchers months of lab setup and debugging. The AI agents did it in a couple of weeks, and they kept working while the researchers slept.

Calif adds one caveat. The AI only got there because the researchers already knew PHP's history and architecture, and that decided where to point it and what to ask. So the people still matter. But they now get much more done in the same time.

What actually changed

This is my reading, not something the sources say in these words.

A bug that is "real but nobody can prove it's exploitable" used to be low priority. Every large codebase has a pile of these. The proof step was the thing protecting us, and AI just made that step much cheaper.

So old audit notes that say "not exploitable" are worth reading again. And the gap between a patch being published and someone attacking it is going to shrink.

On attackers: I could not find any source confirming that attackers used AI against PHP2Shell. The researchers who used AI were on the defending side. Exploit attempts have been reported since the disclosure, which is normal once a patch is public. The window between patch and attack is what matters now.

Who needs to do what

Many small business sites, including a lot here in India, run WordPress on shared hosting. For those owners the only move is to ask the host. Ask clearly: "Is the PHP version on my plan patched for CVE-2026-109618 and CVE-2026-109619?"

What to do this week

1. Find where PHP runs. Production is the easy part. Also look at staging servers, old VPS boxes, cron workers and container images.

2. Check the version.

   bashCopy

   php -v
   php-fpm -v

   Compare it with the release notes on php.net for your branch. I am not listing patched version numbers here because they differ by branch.

3. Update the PHP runtime and restart. A package update alone is not enough if the old process is still running.

4. Rebuild and redeploy containers. An old image keeps the old PHP no matter what is installed on the host.

5. Look at your logs since October 21. Check for strange requests, especially to upload endpoints and login pages.

OpenAI also published a PHP2Shell version checker on GitHub. It is called php2shell-checker. If you use it, read what it does before running it on a production machine.

What this means for how we work

I see three things.

First, "we'll patch next sprint" costs more now. If the time from public patch to working exploit keeps shrinking, a patch cycle measured in weeks is a real risk.

Second, security backlogs need a second look. Bugs marked "can't prove exploitable" were never safe. We just couldn't prove they were dangerous. That is a weaker kind of safe.

Third, defenders get the same tools. The researchers who found PHP2Shell used AI to find bugs and verify patches. Any team that can write down its codebase's known weak spots can do some version of that. The hard part is knowing where to look, which is the point Calif made.

I do not think this is a reason to panic. It is a reason to know what version of PHP you are running, and to have a short path from "patch released" to "patch deployed".

Sources

• Wiz Research: PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet
• Wiz podcast: Breaking Down PHP2Shell with Sagi Tzadik & Thai Duong
• iThome (in Chinese), summarizing Calif's account of the 2004, 2020 and 2024 history: PHP2Shell report
• NeuralTrust: PHP2Shell AI-assisted exploitation (on the point that attacker use of AI is not confirmed)
• Towards AI: PHP2Shell: How AI Found a 14-Year-Old Bug in PHP, and Why the Patch Race Is On (update and restart steps)
• Forkast: AI-Assisted Research Uncovers Critical PHP2Shell RCE Vulnerabilities

Benchmark and capability claims are as reported by the researchers and outlets above. I have not reproduced them.