Conceptual image of a technician disconnecting a network cable, illustrating precautionary website shutdowns during the PHP2Shell response — PHP2Shell prompted precautionary website shutdowns while operators prepared emergency PHP updates. *AI-modified* © Popular AI

Website operators around the world deliberately took services offline on October 21, 2026, after two critical PHP vulnerabilities threatened to let unauthenticated attackers take control of affected servers. Government agencies and media organizations were among those responding. The flaws, collectively dubbed PHP2Shell, had survived for years. AI helped researchers turn them into working attacks, helped defenders test fixes, and may now make unpatched servers easier to target.

The PHP security team released emergency updates on October 21. As of October 22, the incident remains a live security problem. The widespread downtime reflects operators’ precautions, however, and does not establish that the affected websites were hacked.

Why PHP2Shell put so much of the web at risk

PHP executes server-side code for websites built with WordPress, Drupal, Joomla, MediaWiki, and many other systems. Security company Wiz estimates that PHP powers roughly 70% of websites. That estimate describes the language’s reach. It does not tell us what proportion of websites were vulnerable or how many have been compromised.

The two flaws, CVE-2026-109618 and CVE-2026-109619, both received a critical 9.2 rating under CVSS 4.0. One involves out-of-memory handling that leaves partially initialized internal structures behind. The other involves a fatal error leaving references to memory that has already been freed. Under exploitable conditions, a subsequent request can misuse that corrupted state.

Imagine a hotel clearing a room but failing to cancel an old key card. The next guest inherits a room where yesterday’s key still works. PHP’s memory handling is far more complex, but the broken assumption is similar: something that should have been invalidated remains usable.

Wiz demonstrated remote code execution against WordPress, Drupal, and Joomla, along with process-memory disclosure that could expose credentials and tokens. Those demonstrations established exploitable paths in vulnerable configurations. They were not evidence that every installation of those applications had been breached.

The potential consequences explain why government and institutional websites across Europe were temporarily suspended. Operators faced a choice between controlled downtime and leaving services exposed to a flaw that could give an attacker remote access.

AI helped prove an old PHP bug was exploitable

The discovery story began well before this week’s emergency. During a 2024 security audit, a PHP developer identified signs of the out-of-memory problem. The team explored fixes but lacked a demonstrated route to remote code execution. Proposed solutions carried difficult compatibility, performance, or extension-maintenance tradeoffs. Work on the repair repeatedly stalled, according to the PHP Foundation.

Calif researcher Ryan Austin began investigating PHP on July 30, 2026, through OpenAI’s Patch the Planet initiative. He drew on PHP’s vulnerability history to steer the research. Calif found exploitable paths in early August and formally reported an attack on August 11. OpenAI independently reported the same underlying problem that day. Wiz subsequently submitted related findings.

Calif used GPT-5.6 Sol in the discovery, according to OpenAI. Wiz says its researchers used Gemini 4 Argon, GPT-5.6 Sol, and Wiz Atlas to find variants, develop and adapt exploits, identify attack patterns, and validate patches.

The models helped researchers work through failed tests and propose the next experiment. That reduced the effort needed to investigate exploitation paths that had previously been difficult to prove, and to adapt attacks to different conditions.

A human expert still guided the research. Austin credits his knowledge of historical PHP bugs and warns that generic prompts will not make a model uncover every vulnerability. The researchers supplied direction and judgment while the models helped them investigate and iterate.

Leaks disrupted the PHP2Shell disclosure timeline

The patch was originally scheduled for October 22 at 14:00 UTC. On October 20, vulnerability identifiers circulated with an incorrect severity score and release time. No technical details were initially exposed, but PHP moved its announcement and patch release forward by one day.

Calif then mistakenly published a proof-of-concept video, and copies spread after its removal. On October 21 at 07:41 UTC, Chainguard released images containing the fixes, breaking the embargo more than six hours before the coordinated public release. A determined researcher could compare those patched binaries with earlier versions to investigate the changes. The PHP Foundation documents both the video’s publication and the premature release of patched images.

The earliest suspicious activity predates those leaks. Amazon’s decoy servers recorded an apparent PHP2Shell exploitation attempt on October 17, three days before the public leak. Amazon does not know how the actor learned of the flaw or whether the attempt would have worked against a real server.

Further attempts followed, and Amazon reported broad exploitation activity after disclosure. The leak aggravated an already dangerous situation, but the October 17 observation means the public leak cannot explain all the activity Amazon detected.

PHP2Shell timeline: apparent decoy-server exploit attempt on October 17, identifier leak on October 20, premature patched images at 07:41 UTC on October 21, and emergency PHP updates on October 21 — PHP2Shell disclosure timeline, from the earliest reported decoy-server attempt to emergency patches. © Popular AI

AI tested the fixes. People wrote and released them

The emergency repair was a human-led engineering effort. The PHP Foundation says its maintainers made the decisions and worked on every patch. AI helped validate reports, group duplicate findings, test exploitability, and check repairs. OpenAI also describes using frontier models to look for ways around the proposed fixes.

Meanwhile, Cloudflare activated protective firewall rules for customers by 03:02 UTC on October 21, roughly nine hours before disclosure, according to the company. Providers coordinated protective measures while distributions prepared patched packages.

Those filters bought time, but they cannot guarantee that an unpatched PHP server is safe. The core repair still needed to work across PHP’s supported configurations without breaking the applications that rely on them.

Attackers can use the same model-assisted reasoning to inspect a newly released fix, infer the bug it repairs, and adapt proof-of-concept code. Amazon warns that patch-to-exploit timelines can shrink to hours or minutes. For operators trying to schedule an update, that leaves little room for delay.

What website owners should do about PHP2Shell

The fixed PHP versions are 8.2.35, 8.3.36, 8.4.27, and 8.5.12. Update the PHP runtime that actually serves web requests. Updating WordPress or its plugins does not replace that work. Check your hosting provider’s installed build and security backports, especially on servers that use distribution-managed packages.

PHP 8.1 and older no longer receive upstream support, although certain vendors supply backported fixes. Firewalls and configuration changes can reduce specific attack paths, but the PHP team says applying the fix is the only complete remediation. If an exposed deployment cannot be patched, temporarily removing public access may be the safer course.

Because Amazon observed suspicious activity as early as October 17, operators should review server logs, unexpected process execution, and file changes from at least that date. A successful update prevents future exploitation of these flaws. It cannot undo a compromise that happened before the patch was applied.

For smaller teams, our guide to faster patching in the age of AI security tools explains how to make this response routine, with less dependence on a last-minute scramble.

PHP2Shell leaves unpatched servers in a shorter race

AI helped researchers prove that an old, difficult PHP bug could be exploited. It also helped defenders investigate the flaws, validate repairs, and prepare protections. Distributing patches, coordinating disclosure, and deciding how to change PHP safely still depended on experienced people working under pressure.

Finding and exploiting vulnerabilities is becoming cheaper. Getting a repair onto millions of independently managed installations remains slow. For website owners, the response is concrete: confirm that the web-facing PHP runtime has received the fix, then investigate possible activity before the update. A restored website needs both checks.

PHP2Shell: How AI found the flaw that took…