On 21 October 2026, security researchers publicly disclosed two critical vulnerabilities in the core of PHP, the programming language behind about 70% of all websites on the internet. The flaws, identified as CVE-2026-109618 and CVE-2026-109619, are known as PHP2Shell.
They affect PHP versions from 5.4 through 8.5.11. The vulnerabilities allow an unauthenticated attacker to execute malicious code on an affected server and, in some cases, access sensitive information held in the server’s memory, such as passwords, login tokens, API keys, and certificates.
Because the flaws are in PHP itself, rather than in a specific application, any website running an affected version of PHP is potentially exposed. This includes sites built with WordPress, Drupal, Joomla, MediaWiki, e-commerce platforms, and government portals.
Researchers used advanced LLMs to prove real-world risk of PHP2Shell
These security flaws had been known for more than a decade, but they were never considered an immediate threat because researchers had not shown that they could be exploited in practice. That changed recently, when two independent teams used advanced AI models to demonstrate how serious the vulnerabilities actually were:
- Ryan Austin, a researcher at the security firm Calif, identified them during OpenAI’s “Patch the Planet” project with assistance from OpenAI’s GPT-5.6 Sol model.
- Researchers at Wiz independently found the same vulnerabilities using GPT-5.6 Sol, Gemini 4 Argon, and Wiz’s own research tool, Wiz Atlas.
Understanding PHP2Shell and its impact
PHP2Shell refers to two critical Remote Code Execution (RCE) vulnerabilities in the PHP runtime. They arise from flaws in the PHP engine’s handling of memory allocation failures and request cleanup operations.
1. CVE-2026-109618: RCE caused by Out-of-Memory (OOM) corruption. When an incoming request reaches PHP’s memory limit, the runtime uses the low-level C function longjmp() to interrupt execution. This abrupt jump bypasses the normal memory cleanup process, potentially leaving partially initialized memory structures behind. During subsequent request cleanup, PHP may access this corrupted or uninitialized memory, creating an opportunity for attackers to execute code remotely.
2. CVE-2026-109619: RCE through Stale Global State (Use-After-Free). PHP retains certain global pointers between request cycles. If error handling interrupts a request, some global pointers may not be properly reset and can continue referencing memory that has already been freed. A subsequent request may access these stale pointers during initialization or cleanup, resulting in a Use-After-Free condition that could allow RCE.
Two days after the initial disclosure on October 21, 2026, a third related vulnerability emerged: CVE-2026-115560. This flaw can also lead to remote code execution under certain server configurations. Unlike the main PHP2Shell vulnerabilities fixed in the October 21 security updates, CVE-2026-115560 required a separate fix planned for a later PHP release. In the meantime, administrators were advised to disable session upload progress by setting session.upload_progress.enabled=0.
These flaws affect most common PHP deployment configurations, including Apache with mod_php, PHP-FPM, php-cgi, FrankenPHP, and LiteSpeed. Their CVSS v4.0 scores range from 9.2 to 10.0, placing them in the critical severity category. CISA and the UK’s NCSC have also issued warnings, urging administrators to apply security patches as soon as possible.
A timeline of events
The timeline below traces how the discovery and disclosure of these vulnerabilities developed into a wider security incident.
- 22 June. Patch the Planet is announced. OpenAI introduces the Patch the Planet initiative to improve open-source security by combining advanced AI-assisted research with expert human verification. The initiative launches with support from Calif (providing advanced LLMs), Trail of Bits (expert vulnerability research), and HackerOne (coordinating triage and responsible disclosure).
- 30 July. Calif begins investigating the PHP codebase.
- 1 August. Calif discovers multiple RCE paths. Calif reports finding an out-of-memory (OOM) issue. It also identifies additional interruption points that could be combined to achieve remote code execution.
- 11 August. Calif reports the first vulnerability. Sansec records that Calif reported the first vulnerability to the PHP security team and begins coordinated disclosure process. OpenAI also independently reports the same bug.
- 19 August. Wiz Research (an Alphabet-owned cybersecurity firm) discovers another bug. Wiz identifies its first PHP vulnerability using Wiz Atlas, powered by Google’s Gemini 4 Argon and OpenAI’s GPT-5.6 Sol. The researchers later demonstrated RCE against applications including Drupal and WordPress. They explained that these security flaws were deeply hidden inside the PHP source code. Without AI assistance, finding and mapping these issues manually would have been extremely difficult and time-consuming for human researchers.
- 24 August. Wiz reports vulnerabilities to PHP. Wiz Research reported its findings to the PHP security team.
- 21 September. PHP acknowledges the reports and begins developing a coordinated fix.
- 20 October. Vulnerability details leak. Sansec reports that technical details leaked before the planned public disclosure. Cloudflare also reported observing attack traffic before the official release. Attackers were already probing for weaknesses. Cloudflare, which operates a large part of the internet’s traffic, later reported thousands of exploitation attempts in the ten hours before the public announcement. This suggests that some actors had access to the vulnerability, or to information about it, before defenders did.
- 21 Oct 2026. Public disclosure and security patches. Calif.io, Wiz, OpenAI, and Quarkslab publicly disclosed the two vulnerabilities, known collectively as PHP2Shell. The PHP project released fixes, while security providers shared protections and guidance. Cloudflare says its WAF protections were already active before public disclosure. The United States National Security Agency issued an alert recommending that every affected organization apply the patches immediately. The warning was direct: malicious actors could use the flaws to access servers without authorization, steal sensitive data, disrupt services, or move deeper into a network.
- Within 45 minutes. Cloudflare observed tens of thousands of exploitation attempts. Automated tools were scanning the internet for vulnerable systems. Attackers did not need to understand the flaw in detail. They only needed to find a target that had not yet patched.
- Within two hours. The number rose to hundreds of thousands.
- Within days. The number reached millions.
Dates vary across public accounts, particularly those describing when researchers first identified the flaws, so the timeline distinguishes between discovery, reporting, and public disclosure whenever possible.
The PHP2Shell incident was not a case of autonomous AI agents independently discovering and exploiting vulnerabilities across the internet. Human researchers remained essential throughout. They directed the queries, filtered out AI hallucinations, manually engineered the precise exploit payloads, and coordinated responsible disclosure with core PHP developers.
What should you do?
If you manage websites, maintain server infrastructure, or oversee a business’s digital assets, take the following steps immediately:
- Update PHP: Upgrade to the latest secured versions (8.5.12, 8.4.27, 8.3.36, or 8.2.35). If you use packages supplied by your Linux distribution or hosting provider, check that the latest security patches have been applied.
- Restart your services: After updating PHP, restart the relevant web server and PHP processes (Apache, PHP-FPM, LiteSpeed, etc.) to ensure that all workers load the patched runtime.
- Review access and error logs: Look for unusual multipart requests, unexpected file uploads, suspicious request patterns, and files created or modified by the web server account. Investigate any activity that coincides with the period when your server was vulnerable.
- Rotate credentials if compromise is suspected: If there are signs of successful exploitation, rotate database passwords, API keys, application secrets, and other credentials that may have been accessible to the compromised PHP process. Also investigate whether attackers could have accessed sensitive data or modified application files.
