PHP2Shell: How AI Changed the Race to Secure the Web

On July 30, Calif began investigating PHP, software that powers websites ranging from small-business shops to major online services. By August 15, according to Calif's account, PHP's maintainers had confirmed that its demonstration of an attack worked.

Sixteen days separated the investigation's start from that confirmation. The public security release arrived on October 21. Four days before it, Amazon's decoy servers had already recorded an apparent attempt to exploit the vulnerabilities.

For a business running an affected website, the stakes were immediate: someone might be able to run code on its server without signing in. For everyone watching AI's development, there was another question. What happens when models help researchers prove a dangerous weakness, but getting a reliable fix into use still requires many people and organizations to move together?

The earlier warning matters. In 2024, PHP's developers had already found signs of the underlying problem. AI-assisted research helped make its consequences concrete in 2026. The breakthrough was turning a suspected danger into something maintainers could test and urgently act on.

Two critical flaws beneath the website

PHP is software that runs website code on a server. Visitors may never see its name, but businesses can depend on it every time a page loads or a customer signs in.

PHP2Shell covers two related vulnerabilities: CVE-2026-109618 and CVE-2026-109619. Both received critical severity scores of 9.2 under CVSS v4.0. The official advisories describe problems in what happens when PHP's work is interrupted or internal state survives beyond the memory it belongs to.

In plain English, PHP can end up treating unfinished or obsolete internal information as usable. Under relevant conditions, an attacker can turn that failure into running code on a server without signing in. The attacker would gain the permissions of the process serving the website. How far that access could reach depends on the surrounding system.

The scale deserves attention without exaggeration. W3Techs' October 22 snapshot puts PHP at 69.3% of websites whose server-side programming language it can identify. That is a measure of usage. It does not tell us how many sites were exposed, attacked or compromised.

What AI actually contributed

The research involved several teams. OpenAI says Calif used GPT-5.6 Sol through Patch the Planet. The PHP Foundation credits OpenAI's independent report and Codex Security team.

Calif researcher Ryan Austin brought a particular advantage: years of following PHP security research. He chose a historical weakness worth revisiting and used a language model to pursue that hypothesis.

His account describes the division of labor. The model helped examine memory exhaustion and places where interrupted work could leave PHP's internal bookkeeping incomplete. After the first finding, Calif turned the underlying pattern into reusable instructions for further analysis. That search surfaced another variant.

The model helped an expert follow an idea through complicated code, then apply what the investigation had learned elsewhere. Austin says the initial discovery required neither specialized testing infrastructure nor access to nonpublic models. His knowledge of where to look helped direct the work.

Wiz reports using Wiz Atlas, Gemini 4 Argon and GPT-5.6 Sol. It describes AI assistance with finding weaknesses, developing demonstrations, detection and patch validation. Its demonstrations included unauthenticated remote code execution on test deployments of WordPress, Drupal and Joomla built from their latest container images at the time, plus disclosure of sensitive process memory.

The capability claim goes beyond spotting suspicious code. A promising theory has to survive testing. Differences between applications and server configurations can make an approach fail, requiring more analysis and adjustment. Wiz says frontier models helped it develop and adapt working exploits across applications in hours.

The time claim comes from Wiz. There is no controlled human-only comparison here, and Choosely has not reproduced the demonstrations. The accounts support meaningful assistance on a difficult task; they do not establish a universal speedup or a winning model.

The potential economic effect is significant: reducing the effort needed to investigate a difficult lead could make more investigations worthwhile. This incident illustrates that possibility without measuring how widely it applies.

The fix that stalled

Quarkslab's audit, organized through OSTIF with public funding, combined code review and testing within an agreed scope.

The PHP Foundation says a developer found the first signs of the out-of-memory (OOM) problem while repairing an audit finding in 2024. Exploitation was suspected; concrete attack paths were missing. Proposed repairs could break existing applications, create new ways to disrupt service or require changes across third-party extensions. Scarce expertise and difficulty reaching consensus stalled work. The Foundation calls this a structural failure.

For a website owner, those trade-offs have practical consequences. A security update that changes how a server handles failure can also interrupt legitimate work. A repair must close the vulnerability while preserving as much expected behavior as possible across the applications that depend on it.

The OOM patch changes how PHP handles memory exhaustion: it allows a controlled stop at a safe point, with a harder limit that terminates the process when necessary. That is an engineering change to the runtime's behavior, with consequences for real workloads.

Every incoming security report adds another demand on that expertise. In an October 14 account of PHP's security process, Alexandre Daubois reported 15 CVEs since July and 106 closed reports that were invalid, duplicated or unreproducible. Each still needed attention; the figures do not establish how many submissions were AI-generated.

The team uses AI too, including Daybreak Red for validation and grouping related reports, alongside earlier access to Claude Mythos. People retain responsibility for decisions and patch review. The researchers and maintainers are both using AI, with different jobs to complete.

The race to get protection into place

Amazon Threat Intelligence reports an apparent exploitation attempt on October 17 in MadPot, its network of decoy systems. AWS says it is unclear whether the pre-release attempts would have succeeded against real-world systems. The attackers' identities, their source of information and any use of AI remain unestablished.

The final days brought a further problem: information started circulating before the coordinated release. According to the PHP Foundation's chronology, vulnerability identifiers circulated around 15:00 UTC on October 20 with an incorrect severity score and no technical details. PHP pre-announced at 19:30 and advanced release by a day. Around 20:00, Calif mistakenly published a demonstration video. At 07:41 the following morning, Chainguard released fixed images early; the Foundation says this breached the embargo.

Meanwhile, Cloudflare enabled protective rules at 03:02 UTC on October 21. PHP's coordinated release followed at 14:00. The October 20–21 disclosures cannot explain an attempt observed on October 17.

After release, AWS reported a broader exploitation picture. AWS says newly published exploits reached its sensors almost immediately and reports that PHP2Shell was being broadly exploited in the wild. Cloudflare also reports attacks against customers, with payloads changing in attempts to evade protection. Those accounts do not provide a count of successfully compromised websites.

There is a practical tension here. Operators need usable updates, which means distributors need time to prepare them. Yet releasing technical information can help attackers while other users are still waiting for protection. Even a well-engineered fix has to cross that distribution gap.

Cloudflare's filters provide a defensive layer while operators update. They do not repair the vulnerable PHP runtime.

What it means for AI tools and your website

PHP2Shell concerns the PHP runtime. It is not an identified flaw inside the language models behind ChatGPT, Claude or Gemini.

An AI-powered website can still use PHP somewhere in its own infrastructure. Imagine a business adding an AI support assistant to a WordPress site. The presence of a sophisticated model does not remove the site's existing software dependencies. Exposure depends on the PHP version, configuration and software actually deployed.

For a website owner, the useful questions are when the hosting provider applied the PHP security update and whether it has investigated suspicious activity from October 17 onward, the starting point AWS recommends. Updating a WordPress plugin alone does not repair the runtime underneath it. Cloudflare's guidance makes that distinction explicit.

PHP released fixed versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 on October 21. Older installations need an appropriate upgrade or verified vendor/backport route. Temporary mitigations are not a complete substitute.

For AI operators, this sits alongside the separate question of what authority an assistant should receive. Model behavior, permissions and the security of the software around a model all matter. None can stand in for the others.

Choosely's verdict

Calif's investigation reached a validated demonstration in just over two weeks. Another 71 days separated its August 11 report from the October 21 release. Those weeks included engineering, validation and coordination, so the dates cannot tell us how much time AI saved or isolate the time spent writing a patch.

The sequence does show how much work remains after a breakthrough. A demonstration answers whether an attack can work. A security release must protect supported deployments without introducing unacceptable failures. Then website operators must install it. The people responsible at each stage face different constraints.

PHP2Shell provides evidence that AI can assist demanding vulnerability research, including developing practical demonstrations and extending findings across applications. Turning that capability into safer websites requires sustained work at every subsequent stage.

Our assessment is that organizations benefiting from widely used software need to invest in the people who maintain it: their time, specialist knowledge and ability to resolve difficult decisions. AI can help them too. Funding those responsibilities becomes more urgent if researchers can bring serious findings to their door with less effort.

For website owners, the decisive moment comes when someone tries the attack. By then, the protection needs to have reached their server.