All posts

AI Vulnerability Discovery Moves the Bottleneck to Fixing

Four teams found PHP2Shell flaws with AI help, one in a single night. Finding bugs is now cheap. Triage, fix decisions, and patch latency are the limits.

Misha Druzhinin
Diagram of the PHP2Shell timeline: a wide AI-assisted discovery stage feeding into a narrow fix-decision stage, followed by a patch window measured in hours.

On a Friday in October, Chainguard heard that something was coming in PHP. That night, its team found the same bug on its own. CEO Dan Lorenc wrote that they used “our harness and a frontier model” with a basic prompt: “find bad vulnerabilities in PHP.” Security researcher Justin Elze shared the screenshot with a dry caption: “You’re all prompting wrong.”

The bug was PHP2Shell, two critical remote code execution flaws fixed on October 21, 2026. Chainguard wasn’t the first to find them. Calif and Wiz had already reported the same root cause, and OpenAI had reported further attack vectors. All three say they used AI models.

Our read: finding vulnerabilities just got cheap. Fixing them didn’t. PHP first saw signs of the main bug in 2024, and the fix stalled for most of two years. If you run software in production, plan around that gap.

Key Takeaways

  • At least four groups found PHP2Shell flaws with AI help. Chainguard did it in one night, after a tip that something was coming, with a one-line prompt and its own harness.
  • The prompt wasn’t the asset. The harness was: the loop that reads code, builds, runs, and checks a finding.
  • PHP’s bottleneck was the fix decision, not discovery. The Foundation calls its two-year delay “a structural failure.”
  • Patch windows are now measured in hours. Exploitation reports arrived before the official release.
  • Measure your own time from upstream fix to production, and decide in advance who can approve a costly fix.

What happened with PHP2Shell?

PHP2Shell is two flaws in PHP’s memory management and error handling. Both allow unauthenticated remote code execution. Fixed versions are 8.5.12, 8.4.27, 8.3.36, and 8.2.35. The timeline below comes from the PHP Foundation’s postmortem unless noted.

When What
2024 A funded Quarkslab audit leads a core developer to the first signs of the memory bug. No exploit path is found, so it’s deprioritized.
2024 to 2026 Competing fixes are debated. Work stalls and restarts.
Aug 11, 2026 Calif reports an unconditional RCE with the same root cause.
Aug 24 Wiz reports the same root cause.
Sep 18 OpenAI reports further attack vectors.
Oct 16 (Fri) Chainguard hears something is coming and independently finds the bugs that night (Lorenc, via X).
Oct 20 CVE IDs circulate early with a wrong release time and a wrong CVSS score (10.0; actual 9.2). PHP moves the release up a day. Calif mistakenly posts a proof-of-concept video.
Oct 21, 07:41 UTC Chainguard publishes patched images, over six hours before the coordinated release.
Oct 21, 14:00 UTC Coordinated release.

The Foundation says Chainguard “unilaterally broke the embargo.” Lorenc says other vendors reported exploitation in the wild on Tuesday night, and that Chainguard didn’t leak anything. We won’t referee that dispute here. The more useful question for engineering leaders is why an embargo was this fragile to begin with.

Why the prompt didn’t matter

Elze’s joke lands because the prompt really was trivial. It helped to know a bug existed. But the prompt itself needed no craft, and it found a bug that had survived a decade of releases. Wiz says every PHP version released in the last decade is affected, back to 5.4 (The Register).

Chainguard hasn’t published how its harness works, so we can’t describe it. But we can say what a harness generally adds that a chat prompt doesn’t. It gives the model a loop. Read the code, form a hypothesis, build the target, run a test, check for a crash, and repeat. That loop turns a guess into a confirmed finding. We wrote about what makes that loop reliable in building an agent harness for long runs.

Two implications follow.

Discovery is no longer scarce. When four groups independently find these flaws, the same bug is probably findable by anyone with similar tooling. That includes attackers. An embargo assumes only the reporters know. That assumption is getting weaker.

The work moves to verification. A harness makes findings cheap to produce. It doesn’t make them cheap to confirm, deduplicate, or fix. That’s where PHP actually struggled.

Where PHP’s bottleneck really was

PHP’s bottleneck was deciding how to fix a known problem. Both flaws sit in code that nearly every request touches. Every candidate fix had a cost: broken backward compatibility, a new denial-of-service risk, or changes to third-party extensions.

The security team ran on consensus, and no option won. With no known exploit path and a small group of engineers who know the engine deeply, the work kept stalling. The Foundation’s postmortem calls this “a structural failure” of both its decision process and its resources. It’s now moving to majority decisions, and leadership will get involved sooner when a fix has hard trade-offs.

Meanwhile, reports kept arriving. The team has published 15 CVEs since July 1. It also worked through more than 100 reports that were invalid, duplicates, or not reproducible.

That pattern isn’t specific to PHP. Point an AI scanner at a large codebase and you get the same shape. There are many findings, a few real ones, and few people who can judge them. Human attention is the scarce input, as we argued in designing agent work around human attention.

The Foundation’s own use of AI is instructive. It uses tools to validate reports, group duplicates by root cause, and reproduce issues. But in its words, “a person makes every call and works on every patch.” That’s the right split. Automate the triage. Keep the decision with someone accountable.

How short is the patch window now?

Hours. Insikt Group at Recorded Future says PHP2Shell “went from disclosure to exploitation in hours” (Recorded Future). It reports that Patchstack saw exploitation incidents from hosting partners at 07:34 UTC on October 21. That was hours before the official fix. Recorded Future also notes the extent of successful compromise isn’t established.

Lorenc put the attacker side plainly to The Register: “People are able to build an exploit in hours.” The PHP Foundation says it found no functional public proof of concept at release time. Both can be true at once: no working public exploit, and private exploitation still possible.

For your team, the details of this dispute matter less than the direction. If discovery is cheap and exploit development is fast, your exposure is set by one number. That’s the time from an upstream fix to that fix running in your production fleet.

What should engineering leaders do?

Treat patch latency as an engineering metric, and treat AI findings as a triage problem. Here’s what we’d put in place.

1. Know where the runtime lives

Recorded Future’s guidance is to patch PHP everywhere it’s bundled: inside third-party apps, containers, and managed services. Older, unsupported branches got no fix. Most teams can list their PHP services. Fewer can list every container image that ships a PHP binary. Build that inventory from your image registry, not from memory.

2. Measure time from upstream fix to production

Pick a recent upstream security release and trace it. When did the fixed version publish? When was your base image rebuilt? When did the last affected service deploy? If nobody can answer, that’s your first finding.

Then make the path boring. Routine runtime patches are a good fit for an automated, bounded agent workflow. We described how to scope that in granting agent autonomy one class of work at a time. Patch bumps with automatic rollback are the example we used there.

3. Scan your own code, but budget for triage first

Run AI-assisted discovery on your own services before someone else does. But size the review capacity before you size the scan. A scanner that produces, say, 200 findings for one reviewer creates noise, not security.

Copy PHP’s triage steps. Reproduce each finding automatically. Group findings by root cause. Track the false-positive rate like you’d track any eval for an AI system. Route only confirmed, deduplicated issues to a person. And rank fixes by exposure, the way we suggest reviewing AI-written code by risk.

4. Decide in advance who can approve a costly fix

PHP stalled because nobody could break the tie between bad options. Your team will face the same choice: a fix that breaks a customer integration, slows a hot path, or needs a migration.

Write down who can make that call, and how fast. Make that decision before the vulnerability arrives. A consensus process works well for design reviews. It fails when an exploit is weeks or hours away.

5. Fund what you depend on

The Foundation asks companies, hosting providers, cloud platforms, distributions, and governments to fund its security work. The 2024 audit that first surfaced the bug was publicly funded. If your product runs on an open source runtime, its security team’s capacity is part of your security posture.

Frequently asked questions

Does this mean embargoes are obsolete? No. Coordinated disclosure still gives distributors time to package fixes. But an embargo now protects a shorter window, because others can rediscover the same bug. Plan as if the window may close early.

Should we build our own vulnerability-finding harness? Only if you have the people to triage its output. Start with one high-exposure service, measure the confirmed-finding rate, and expand from there.

Is this only a PHP problem? No. Any widely deployed runtime or library with old, central code is a candidate. PHP is the current example because its postmortem is unusually candid.

The bottom line

PHP2Shell shows where the work has moved. Given a tip, AI tools made a decade-old bug findable in one night with a one-line prompt. The hard part was everything after: deciding on a fix, coordinating it, and shipping it before attackers caught up.

One thing a staff engineer can do this week: trace the PHP2Shell fix through your own systems. No PHP? Use your main runtime’s latest security release. Record three timestamps: upstream release, base image rebuilt, and last affected service deployed. Share the gap with your team. That number is your real exposure window.

If your team is drowning in AI-generated findings, or can’t say how fast a patch reaches production, that’s the kind of engineering cleanup we do.

Sources