PHP2Shell: AI Found the PHP Flaw Under Most of the Web. Detection Must Now Think Like an Agent

PHP2Shell, the pair of critical PHP remote code execution flaws CVE-2026-109618 and CVE-2026-109619, was found with the help of AI. On October 17, a honeypot run by Amazon recorded someone attempting to exploit a PHP vulnerability that was not yet public. The patches shipped on October 21. By that evening, Cloudflare said it was seeing exploit attempts in the millions. The flaws sit in the web's most common server-side language, they are rated 9.2 by the PHP project, and they were found by researchers working side by side with AI models. This is the clearest picture yet of what vulnerability research looks like when the researcher never sleeps.

Two Flaws, One Root Cause

PHP2Shell is the name given to a pair of vulnerabilities, CVE-2026-109618 and CVE-2026-109619, that the PHP project rates at CVSS v4.0 9.2 and that can be triggered by an unauthenticated remote request [2][5]. They are memory-safety bugs. Wiz Research, which published the most detailed technical account, describes a shared pattern: when PHP hits a fatal error during a request, usually an out-of-memory condition, it can leave corrupted internal state behind. A later request handled by the same worker reuses that stale state [1].

Wiz walks through four concrete variants. An upload-progress unserializer can be left pointing at memory an attacker has since reclaimed. A multipart request can leave a session identifier pointing at freed memory, which a later request then encodes into a PHPSESSID cookie, leaking process memory even when the application never starts a session. A fatal-error backtrace pointer can survive into the next request. And an OPcache bookkeeping step can be interrupted so that another worker receives a pointer of the wrong type [1]. Wiz says other variants fold under the same two CVEs [1].

The reach is the story. Per BleepingComputer, the flaws affect every installation that serves web requests: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed [2]. Calif, one of the discoverers, traced the vulnerable code path back to PHP 5.4.0, according to Tenable [5]. The PHP project considers the risk highest for mod_php, where a demonstrated exploit lets an unauthenticated request trigger the attack before any application code runs [2][4].

How AI Changed the Economics

None of these bugs is new. Wiz says the underlying weaknesses had been present for decades, and OpenAI co-founder Greg Brockman told Fortune the issue had been in PHP for 14 years [1][3]. What was missing was a practical way to turn them into a working attack. Chaining a fatal error, a heap layout and a memory reclaim into reliable code execution is slow, specialised work.

That is the part AI compressed. Fortune reports that Calif found the first issue on August 1 using OpenAI's GPT-5.6 Sol and informed OpenAI. Wiz independently identified the first issue on August 19, using what it describes as Wiz Atlas, Google's Gemini 4 Argon and GPT-5.6 Sol [1][3]. Wiz says Gemini 4 Argon made an invaluable contribution to finding the vulnerability, developing the exploit, detecting attacks and validating the patch [1]. By August 20 Wiz had unauthenticated code execution against Drupal, and by August 21 against WordPress [1].

Wiz Research's own conclusion is that a single researcher completed in a week what previously would have taken a world-class team months of work.

Treat that as a vendor's claim, not a measurement. The sources do not say which findings were fully automated and which were human-directed, and they do not break out what Calif and OpenAI did with AI beyond naming GPT-5.6 Sol. But the direction is hard to argue with. Wiz notes that models can adapt an exploit to different PHP versions, configurations and memory layouts, and can analyse failures and iterate when given testing and debugging tools [1].

The Exploitation Clock Started Before the Patch

The coordinated timeline looked orderly. Wiz reported the flaws to the PHP security team on August 24. PHP acknowledged them on September 21 and began a coordinated fix [1]. Then the process leaked.

Amazon's MadPot saw the first attempt on October 17, from an address tied to a commercial anonymisation service, and more attempts on October 21 with payloads and infrastructure that suggested multiple actors. Amazon advised defenders to begin investigations from October 17, not from the disclosure date [4][5]. How the October 17 actor got details is unknown. Help Net Security and Tenable both say so plainly [4][5]. Cloudflare's Matthew Prince told Fortune it saw tens of thousands of exploit attempts within 45 minutes of the news and millions by evening [3].

What Defenders Should Do Today

Patch first. Install PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35. PHP 7.4, 8.0 and 8.1 received only minimal source backports, and older branches get nothing from the project, so check your distribution or LTS vendor and plan a migration [2][5]. If you cannot patch immediately, the PHP project's stopgaps reduce exposure but do not make a server safe: set memory_limit=-1 in a way applications cannot override, cap post_max_size, disable session.upload_progress.enabled, and on PHP 8.5 set fatal_error_backtraces=0, restarting every worker afterwards [2][5]. The UK NCSC urged organisations to update immediately or take unpatchable systems offline [2][4].

Then look backwards. Wiz suggests hunting for unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses, unexpectedly large or malformed PHPSESSID response cookies, and unexplained worker churn [1]. Amazon's advice means that window opens on October 17.

This Is Not a One-Off

PHP2Shell is the loudest example, not the only one. In the first week of October, two reports showed the same pattern from different directions.

Attackers are using agents, and the agents are loud. On September 21 an AI agent breached the Dutch Institute for Vulnerability Disclosure by chaining two Zammad flaws, CVE-2026-102489 (unauthenticated remote code execution) and CVE-2026-102490 (local privilege escalation to root), moving from a hijacked session to root in seconds [7][8]. DIVD wrote that it could watch the agent work automatically, because after every action it decided the next step itself, and that the agent's over-explaining comments made reverse engineering easier [7]. Sysdig's analysis notes the details are still developing. Zammad says it received a report on CVE-2026-102489 in August, before the breach, which complicates the zero-day label, and the sources disagree on exactly which versions are affected [7][8].

The flaws AI finds are the ones attackers want. Google Threat Intelligence Group's analysis of January 2025 to August 2026 found monthly CVE disclosures roughly doubled, from 5,045 in January to 10,740 in August, and that zero-day exploitation rose from an average of 8 a month in 2025 to 11 a month in 2026 [6]. Half of the vulnerabilities GTIG judged likely AI-discovered led to remote code execution, against 26% of others, though GTIG cautions that its AI label is inferred and the public data undercounts it [6]. One AI-discovered flaw, CVE-2026-1731 in BeyondTrust, found by the Hacktron research agent, was exploited by one threat cluster within four days of disclosure and by five more within seven [6]. GTIG also counted 2,076 vulnerabilities in AI-related software since the start of 2025, including 212 in inference and serving software such as vLLM, Ollama and LiteLLM in 2026 [6].

Put together, the picture is uncomfortable. AI is finding the severe bugs. AI is shrinking the time from disclosure to working exploit. AI agents are the ones running the intrusion. And the software used to build agents is itself a growing target.

The Future of AI-Based Threat Detection

Here is the problem with a detection strategy built on knowing the vulnerability: PHP2Shell was being exploited before it had a public name. The DIVD attacker used flaws that were not yet widely known. A signature written after the fact is a signature written after the damage. Sysdig's conclusion on the Zammad breach is the useful one: a service account spawning a shell, a process escalating to root and unfamiliar outbound connections look the same whether the exploit is a known CVE or a zero-day [8].

A caution before going further. Helixar did not discover PHP2Shell, did not detect its exploitation, and does not claim that any Helixar product would have detected or stopped it. What follows is an argument about where the industry's detection has to go, drawn from the public record.

That points to three shifts in how detection has to work.

From the vulnerability to the behaviour. The signals that Wiz itself recommends hunting for are not CVE strings. They are a web worker that fails on memory, an upload followed by repeated 500 errors, a session cookie far larger than a session identifier should be, and unexplained worker churn [1]. Those are behavioural traces. Detection built on them does not depend on anyone having published the vulnerability's name first, though whether it would catch a given exploit in production is a question for testing, not assertion.

From single events to sequences. The DIVD agent was caught not by one decisive alert but by a recognisable sequence: session hijack, shell, privilege change, credential attacks, outbound connections [8]. Each step alone is plausible. Together they tell a story. Detecting an agent means reading stories, not lines. This is the argument Helixar made in why the category still has no winner, and the research behind it is set out in the research behind agentic threat detection.

From human response time to machine response time. An agent that decides its next step at machine speed will not wait for a ticket to be triaged. If the attacker iterates in seconds, the first response has to be automated and graduated: observe, alert, require approval, block. A separate and adjacent point concerns the defender's own agents, which now carry credentials and tool access that make them worth attacking. Governing what they may do, and keeping a verifiable record of what they did, is the subject of what an AI control plane is. It is a different problem from patching PHP, and it is not a substitute for it.

There is a hopeful reading, and it is the one Google DeepMind's Raluca Ada Popa put in Wiz's post: Gemini 4 Argon helped defenders find vulnerabilities and help patch them [1]. The same capability that shortened the attacker's path also shortened the defender's. The sides will keep trading that advantage. The side that wins is the one whose detection does not depend on being told what to look for.

PHP2Shell: Frequently Asked Questions