On October 21, 2026, the PHP development team fixed two critical vulnerabilities that could allow code to be executed on a server without authentication, releasing PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Both vulnerabilities are rated 9.2 (Critical) on the CVSS scale. The official announcement strongly urges all users to update promptly, and no configuration change alone fully prevents the attacks. The PHP Foundation also revealed that it had noticed signs of one of the problems as early as 2024, but that compatibility concerns and a shortage of developers made it difficult to fix.
The vulnerabilities, dubbed "PHP2Shell," lie not in a CMS or plugin but in PHP itself, the foundation on which those products run. When an earlier report on preparations for the patch release was published, the details were not yet known. The release has now revealed how the vulnerabilities work and where configuration-based mitigations fall short. It has also brought to light why the path from discovery to fix and disclosure took so long.
Both flaws stem from memory management during abnormal termination
The first, CVE-2026-109618, originates in error handling when memory runs out. Traditionally, when a memory allocation failed, PHP used longjmp() to jump out of the code being executed. However, if processing is interrupted before internal data has finished initializing, the request shutdown process may treat the incomplete data as valid. The danger is that this does not merely halt the program on an out-of-memory condition: it can trigger invalid memory access and ultimately allow arbitrary code execution.
In mod_php environments, where PHP runs embedded in Apache, it has been demonstrated that the vulnerability can be exploited before any application code runs. Unauthenticated code execution over HTTP has been confirmed, and a successful attack runs code with the privileges of the worker handling the web request. The attack reportedly worked even in environments configured with typical input sizes and memory limits, and in setups using multiple workers.
The second, CVE-2026-109619, is a vulnerability in which a problematic memory state is carried over into the next request. If a fatal error causes cleanup to be skipped, or a warning raised during shutdown re-registers internal information, a reference to already-freed memory can remain in the worker. When the same worker then accepts the next request and uses that reference before normal initialization begins, an invalid access to freed memory occurs. In other words, an anomaly produced by one request affects later, separate requests.
For this vulnerability, code execution has been verified not only in mod_php but also in PHP-FPM via session handling. However, the attack demonstrated against PHP-FPM requires that a fatal error occur after application-side processing has begun and that the same worker then handle the next request. Sending the same HTTP request therefore does not guarantee success in every PHP-FPM environment.
Wiz's research team announced that, using the latest containers available at the time of testing, it achieved unauthenticated code execution on WordPress, Drupal, and Joomla. These were the applications used for testing; the impact is not limited to those three products. Wiz also confirmed that, even when code execution is not achieved, passwords, authentication tokens, and other data can be read from PHP process memory. Because the flaws exist inside PHP, fixing an application's authentication logic or its plugins is not a fundamental solution.
Configuration changes and WAFs alone cannot fully stop attacks
When considering interim mitigations for PHP2Shell, it is necessary to distinguish between the path that triggers out-of-memory conditions and the path in which invalid state persists across requests. For example, disabling upload progress tracking or changing memory limits cannot, by itself, resolve both vulnerabilities. Based on the "Mitigation" section of the official advisory published October 21 and Cloudflare's explanation of its protections, the main interim measures and their limitations are summarized below.
| Interim measure | Attack path mitigated | Remaining risks and constraints |
|---|---|---|
Administrator enforces memory_limit=-1 |
Controllable out-of-memory conditions caused by hitting PHP's memory limit | Does not prevent allocation failures at lower layers such as the OS. Input limits at the web server and elsewhere are also needed to maintain availability |
session.upload_progress.enabled=0 |
The demonstrated path abusing session handling for upload progress | Does not resolve problems where internal state persists via other paths |
fatal_error_backtraces=0 in PHP 8.5 |
The demonstrated path abusing backtraces of fatal errors | Does not address other internal state, and is not a measure applicable beyond PHP 8.5 |
| Traffic blocking by Cloudflare's WAF | Attack traffic matching the company's detection rules | The PHP vulnerabilities themselves remain unpatched, so Cloudflare also recommends updating PHP |
This table organizes the scope of each measure; it neither ranks their defensive strength nor exhaustively lists the available settings. If PHP's memory limit is lifted, the setting must be protected from being overridden by applications, and input sizes should be capped at the web server or reverse proxy to keep the service stable. The official advisory warns that using RLIMIT_AS or RLIMIT_DATA as an alternative may itself trigger the problematic memory allocation failures.
Where settings are applied also matters. Disabling upload progress must be done in a setting that takes effect before HTTP request parsing begins, so ini_set() in PHP code or .user.ini in PHP-FPM cannot be relied upon. All workers must also be restarted after the change. Disabling error display or finding no anomalies in logs does not by itself mean attacks are being prevented.
To handle cases where the content of an HTTP request alone makes it hard to tell attacks from legitimate traffic, Cloudflare introduced a defense that inspects both requests and responses. It detects signs of an attack by also examining the responses returned from the server, blocking the matching responses before they reach the user. The company says it has actually observed attack traffic, but detecting traffic is distinct from an attacker successfully breaking in. In any case, a WAF is a supplementary defense and does not replace updating PHP itself.
The fixed releases introduce mechanisms that address the root cause rather than relying on configuration changes. When memory runs out, PHP no longer aborts processing immediately; error handling is deferred until a point where it can be done safely. If a higher memory limit is reached, the process is terminated at once, preventing processing from continuing with an incomplete internal state. Internal state that must not be retained between requests is now reset broadly. This lets PHP keep its memory limit while addressing the problem of cleanup after abnormal termination creating new vulnerabilities.
When updating, it is also necessary to check the fixed packages distributed by Linux distributions and long-term support providers. PHP 8.1 and earlier are no longer under regular support from the PHP project, but minimal source patches have been prepared for PHP 7.4, 8.0, and 8.1 as well. This measure is intended to let users who build PHP themselves address the vulnerabilities; it does not mean support for the older versions has resumed.
From a problem known in 2024 to an emergency fix
According to the PHP Foundation's explanation, signs of the memory exhaustion problem had already been found in 2024. A PHP core developer contracted by the Foundation noticed it while fixing issues identified in an external security audit by Quarkslab. The possibility of exploitation was recognized even then, but no concrete attack path had been found. As a result, other problems with demonstrated real-world impact were prioritized, and work on this vulnerability was postponed.
Technical issues also made the fix difficult. Proposed fixes included ones that would break compatibility with existing code, ones that would create new denial-of-service risks, and ones that would require changes to many PHP extensions, so it was not easy to settle on an approach. The security team's decision-making method, which emphasizes consensus among all members, also made judgment harder. Moreover, few developers are deeply familiar with the internals of the PHP engine, and each had other duties, so the work stopped and restarted repeatedly over several months.
The Foundation acknowledged that the delay was a "structural failure" stemming from the security team's decision-making process and lack of resources. Even though the problem was known, there was a large gap between recognizing it and deciding on a fix that preserved compatibility and stability, then actually distributing it. The episode shows that what was needed was not only the ability to discover vulnerabilities but also a development structure capable of making difficult technical decisions quickly.
The situation changed in August 2026, when concrete attack demonstrations were reported. According to the Foundation, Calif and OpenAI independently reported the same root cause, and new attack paths were subsequently reported by Wiz and others. This clarified the impact of the vulnerabilities, and the Foundation's security staff made fixing them the top priority. The discovery is not simply a story of AI finding a completely unknown problem from scratch; it also reflects that concrete methods of exploiting a previously recognized danger came to light.
A question about when to distribute the fixed releases also arose just before publication. After information such as the CVE numbers began circulating on October 20, the PHP development team moved the release up by one day, from the originally planned 14:00 UTC on October 22 to 14:00 UTC on October 21. According to the Foundation, distributors such as Linux distributions were still preparing update packages, and releasing immediately risked leaving users who could not easily apply the fix. Given these circumstances, a one-day advance was chosen as a compromise. Even once the fix code was complete, a separate preparation period was needed to put users in a position to actually update.
AI shortens the time to prove vulnerabilities, while challenges remain for maintainers
According to OpenAI's announcement, Calif discovered the problem using GPT-5.6 Sol as part of its "Patch the Planet" initiative. Wiz, which discovered the vulnerabilities independently, has also said it used Wiz Atlas, Gemini 4 Argon, and GPT-5.6 Sol in its investigation. However, the use of AI to find vulnerabilities and demonstrate attacks is a separate matter from completing a fix for PHP itself. It was PHP's maintainers who led the actual fix and release.
Wiz particularly emphasizes that AI streamlines the work of adapting complex attack techniques to different environments. Attacks that exploit invalid memory reads and writes succeed or fail depending on differences in PHP version, configuration, and memory layout. To make an attack that worked in one environment work in another configuration, one must investigate why it failed and adjust the method repeatedly. In the company's assessment, combining AI with testing and debugging tools can reduce the burden on the experts needed for this work. While defenders can quickly demonstrate how dangerous a vulnerability is, attackers may also find it easier to adjust their methods once fix information is published.
Meanwhile, what the Foundation faced in this fix was how to balance compatibility with existing environments against service stability, and who makes the final call. The foundation says it will revise its procedures going forward so that decisions can be made by majority vote or compromise rather than insisting on unanimity. It also plans to set up a mechanism for reporting stalled cases to leadership early. To increase the number of developers who know PHP's overall internals well, it is also calling on companies that use PHP and others for continued financial support.
The coordinated vulnerability disclosure process proposed by OpenAI likewise covers not only discovery and fixing but also preparation by distributors and the application of updates after publication. What matters in this emergency update is not just the fact that fixed releases are out, but whether the fix reaches the PHP environments that are actually handling external traffic. And to respond quickly when similarly serious problems are found in the future, it will be essential not only to make discovery and demonstration more efficient with AI but also to secure maintainers who can verify the effects on compatibility and stability and make the necessary decisions.