AI Security Vulnerabilities: What PHP2Shell Shows
AI security vulnerabilities, meaning ordinary software flaws that AI models help find and attackers then exploit faster, stopped being theoretical on 21 October 2026. That is when PHP released fixes for two critical bugs that researchers say AI tools helped uncover and turn into working exploits. For website owners, the headline lesson is not that AI is dangerous. It is that the time between a fix being published and a site being attacked has collapsed.
This is part 2 of The Web After PHP2Shell. Part 1, PHP vulnerability 2026, explains the flaws and the fixes. This part is about what the AI angle changes. One scope note: “AI security vulnerabilities” can also mean weaknesses inside AI systems, such as prompt injection. That is a different topic. Here it means AI as a force acting on everyone’s ordinary web stack.
On this page
- What are AI security vulnerabilities?
- How did AI help find the PHP flaws?
- What do the researchers actually claim?
- Why do patch windows shrink?
- Is AI a bigger risk or a better defence?
- Is this only a PHP problem?
- What should a small site change?
What are AI security vulnerabilities?
The term covers two different problems, and mixing them up leads to the wrong fixes.
| Meaning | Example | Who fixes it |
|---|---|---|
| Flaws found by AI in ordinary software | PHP2Shell: memory bugs in the PHP engine | Software maintainers, then everyone who runs the software |
| Flaws inside AI systems | Prompt injection, leaked model keys, unsafe AI-written code | The team that builds or deploys the AI feature |
PHP2Shell belongs in the first row. The bugs are use-after-free faults in a C codebase, the kind of defect that has existed in many runtimes for years. What changed is who, or what, was looking for them. The GitHub advisory credits named reporters and the developers who fixed them, and it describes the technical fault, not the method of discovery. The AI account comes from the researchers who found it.
How did AI help find the PHP flaws?
According to Wiz’s write-up, its research used its own tooling plus frontier models, named as Gemini 4 Argon and GPT-5.6 Sol, throughout. The dates it gives are the best view of how fast the work moved:
- 19 August 2026: Wiz finds the first PHP vulnerability with the AI tools.
- 20 and 21 August: unauthenticated code execution is confirmed against Drupal, then WordPress.
- 24 August: Wiz reports the vulnerabilities to the PHP security team.
- 21 September: PHP acknowledges the reports and begins a coordinated fix.
- 21 October: patched releases ship and the flaws are disclosed.
Sansec’s account adds an earlier thread: Calif found multiple code-execution paths on 1 August and reported the first bug on 11 August. Cybersecurity Dive reports that Calif used OpenAI’s GPT-5.6 Sol, and that the US government learned of the flaws on 16 October.
Scroll the diagram sideways to see all of it.
What do the researchers actually claim?
Three claims matter, and each is attributed to a named source, not established independently.
The exploit was hard before AI. Wiz describes the exploit chain as near the limit of what human researchers could practically achieve, because it needed several bugs chained together and careful handling of how memory is reused across requests. It says frontier models substantially lowered that barrier and helped adapt the exploit to different PHP versions, configurations and memory layouts.
The same capability cuts both ways. Cybersecurity Dive reports that OpenAI said AI can uncover security flaws with internet-scale impact, but that the same abilities can help attackers build exploits. The researcher Nicholas Weaver, quoted there, called PHP2Shell one of the first widespread vulnerability crises of the AI era and noted that AI is good at turning patches into exploits, so organisations must apply updates almost immediately.
Accounts differ on who used what. Wiz names Gemini 4 Argon and GPT-5.6 Sol. Cybersecurity Dive attributes the Calif work to GPT-5.6 Sol. NBC News reports that OpenAI said it helped discover the flaw through a programme giving security companies access to its models. These are compatible, but no single source reconciles them, so treat model names as reported, not audited.
Why do patch windows shrink?
A patch is a map to the bug. The moment a fix is public, anyone can compare the old and new code and see exactly what was wrong. That has always been true. What AI changes is the labour: Weaver’s point is that models are good at turning a patch into a working exploit, so the gap between “fix published” and “exploit available” can drop from days or weeks to hours.
The PHP2Shell traffic shows what that looks like. ABC News, citing Reuters, reports that Cloudflare’s CEO Matthew Prince said thousands of exploit attempts hit Cloudflare’s network in the 10 hours before public disclosure, tens of thousands in the 45 minutes after, hundreds of thousands within two hours, and later millions.
Scroll the diagram sideways to see all of it.
Not every one of those attempts succeeded, and Sansec’s later analysis says reliable exploitation needs specific conditions. The pattern still holds. Attackers were testing before the fix existed and scaled up within minutes of it appearing.
Is AI a bigger risk or a better defence?
Both, and the evidence from this case tilts toward “defence got there first, adoption lagged”. The flaws were found and reported in August by researchers working with maintainers. According to Cybersecurity Dive, OpenAI said it coordinated patching with US and foreign agencies including CISA and the Office of the National Cyber Director. The failure was not discovery. It was the roughly two months between report and fix, a leak, and then the long tail of sites that update slowly.
That tail is the real exposure. Cybersecurity Dive reports Cisco’s estimate that roughly half of internet-facing PHP instances run versions too old to receive the fixes, and Part 1 shows more than a third of PHP sites on PHP 7 or older per W3Techs. A world where AI finds flaws faster is only safer if patches are installed faster too.
This also connects to how sites get discovered. The same crawlers and agents covered in agentic search optimization are automated visitors, and security scanners are another kind. Both treat your site as a machine-readable surface, and both reward sites that are well maintained.
Is this only a PHP problem?
No, and it helps to see PHP2Shell next to a case from the JavaScript side. In December 2025 the React team disclosed CVE-2025-55182, rated CVSS 10.0, which let an unauthenticated attacker run code on a server through a crafted request to a React Server Function endpoint. It affected Next.js and several other frameworks. A single researcher reported it on 29 November through a bug bounty, and the fixed versions were published on 3 December, four days later.
The comparison is useful for two reasons. First, the pattern is not specific to PHP or to AI: mainstream server-side runtimes and frameworks all ship critical flaws sometimes, and sites that do not apply the fix quickly bear the cost. Second, the timelines differ in a way that matters. React’s fix followed the report in days. PHP2Shell took about two months from the first report to a release, because the bugs were deep in the engine and needed a coordinated fix. A long fix window followed by a short exploit window is what makes the post-disclosure scramble so intense.
Nothing in this story argues for or against a particular stack. It argues for being the kind of site owner who can apply a fix in a day.
What should a small site change?
You cannot out-research an AI-assisted attacker. You can shorten your own response time and reduce what there is to attack. The changes that matter most are about process, not prediction.
Scroll the diagram sideways to see all of it.
| Layer | What it means in practice | Who usually owns it |
|---|---|---|
| Inventory | A written list of apps, versions and the host that runs each | You or your agency |
| Patch fast | Managed hosting that updates runtimes, or a documented same-day routine | Host or developer |
| Virtual patch | A web application firewall in front of the site | Host or CDN |
| Shrink surface | Fewer plugins, fewer admin panels, static where a page does not need code | Developer |
| Contain and watch | Rotatable secrets, logs someone reads, backups kept offline | You or your agency |
A recurring routine beats a heroic response. The website maintenance tasks checklist is a good base for turning layers 1 and 2 into a monthly habit, and AI SEO in 2026 shows how much of the web’s discovery layer is now automated, which makes uptime and hygiene matter more.
What AI security vulnerabilities mean for your website
For a typical business site, the practical meaning is modest and urgent: updates that used to be safe to schedule for next month are now safe only if done within days. If your site is on managed hosting that patches for you, you are mostly covered. If it is on a server nobody has logged into since launch, that is the risk to fix first.
The rest of the series follows from this. Part 3, is PHP dead, asks whether a runtime with this history deserves your trust. Part 4, static vs dynamic website, shows how running less code on the server lowers the exposure. Part 5, website maintenance mode, covers taking a site down safely when you have to, and Part 6 looks at the future of web development.
If you want a site that depends on less server-side code and a build process that makes updates routine, Ambeltek’s web development service is built around exactly that. We will also tell you when a dynamic stack is the right call.
Frequently asked questions
What are AI security vulnerabilities?
The phrase has two meanings. One is flaws inside AI systems themselves, such as prompt injection. The other, and the one the PHP2Shell story is about, is ordinary software flaws that AI models help find and exploit. This article covers the second meaning.
Did AI really find the PHP vulnerabilities?
Wiz says it used AI tools, including frontier models, for discovery, exploit development and patch validation, and other reports say Calif used an OpenAI model. PHP's own advisories credit named reporters and fixers and do not describe the role of AI, so that account comes from the researchers.
Does AI make hacking easier?
It lowers the cost of the hardest steps. Wiz says its exploit chain was near the limit of what human researchers could practically build, and that AI models helped adapt it to different PHP versions, configurations and memory layouts. The same capability helps defenders find flaws first.
How fast do attackers exploit a new vulnerability now?
For PHP2Shell, very fast. Cloudflare's CEO said thousands of exploit attempts hit its network in the 10 hours before public disclosure, tens of thousands in the first 45 minutes after, and hundreds of thousands within two hours. Amazon logged an attempt four days before disclosure.
How can a small business protect itself from AI-found vulnerabilities?
Shorten the time between a fix being released and installed. Know every application that runs, use a host that patches for you, put a web application firewall in front as a stopgap, remove software you do not need, and keep secrets rotatable. Speed of patching matters more than predicting the next flaw.
Are AI tools themselves a security risk for websites?
They can be, but that is a separate problem. Prompt injection, leaked API keys and unreviewed AI-written code are real risks. They are different from the PHP2Shell pattern, where an old flaw in a mainstream runtime was found and weaponised faster than most sites could update.