AI found PHP2Shell. That is the headline.
Researchers used frontier AI models to find two critical flaws in the PHP engine itself, bugs that had been sitting there since PHP 5.4. The same models built working exploits. The news leaked before the fix was ready, and someone was already probing for it four days before disclosure. Within hours of the patch going public, AI-generated exploit code was on GitHub. Within days, researchers had an exploit that walks past the protections a properly configured production server is supposed to have. And incident responders are now describing post-compromise activity that looks like an AI agent working through a checklist: enumerate the host, grab the password hashes, pull the MFA secrets, tunnel into Active Directory. Two hours from first access to a domain admin attempt.
Nobody has proven that attackers used AI to exploit PHP2Shell. I want to be precise about that, because precision separates a warning from a sales pitch. What is proven is that AI shortened every phase of the timeline: discovery, weaponization, exploitation, and post-exploitation.
That has never happened on one vulnerability before. It will happen on the next one.
The parity window is open
For a year I have been describing what I call the parity window. For the first time in our field, attackers and defenders got the same technology at the same moment. Nobody got a head start.
PHP2Shell is the first vulnerability where a general audience can see the parity window in a single CVE. The flaw was found with AI. The exploit was built with AI. The post-compromise tooling appears to be AI. In some places, the defense was AI too.
AI changes the math. What we do with the time we have is the open question.
What we did in the first 72 hours
I am going to tell you exactly what happened at 7AI, because it shows what a machine-speed defense looks like when it is running in production rather than on a slide.
When the advisory landed, our AI agents started hunting. They went into customer environments and looked for the behaviors PHP2Shell exploitation leaves behind: child processes spawned by PHP worker processes, web shells written to upload paths, outbound connections from web servers that have no business making them, credential access from the web tier. Across every customer on the platform, the same day.
Our PLAID ELITE team, the security experts who sit on the loop above the agents, took the results and hunted proactively for every PLAID ELITE customer and every customer who had asked us to. They got on calls. Where we saw exploitation attempts, a person picked up the phone before any email went out. Where a customer wanted to understand what we were seeing and why, a human walked them through it.
The agents did the non-human work: correlating telemetry across thousands of endpoints, running the same hunt across every environment in parallel, surfacing what mattered. The humans did the human work: judgment, context, the phone call. Speed came from AI doing what AI should do, with people still making the decisions.
This is just the beginning
PHP2Shell is a preview.
The researchers who found these bugs used the models available today, and those models get more capable every quarter. Finding a twenty-year-old memory corruption bug in a runtime that powers a huge share of the web became a research project. Turning it into an exploit took hours. Running the post-exploitation playbook took an agent and a prompt.
Each of those costs keeps falling. Expect more PHP2Shells per year and less time between disclosure and exploitation.
So the question I keep coming back to is who is defending at machine speed.
The companies most visible in this week's coverage sell detection and patching. That work matters. A signature catches one exploit path and an advisory tells teams to patch. Neither answers whether someone already got in during the four days before disclosure. When the next PHP2Shell lands, the organizations in the best position will be the ones where AI agents are already in the environment, already hunting and correlating, with experienced people on the loop deciding what to do about what they find.
Fighting fire with fire is the only model where the math works.
What to do this week
- Patch to 8.5.12, 8.4.27, 8.3.36, or 8.2.35. Where patching has to wait, apply the interim php.ini mitigation and restart the PHP workers.
- Find every PHP install that serves web requests, including the ones embedded in appliances and admin consoles. PHP is in more places than any inventory says it is.
- Hunt for the behaviors, not the CVE string. Start with four: child processes spawned by PHP worker processes, new files in upload and temp paths that PHP can execute, outbound connections from web servers to hosts they have never talked to, and credential access originating from the web tier. Pull the window back to at least October 17, because exploitation started before disclosure.
- Decide, now, what the response to the next one looks like. The teams that already have agents hunting and people on the loop will not be starting from the advisory email.
The next PHP2Shell is coming, and the defense has to be in the environment before it lands.
Frequently asked questions
What is PHP2Shell?
PHP2Shell is the name for two critical remote code execution flaws in the PHP engine itself, CVE-2026-109618 and CVE-2026-109619, disclosed on October 21, 2026. They affect PHP versions back to 5.4 and let an unauthenticated attacker run code on a vulnerable web server. Patched releases are 8.5.12, 8.4.27, 8.3.36, and 8.2.35.
Did attackers use AI to exploit PHP2Shell?
No source has proven that attackers used AI to exploit PHP2Shell. What is documented is that researchers found the flaws and built working exploits with frontier AI models, AI-generated exploit code appeared on GitHub within hours of disclosure, and incident responders have observed agentic AI tooling in post-exploitation activity. AI shortened every phase of the timeline whether or not it ran the exploit.
How did 7AI respond to PHP2Shell?
7AI's AI agents hunted for PHP2Shell exploitation behaviors across customer environments on the platform the same day the advisory landed. The PLAID ELITE team, with humans on the loop, reviewed the results, hunted proactively for PLAID ELITE customers and any customer who had authorized hunting, and called customers directly where exploitation attempts were observed.
What should security teams do about PHP2Shell this week?
Patch to 8.5.12, 8.4.27, 8.3.36, or 8.2.35, or apply the interim php.ini mitigation and restart PHP workers where patching has to wait. Find every PHP install that serves web requests, including those embedded in appliances. Then hunt for behaviors rather than the CVE string: child processes from PHP workers, new executable files in upload paths, unexpected outbound connections from web servers, and credential access from the web tier, going back to at least October 17.
