OpenAI's PHP2Shell Exposes 70% of Websites to Remote Code Attacks

The PHP project has patched two critical interpreter flaws, tracked as CVE-2026-109618 and CVE-2026-109619, after a two-month disclosure process involving PHP maintainers, OpenAI, Wiz, Cloudflare and government agencies. Researchers found the vulnerabilities through human-led, AI-assisted security work and demonstrated unauthenticated remote code execution against common PHP deployments.

PHP’s reach gives the flaws an unusually broad attack surface. Wiz’s analysis cites estimates that PHP runs on roughly 70% of websites with a known server-side language, including sites built with WordPress, Drupal, Joomla and MediaWiki. OpenAI’s disclosure describes PHP2Shell as an early example of a frontier model helping researchers find an internet-scale vulnerability before widespread exploitation.

How request cleanup becomes code execution

The PHP security team assigned each vulnerability a Critical rating and a CVSS v4.0 score of 9.2. Both flaws reside in the interpreter, so exploitation does not depend on a bug in WordPress, Drupal or another application. Wiz reports that a minimal PHP script was sufficient in its tested configurations, although reachability still depends on the server and worker setup.

PHP can call longjmp() to escape the current execution path after an out-of-memory condition. That jump can bypass ordinary initialization and cleanup steps. When shutdown code later handles partially initialized data or a pointer to released memory, an attacker may gain memory access and eventually control execution.

• CVE-2026-109618: An out-of-memory condition can interrupt request initialization. Cleanup code may then process invalid internal data as though initialization had completed.
• CVE-2026-109619: A pointer associated with one request can survive after its backing memory has been released. A later request handled by the same worker may use that stale state before normal initialization replaces it.

Persistent workers increase the second flaw’s reach because PHP-FPM and similar server processes handle many requests during their lifetime. Wiz demonstrated unauthenticated code execution against default container images for WordPress, Drupal and Joomla. Its researchers also extracted PHP worker memory containing data such as passwords, tokens and API keys.

Every PHP release from version 5.4 onward is affected by at least one of the flaws, according to the disclosures. Supported branches have patches, while end-of-life branches require migration or strict isolation.

Fixed releases and deployment steps

Runtime upgrades are required independently of CMS and framework releases. Production teams should complete the following steps:

1. Inventory every PHP runtime. Check CLI, PHP-FPM, Apache modules, scheduled jobs, serverless functions and container images separately because they can load different binaries.
2. Upgrade supported branches. Rebuild immutable images from patched base images instead of modifying only running containers.
3. Restart persistent processes. Existing PHP-FPM and web-server workers retain the vulnerable interpreter until they are replaced.
4. Verify the deployed version. Confirm the version inside each running workload and inspect orchestration systems for replicas using older images.
5. Contain end-of-life installations. Remove direct internet exposure, restrict allowed clients, segment the host and schedule migration to a supported branch.
6. Review exposed systems. Investigate unusual out-of-memory events, crashes and repeated worker restarts around suspicious requests. Normal operations can produce the same events, so correlate them with HTTP, process and network telemetry.
7. Protect resident secrets. Rotate credentials if evidence suggests that an attacker read worker memory or executed code.

Cloudflare has released WAF rules, while Wiz has published a runtime policy that terminates processes identified as exploiting PHP2Shell. These controls can reduce exposure while the vulnerable interpreter remains present.

Technical details leaked on October 20, 2026, one day before the planned disclosure. watchTowr reported reproducing CVE-2026-109618 before patched packages became available, and public proof-of-concept code is now circulating.

Three AI-assisted teams converge

Research teams at Wiz, Calif and OpenAI independently identified the same vulnerability class. The published accounts describe researchers choosing targets, directing analysis, reproducing crashes, developing exploits and validating fixes with support from frontier models.

OpenAI says the Calif team used GPT-5.6 Sol through the Patch the Planet initiative. Wiz used Wiz Atlas alongside Gemini 4 Argon and GPT-5.6 Sol, crediting Gemini with contributions to vulnerability discovery, exploit development, attack detection and patch validation.

Wiz reports that one researcher completed the work in a week and estimated that a conventional team would previously have needed months. The disclosures provide no standardized benchmark for that comparison, but they document model use across the full research cycle, from source analysis through adversarial testing of the patch.

Two months inside the defender’s window

OpenAI calls the interval between private frontier-model discovery and broad reproduction the “Defender’s Window.” During that period, maintainers can prepare fixes and downstream operators can deploy them before exploit development becomes widely accessible.

The PHP2Shell response took about two months because the repair required changes to the PHP engine, backports across four supported branches and testing for bypasses and related variants. Hosting providers, WAF vendors and security teams also needed time to prepare mitigations and deployment guidance.

OpenAI says the coordination included the White House’s Super Intelligence Force, the Office of the National Cyber Director, the Cybersecurity and Infrastructure Security Agency and international partners. Their role was to help notify critical infrastructure operators and other organizations that might not receive upstream security notices quickly.

OpenAI’s five-stage playbook

OpenAI proposed a five-stage process for future AI-assisted discoveries in widely deployed software:

1. Validate and repair upstream. Reproduce the vulnerability, develop a fix and use adversarial testing to search for bypasses and related flaws.
2. Notify downstream operators. Give distributors, cloud providers, hosting companies and security vendors time to prepare updates.
3. Reach critical infrastructure. Coordinate with government partners that can contact essential service operators.
4. Close coverage gaps. Prepare updates and mitigations for downstream products, unsupported configurations and delayed upgrade paths.
5. Publish and deploy. Release technical guidance when patches become available and support organizations during rollout.

OpenAI also committed $1 billion in subsidized access to its Daybreak security program for resource-constrained organizations that protect essential services. The company says it will provide Codex subscriptions to open-source maintainers and continue funding ecosystem organizations such as the Rust Foundation.

The engineering work after PHP2Shell

• Treat the runtime as a tracked dependency. Record the PHP branch, exact patch release, SAPI, extensions, container digest and base image for every workload.
• Audit mature native code. Interpreters, parsers and long-running services written in memory-unsafe languages contain complex state transitions that model-assisted tools can inspect at scale.
• Keep humans in the verification loop. Researchers must reproduce model findings, establish exploitability, test patches and check for variants before disclosure.
• Prepare emergency release paths. Maintainers need monitored security contacts, private build infrastructure, backport plans and a process for notifying downstream vendors under embargo.
• Rehearse fleet-wide upgrades. Teams should be able to identify affected instances, rebuild images, restart workers and verify deployed versions within hours.

PHP2Shell shows how model-assisted research can compress vulnerability discovery and exploit development into a much shorter cycle. Developers and operators can preserve a defensive lead through precise runtime inventories, rapid rebuilds, adversarial patch testing and coordinated releases across the software supply chain.