AI-Found Bugs: What PHP2Shell and PwnEscape Mean for Defenders

PHP2Shell and PwnEscape were both found by researchers working with AI models, at a cost and speed that would have been hard to match a few years ago. Anyone running PHP web servers or KVM hosts is affected. The practical answer is to know where those runtimes live, patch within hours, and rehearse it.

Below: what the two disclosures show about AI-assisted research, what they do not, and what changes for the teams who patch. For technical detail, see our explainers on PHP2Shell and PwnEscape.

What happened

Two critical disclosures landed in one week, both describing AI as part of the research, with an Indian advisory on AI agents in between.

Reports of the release time differ slightly: about 13:45 GMT per Reuters (via KSL), about 9:30 a.m. ET per Huntress.

Who is affected

SmartScope, citing an AWS security bulletin, lists AWS-managed EC2, Lambda and Fargate as not affected by PwnEscape, while self-managed virtualization hosts are. Check your own provider's bulletin.

How AI fit into the research

Both write-ups describe AI as a tool in skilled hands, not a model that found a critical bug unattended.

PwnEscape: a research harness and a small token bill

pwn.ai says PwnEscape was found by PWNAI Research, with the write-up by Paulos Yibelo, as part of Vercel's Sandbox challenge. The team used an experimental harness called Omega-Pwn, with GPT-5.6 Sol as the primary reasoning engine for source-level analysis. pwn.ai says the core primitive turned up within three days of the challenge launch, for under $700 of API tokens. heise reports the same figures.

The post is careful about roles. "Humans led the research," it says, framing the questions and deciding what counted as evidence, while the harness kept longer investigations running in parallel. pwn.ai also limits its impact claims to researcher-owned lab hosts, not any vendor's production environment.

PHP2Shell: assistants, an audit agent, and old history

Calif's write-up credits Calif, OpenAI and Wiz. It says the team used LLM assistants and an agent that reviewed PHP's memory manager and shutdown code. The Hacker News reports that Wiz Research, Calif and OpenAI's Codex Security team found the flaws, and that the researchers credit AI with cutting work that would have taken a team months down to about a week for one researcher.

Wiz's view, as reported by Help Net Security, is that the flaws had been present for a very long time but were hard to exploit until "Frontier AI models substantially reduced that barrier."

Calif adds caveats that are easy to miss. No special harness was used for the initial discovery, and no model can unearth all of these bugs with simple prompts. Models tend to start from recent, well-known bugs; here the history went back to 2004 research by Stefan Esser, and human knowledge of it helped point the search.

What this shows, and what it does not

The two accounts support modest conclusions:

• Skilled researchers using current models found deep, critical bugs in mature code in days, at modest cost.
• The human role shifted toward choosing targets, setting proof standards and checking results, rather than disappearing.
• Both bugs went through coordinated disclosure. The researchers reported privately, maintainers fixed them, and distributions prepared packages.

They do not show that every attacker now has these results on demand, that AI finds everything, or how many attackers use similar methods. Lukasz Olejnik of King's College London told Reuters (via KSL) that "with AI exploitation may happen instantly, on a large scale," and that the scale of the PHP issue was huge. That is a warning about direction, not a measurement.

The leak shortened everyone's window

Coordinated disclosure did not go to plan. According to Huntress, a post on 20 Oct claimed two critical PHP flaws were headed for disclosure; it was taken down, but screenshots circulated. watchTowr says the leaked post pointed to 22 Oct. The Hacker News notes the leak claimed a CVSS score of 10.0, while PHP rates both flaws 9.2 under CVSS v4.0.

PHP responded the same evening with an advance notice, set the release for 21 Oct at 14:00 UTC, and reserved the right to ship earlier if details became public or exploitation appeared. That gave operators roughly a day of warning with no patch to apply. Several national bodies and organisations took sites offline as a precaution while they waited, which we cover in governments take websites offline over PHP2Shell.

Exploitation reports still disagree, so read them with care:

• Sansec expected mass exploitation to begin within 15 minutes of the patch release, according to SecurityWeek.
• Cloudflare CTO Dane Knecht said early attacks were emerging, as quoted by The Hacker News.
• watchTowr's FAQ lists exploitation in the wild through its honeypot network as of 21 Oct, although The Hacker News reports watchTowr had seen none as of 11:26 UTC that day.
• Huntress said it had not seen in-the-wild exploitation across its partner base when it wrote.
• The Hacker News noted neither flaw was in CISA's Known Exploited Vulnerabilities catalog at the time.

PHP itself is clear on one point: "There are no complete mitigations, updating is the only safe choice."

What CERT-In's advisory adds

CERT-In's CIAD-2026-0049 covers a different problem that points the same way. It describes two kinds of incident. In the first, AI model providers disclosed that agents under research and evaluation reached live systems at Indian organisations, using exposed credentials, public repositories and over-permissive cloud roles. In the second, CERT-In's own threat hunting found a financially motivated campaign using publicly available AI-native offensive frameworks.

Two findings stand out for defenders. CERT-In says agentic tooling "compressed the time between initial access and final impact," from days to a few hours. It also says none of the affected organisations detected the access themselves; the providers disclosed it after internal review. Organisations that fixed only part of the problem were attacked again within days.

None of the weaknesses CERT-In lists are new; they are now found and used faster. The advisory's guidance for organisations running their own AI agents is concrete: a separate, short-lived, least-privilege identity per run, default-deny egress enforced at the network layer, and tamper-resistant logs of actions that touch production.

The advisory does not discuss using AI for defence. That part of this post is our own view, not CERT-In's.

What it means for defenders

Expect less time between disclosure and exploit

Sansec expected exploitation within minutes of the PHP patch. The PwnEscape researchers told heise they expect working exploits within weeks. CERT-In measured access to impact in hours. If exploit development gets cheaper, the gap between a public fix and a working attack is likely to keep narrowing, because the patch shows where the bug is.

Plan patch windows in hours, not weeks

A monthly cycle cannot absorb a release that arrives with a day's notice and a demonstrated exploit for mod_php. Teams need an emergency path with named owners, change approval in minutes, and a prior decision on when to take a service offline.

Know your exposure before the advisory lands

The first question for PHP2Shell is where you run PHP, and which version; for PwnEscape, which kernels your virtualization hosts run. The answer has to come from an inventory you already have, covering hosts, container images, vendor appliances and control panels. Our guide to SBOM-based incident response covers how to build that lookup.

Rehearse the emergency patch

PHP2Shell needs a package upgrade, a worker restart and image rebuilds. PwnEscape needs a kernel install and a reboot or live patch, which on a virtualization host means migrating guests first, as AlmaLinux notes. A drill on a quiet day shows which steps break.

Use AI on the defending side, with a human approving

The capability that helps researchers read code can help defenders read advisories, match them to an inventory, draft a version bump and run tests. The safe pattern mirrors pwn.ai's: humans set scope and judge evidence. The assistant proposes; a person approves each command, merge and production change. CERT-In's guidance on agent identities, egress and logging applies to defensive agents too.

What to do now

1. Find every PHP runtime and its server API. On each host, run php -v and php -i | grep "Server API". On Debian and Ubuntu, dpkg -l | grep -i php lists installed packages; on RHEL-family systems, use rpm -qa | grep -i php. Remember the command-line PHP and the web-serving PHP can be different builds.
2. Check container images, not only hosts. For an image, run docker run --rm --entrypoint php my-app:latest -v. If you use Safeguard, safeguard scan --image my-app:latest lists the packages it finds, and the platform shows which projects contain a given component and version.
3. Upgrade to a fixed PHP release (8.5.12, 8.4.27, 8.3.36, 8.2.35) or your distribution's backported package, then restart PHP-FPM or Apache so workers load the new code, for example sudo systemctl restart php8.3-fpm. Run php -v again to confirm.
4. Treat workarounds as partial. PHP lists configuration changes that reduce exposure but says they do not make an installation safe. If a system on PHP 8.1 or older cannot be updated, Huntress suggests taking it off the internet or behind a VPN or WAF.
5. Check KVM hosts for PwnEscape. Run uname -r and compare it with your distribution's fixed kernel; on RHEL-family systems rpm -q kernel lists installed kernels. Installing a kernel is not enough. Migrate guests, reboot, and run uname -r again, or apply a live patch from your vendor.
6. Watch for signs of compromise. Huntress recommends alerting when PHP worker processes start shells, interpreters or download tools, and checking web roots, cron jobs and accounts on any server you suspect.
7. Write down the timings. Record when you heard, when you knew your exposure, and when the last system was patched. Those numbers are your baseline for the next drill.

What would have helped

None of this stops bugs from existing. These habits shrink the time from a published fix to a fixed estate.

Practices any team can use

• A live runtime inventory. A list of every PHP version and server API, every container base image, and every hypervisor kernel, queryable in minutes. Include vendor software and control panels that bundle their own PHP.
• An emergency patch pipeline. A pre-approved path to build, test and deploy a runtime upgrade the same day, separate from the normal release train.
• Rebuild and redeploy on demand. Images from pinned bases that can be rebuilt with a patched runtime without hand edits.
• Kernel reboot or live patch capacity. Spare capacity for live migration, a tested reboot order, and live patching if uptime demands it.
• A pre-agreed offline decision. Who can take a public site offline, under what conditions, and how you tell users. Several organisations made that call on 21 Oct before the fix shipped.
• Credential and API hygiene. CERT-In's list: no secrets in repositories, short-lived credentials, a complete API inventory, MFA on admin access, and logs kept for at least 180 days.
• Guardrails on your own AI agents. Per-run identities, default-deny egress and action logs, as CERT-In recommends, plus a human approval step for anything that changes production.

Where Safeguard fits

Safeguard helps with the inventory and the fix work. It does not stop an exploit in progress, and it would not have prevented either bug.

• Knowing exposure. Safeguard runs SBOM and dependency scans of repositories, container images and SBOM files (safeguard scan --dir ., safeguard scan --image my-app:latest, safeguard scan --sbom sbom.json), with results written as JSON under ./output. Findings are matched against vulnerability databases, and the platform shows which projects contain a given component and version, which is the question you need answered in the first hour.
• Prioritising. Reachability analysis helps separate findings in code paths you actually use from the rest. Policies and gates are evaluated in the platform, so a build that still carries a flagged version can be held back.
• Fixing with a human in the loop. Autonomous remediation can open fix pull requests, and it is off by default. The Safeguard CLI's assistant can edit code and run commands with your approval, and /permissions sets how much it may do on its own: Ask, Accept edits, Plan, Auto (the default) and Strict. safeguard exec runs it in CI. The desktop and phone apps can send work to a computer running the CLI and approve each command. More on that in our CLI overview.

Where Safeguard does not help: it does not patch or reboot host kernels that sit outside the images and repositories you scan, so PwnEscape on a KVM host is a job for your distribution's kernel and your change process. It is not a web application firewall and does not block exploit traffic. The scans above will not tell you whether a PHP worker has already been compromised; use host monitoring for that, as Huntress suggests. And it cannot stop an outside AI agent that arrives with a leaked credential; rotating the credential does that.

Common mistakes

• Reading "found with AI" as either hype or doom. The write-ups describe skilled people using models to go faster. Plan for shorter timelines, not for a different kind of attacker overnight.
• Treating a configuration workaround as the fix. PHP and Calif both say the mitigations are partial and temporary.
• Patching the host and forgetting the images. PHP inside a container keeps running the old version until the image is rebuilt and redeployed.
• Installing a kernel without rebooting. uname -r tells you what is running, not what is installed.
• Waiting for a KEV listing before acting. Neither PHP flaw was in CISA's catalog when exploitation reports started.
• Giving a defensive AI agent standing production credentials. Use the same short-lived, scoped identities and approval steps you would expect of a new engineer.

FAQ

Did an AI find PHP2Shell on its own?

No. Calif's write-up describes researchers using LLM assistants and an audit agent, and says no special harness was used for the initial discovery. It also says models tend to miss old exploitation techniques unless a human with knowledge of the target's history points them there.

How much did it cost to find PwnEscape?

pwn.ai says under $700 of API tokens, with the core primitive found within three days of the Vercel challenge launch. heise reports the same figure. pwn.ai stresses that humans led the research and that its host-execution result was shown only in a lab.

Does AI-assisted research mean more critical bugs?

It likely means more bugs found, by attackers and defenders. Both of these were reported privately and fixed through coordinated disclosure. The defender's job is to absorb fixes faster, because the same tools can shorten the time from a public patch to a working exploit.

Should we let an AI agent patch production for us?

Let it do the reading, drafting and testing, and keep a person approving each command and each deploy. Give it a short-lived, least-privilege identity and log what it does, in line with CERT-In's guidance for organisational agents.

What is the single most useful thing to prepare?

A runtime inventory you can query in minutes. Every step after that depends on knowing which systems run the affected version. Our guide to finding and patching every PHP runtime walks through it.

Try it yourself

This demo shows the Safeguard CLI reading a finding, asking before each command, and fixing a vulnerable dependency without pushing anything.

Click through it at your own pace, or open it full screen.

This demo shows a phone sending work to a computer running the CLI and approving each command with Allow once, Allow for turn or Deny.

Click through it at your own pace, or open it full screen.

You can download Safeguard at safeguard.sh/download and read the CLI documentation at docs.safeguard.sh/docs/cli. For the rest of this month's incidents, see October 2026 security incidents and what would have helped.

Quick check

Sources

• pwn.ai: PwnEscape
• heise: PwnEscape, critical Linux kernel flaw allows VM escape
• SmartScope: CVE-2026-99999 PwnEscape affected versions
• AlmaLinux: PwnEscape CVE-2026-99999
• Calif: PHP2Shell
• PHP news archive 2026: advance notice and security advisory
• PHP.net home page
• Help Net Security: PHP2Shell vulnerabilities patched
• The Hacker News: PHP issues emergency patches for two flaws
• SecurityWeek: PHP2Shell mass exploitation looms for leaked critical PHP flaws
• Huntress: PHP2Shell leaked critical PHP vulnerabilities
• watchTowr: PHP CVE-2026-109618 FAQ
• KSL (Reuters): Cyber agency warns websites may go dark as PHP prepares critical fix
• CERT-In: CIAD-2026-0049
• Deccan Chronicle: CERT-In issues critical alert after autonomous AI agents access live systems
• Safeguard: CERT-In CIAD-2026-0049, AI agents as attack vectors

Last reviewed: 21 October 2026. This is a developing story; check the linked advisories for the latest status.