PHP2Shell is the clearest sign yet that the time between "a bug is known" and "the bug is being used" has collapsed. The two critical PHP flaws, CVE-2026-109618 and CVE-2026-109619, were found and turned into working exploits with frontier AI models in weeks. Details leaked on October 20, 2026. By 07:43 UTC on October 21, Cloudflare's CTO said the company was "seeing early attacks emerging," more than six hours before the patch was public. Cloudflare also saw attackers mutating payloads to get past its new rules.
Update, October 21, 2026: OpenAI published a five-stage response framework built from the PHP2Shell coalition and floated authorized defenders patching vulnerable hosts remotely. Our analysis.
None of that needs an "AI agent hacker" headline to be serious. But agents and agent-style automation change this incident in four concrete ways, and each one has a defender response. This post covers them. For the incident basics, see PHP2Shell: what happened and what to do now on explainx.ai, and for commands, the PHP2Shell patch guide.
TL;DR
| Question | Answer |
|---|---|
| Did AI find PHP2Shell? | AI models were central: Wiz used Gemini 4 Argon and GPT-5.6 Sol; Calif worked with OpenAI |
| How fast was it weaponized? | Wiz: one researcher, about a week; RCE on Drupal one day after the first bug |
| How fast did attacks start? | Before the patch, within hours of the leak |
| Is agent-driven exploitation confirmed? | No public attribution. The attack shape (thousands of retries, mutating payloads) suits automation |
| Biggest agent-specific risk? | Leaked AI API keys from PHP memory, and coding agents running unsafe fixes |
| What to change? | Patch in hours, rotate secrets, gate and log agent shell access |
Risk 1: AI makes finding and weaponizing old bugs cheap
The PHP2Shell code had been in PHP for more than a decade. Humans got close several times: a memory-limit remote bug in 2004, PHP bug #78876 on out-of-memory handling of multipart input in 2020, and a 2024 OSTIF and Quarkslab audit that found a related issue without proving exploitation.
What changed is cost. Wiz's own timeline:
| Date (2026) | Step |
|---|---|
| Aug 19 | First vulnerability found using Wiz Atlas, Gemini 4 Argon and GPT-5.6 Sol |
| Aug 20 | Unauthenticated RCE confirmed on Drupal |
| Aug 21 | Unauthenticated RCE confirmed on WordPress |
Wiz says the models helped adapt exploits "to different PHP versions, configurations, and memory layouts" by analyzing failures and iterating. That is the hard part of memory-corruption exploitation, and it is now a loop a model can run. Calif showed the same pattern in August with wp2root, a WordPress-to-root chain it says it built with Codex "in under an hour."
The defender reading: the backlog of old, never-exploited bugs is now a real backlog. Disclosure timelines and patch cycles designed for human-speed exploit development no longer match.
Risk 2: thousands of attempts per target is an automation job
heise reports that neither PHP2Shell exploit works on the first or second try, and that one bug can take several thousand requests to trigger, with reliable RCE within thousands to tens of thousands of requests. For a human operator, that is tedious. For a scanner or an agent loop, it is nothing. The loop is simple: send a shaped multipart request, read the response, adjust the heap layout, try again.
Cloudflare's observation that attackers were "mutating payloads" to get past fresh WAF rules fits the same picture: fast iteration against a defense, the kind of feedback loop agentic tooling is built for. We have covered real cases of agents doing reconnaissance and exploitation at scale, from the Cairn agents that touched 1,200 websites to OpenAI agents probing US government sites and the Artex-based bank intrusions in South Korea. PHP2Shell is a ready-made target for that tooling: one exploit script, about 70% of websites as candidates, no login required.
What to do: treat the patch window as hours. Restrict origin servers so only your WAF or CDN can reach them; Cloudflare's rules only help "if your server accepts traffic exclusively from Cloudflare." Rate-limit multipart POSTs per client and alert on bursts of HTTP 500s after them.
Risk 3: PHP memory now holds AI keys worth stealing
The memory disclosure path in CVE-2026-109619 is the part most teams will underrate. Wiz showed that after a fatal error, the session upload progress handler can copy freed worker memory into a PHPSESSID response cookie, even on a site that never calls session_start(). That memory may contain passwords, tokens and API keys from other requests.
In 2026, a PHP worker's memory often holds model API keys. WordPress AI plugins, Laravel apps that call LLMs, support chat widgets and content tools all load an OpenAI, Anthropic or Gemini key into the PHP process. A stolen model key is directly monetizable. We covered how attackers turned hijacked cloud billing into large Gemini bills in LLMjacking via billing accounts.
What to do:
- On any host that ran a vulnerable build and showed attack signs (odd
PHPSESSIDcookies, multipart bursts with memory errors, worker crashes), rotate model API keys alongside database passwords and session secrets. - Put spending limits and alerts on every model key that a web server holds.
- Prefer scoped, per-app keys over one organization-wide key, so one leak does not expose everything.
Risk 4: your own agents, doing the patching
The fourth risk is on the defender side. On patch day, many teams will ask a coding agent to "fix PHP2Shell on our servers." Agents are good at running apt-get and editing pool configs. They also bring failure modes:
- Unverified exploit code. Tenable warns that code claiming to exploit PHP2Shell is circulating and "may contain malware." An agent asked to "test whether we are vulnerable" may clone and run one. We have seen this pattern before in fake Claude Code installers.
- Unofficial fixes. Patchstack tells site owners to avoid unofficial "fix" plugins and copy-pasted snippets. An agent searching the web can find and apply exactly those.
- Wrong restarts. A graceful Apache reload leaves the old PHP in memory. An agent that reports "done" after a reload has left you exposed.
- Mitigations left in place.
memory_limit=-1is a stopgap; left behind, it lets one request consume the server. - Broad credentials. An agent with root over SSH to fleet servers is a powerful tool and an equally powerful target.
What to do:
- Give the agent the exact plan: the target package versions from your vendor, the restart command per SAPI, and the verification step (
grep ' (deleted)$' /proc/*/mapsmust be empty). - Forbid fetching or running proof-of-concept code. Testing against your own servers with an untrusted exploit is not a test.
- Require approval for destructive or network commands, and keep a log of every command the agent ran.
Beam is built for this last point. It records the shell commands, file access and MCP tool calls that coding agents such as Claude Code and Codex make, redacts recognized secrets, and flags risky patterns in categories such as execution, exfiltration and secrets, including a credential read followed by network activity. In a connected workspace with an enforce policy, it can deny commands that the workspace policy forbids, through Claude Code and Codex PreToolUse hooks. It runs in userspace, other agents get a notice rather than a verified block, and an expired cached policy allows the action, so treat it as one layer next to review and least privilege. See how to stop Claude Code from running dangerous commands for the setup.
Why this incident is a template
Put the four risks together and PHP2Shell is a template for the next incident, not an outlier:
- AI-assisted research finds a decade-old bug in core infrastructure.
- Details leak or are reverse engineered from the patch quickly.
- Exploitation needs many attempts, which automation handles easily.
- The payoff includes secrets, including AI keys, not only shells.
- Defenders rush, often with agents, under time pressure.
The defender response is mostly old discipline at new speed: know every runtime you run, patch in hours, keep secrets scoped and rotatable, restrict what can reach your origins, and give automation the same controls you give a new administrator. Our AI agent monitoring explainer covers that last part in more depth, and data from humans missing one in three risky agent commands is why review alone is not enough.
What people ask
"Is this the 'AI hacking' moment people warned about?"
It is a step, not a cliff. The PHP2Shell research was done by defenders who reported it and waited two months for a fix. The concern is that the same capability is available to people who will not wait. Attacks before the patch show how little lead time is left.
"Should we stop using AI for patching?"
No. Agents speed up patching, and speed is what this incident demands. Scope them: known commands, no untrusted code, logged actions, and a human check on the final verification.
"Our PHP host is patched. Anything left for us?"
Yes: rotate keys if you saw signs before the patch, check your other PHP instances (staging, containers, admin tools), and review the end-of-life PHP you may still run.
Related reading
- How PHP2Shell works: out-of-memory, longjmp and stale state
- PHP2Shell patch guide
- PHP end of life after PHP2Shell
- Anatomy of an AI-driven cloud attack (Wiz)
- CVE-2026-109618 and CVE-2026-109619 in the AgentBeam CVE database
- Armadin: AI attack swarms and 90 zero-days on explainx.ai
Primary sources: Wiz Research · Cloudflare · PHP security advisory · Tenable FAQ · Patchstack · heise · Calif wp2root
Exploitation status and attribution are as reported on October 21, 2026. No public report yet attributes PHP2Shell attacks to a specific AI agent or group.