· 5 min read

PHP2Shell: When Finding Bugs Gets Faster Than Fixing Them

AI helped find PHP2Shell, though less than the headlines imply. The sharper lesson is what happens when bugs get cheaper to find and fixing them stays slow.

A network of translucent white polyhedra on a dark background, with a few glowing red ones linked into a path through the middle.
  • Security
  • Models

Four days before PHP shipped a fix for PHP2Shell, someone was already trying the exploit. Amazon’s honeypots logged the attempt on 17 October, and the patch landed on the 21st. Amazon says it doesn’t know how the attacker got the details, or whether the attempt would have succeeded against a real system. Even so, defenders can no longer treat the advisory as their first warning.

PHP2Shell is the name for CVE-2026-109618 and CVE-2026-109619, two memory-safety bugs in the PHP engine that the PHP security team says can allow unauthenticated remote code execution. The headlines said 70% of the internet. The figure comes from W3Techs and is narrower: as of 24 October, PHP runs 69.3% of the websites whose server-side language W3Techs can identify. That is still most of the web, and because the bugs sit in the engine, the advisory treats every PHP installation serving web requests as at risk.

AI turned PHP2Shell into a front-page story. It did help find the bugs, though less than the headlines imply. For companies running their own AI programmes, the sharper lesson comes from the PHP project itself, which shows what happens when bugs get cheaper to find and fixing them stays slow.

What the AI actually did

The root cause was reported more than once. The PHP Foundation’s post-mortem says Calif, a security firm auditing PHP under OpenAI’s Patch the Planet programme, reported a remote code execution on 11 August, and that OpenAI independently reported the same root cause. Wiz and OpenAI then reported further attack vectors, on 24 August and 18 September. The first finding and the later ones are different achievements, and the coverage tends to blur them.

Several press accounts say Calif used OpenAI’s GPT-5.6 Sol, but Calif’s own write-up names no model. It says the initial discovery used no special harness and no model that was not generally available. The starting point was a researcher who knew PHP’s vulnerability history and had a theory tracing back to a memory-limit bug Stefan Esser found in 2004. The model did the legwork from there, reviewing allocator behaviour, spotting the faulty ordering and generalising the pattern into a skill file that turned up a second finding. Calif says it expected nothing critical, because other labs had already run extensive AI-assisted audits of PHP. What separated this audit was a person who knew which old class of flaw to point the model at.

Wiz makes the bigger claim. Its write-up names Gemini 4 Argon, GPT-5.6 Sol and its own Wiz Atlas tool, and says one researcher did in a week what would once have taken a top team months. That is Wiz describing its own research and product, and nobody has measured it independently. Taken with Calif’s account, it suggests AI assistance is lowering the cost of some vulnerability research and exploit development. How much depends on the target, the researcher’s expertise and the complexity of the exploit.

The first signs appeared in 2024

For a board, the most useful document this week is the Foundation’s post-mortem. A core developer found the first signs of the out-of-memory problem behind CVE-2026-109618 during a 2024 audit. Nobody could show it was exploitable, each candidate fix broke something else, and the work stalled and restarted for months. The Foundation’s verdict on itself is blunt: “the delay was a structural failure”.

AI’s real contribution was to remove the excuse for leaving it open. A theoretical bug with no exploit can sit in a backlog for years. Once someone can build the exploit in days, that backlog entry is an incident with no date on it yet.

Even the release ran on thin margins. The CVE identifiers leaked early, the release was pulled forward a day, and a demo video and a vendor’s early patched images both went out before the embargo lifted, according to the Foundation. Once the patch was out, Amazon saw new proof-of-concept exploits within hours.

What it means for enterprise AI

Amazon draws the conclusion most security teams now have to absorb: “A 7-day or 30-day SLA assumes a delay that no longer exists.” Its argument is that AI-assisted analysis makes it cheaper to turn a patch diff into a working exploit, so for critical internet-facing flaws the clock should run in hours.

The second lesson concerns running AI over your own code, which many enterprises are piloting. The PHP Foundation already does this. It scanned PHP with Anthropic’s Claude Mythos through Alpha-Omega earlier this year and now uses OpenAI’s Daybreak Red to validate reports. Since 1 July the team has published 15 CVEs and worked through more than 100 reports that were invalid, duplicates or not reproducible. AI helps sort and group the reports, “but a person makes every call and works on every patch”.

That ratio is the budget line many AI security pilots leave out. A scanner raises the number of findings much faster than it raises the number of people able to judge and fix them. The PHP team had funded staff and a public spotlight, and it still names its own decision process as the point of failure.

A security leader should be able to answer three questions before buying a scanner. Can we find every internet-facing copy of a vulnerable component, including the ones buried inside vendor products? Who can approve an emergency patch or mitigation when the normal route is too slow? Do we have the engineers to check findings and ship fixes as fast as our exposure now demands?

CISA’s alert asks for that first inventory for PHP, and warns that PHP often sits embedded in other software. AI pilots tend to add to that hidden layer, with admin panels and vendor-hosted dashboards that nobody lists as infrastructure.

Calif’s point about generally available models cuts both ways. If the first discovery needed nothing special, attackers have the same tools. The edge defenders still hold is people who know a system’s history and can tell a model where to look.

Finding was the cheap part this time. The question worth asking of any AI security programme is how long a confirmed bug waits for someone to decide on the fix, and who has the authority to end that wait.