PHP releases urgent patches for two critical remote code execution flaws

brown wooden 9-piece office table and chairs — S O C I A L . C U T / Unsplash

The PHP security team released version 8.5.12, 8.4.27, 8.3.36, and 8.2.35 on October 21, 2026, to fix two critical vulnerabilities that allow remote code execution without authentication. The team strongly recommends that all users update immediately to mitigate the risk. These flaws, referred to as php2shell in reports by Wiz, Calif, and Cloudflare, affect all PHP environments that process web requests, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, and LiteSpeed. The risk is highest in mod_php, where attacks can succeed before application code runs, executing code with the permissions of the web request process. Specific conditions for successful exploitation vary by vulnerability type, execution environment, and configuration.

The two vulnerabilities, identified as CVE-2026-109618 and CVE-2026-109619, both carry a CVSS v4.0 score of 9.2. CVE-2026-109618 involves a memory allocation failure during the initialization of internal request data. If memory allocation fails, the process is interrupted, leaving the system in an incomplete state. Subsequent request termination processing that uses this data can lead to remote code execution. CVE-2026-109619 involves the retention of internal state from finished requests. Internal information that should be cleared per request may not be cleared after a fatal error, or it may be re-logged during termination processing. This leaves references to freed memory in the PHP worker process. If the same worker processes a new request and uses these old references before initialization, it accesses freed memory, potentially leading to remote code execution. This vulnerability has been verified in both mod_php and PHP-FPM, though conditions in PHP-FPM depend on application-side handling.

The PHP Foundation explained the timeline of the discovery and fix on October 21, 2026. Signs of the memory allocation issue were found during the remediation of problems identified in a 2024 external security audit, but no specific attack path was found at that time. The security team faced difficulties in agreeing on a fix due to compatibility concerns and denial-of-service risks. A lack of developers with deep knowledge of the PHP engine, who were also handling other duties, caused the work to stall and resume repeatedly. The Foundation acknowledged structural issues, including decision-making mechanisms and staffing shortages, that delayed the fix. On August 11, 2026, Calif reported remote code execution stemming from the same root cause as the 2024 issue. OpenAI independently reported the same root cause on the same day. These reports clarified the severity, and the security team prioritized the fix from that date.

CVE numbers leaked online on October 20, 2026, before the release. Although technical details were not leaked, the project moved the release date forward from October 22 to October 21. The delay after the leak was to allow distributors time to prepare packages so users could update easily. The security team is reviewing decision-making methods to allow majority voting. The Foundation is working to ensure executives are aware of stalled fixes early to support resolution. The team noted that while AI-assisted investigations are increasing vulnerability reports, there is a shortage of engineers who understand PHP internals deeply enough to judge fix strategies and review patches. The Foundation is calling for financial support from companies and public institutions that rely on PHP to increase this talent pool.

Mitigations are available for environments that cannot update immediately, but they only address specific attack paths. For the memory allocation flaw, setting memory_limit to -1 avoids PHP memory limit errors, though it does not fix actual memory allocation failures. Users should prevent applications from overriding this setting and restart all workers. For the internal state flaw, disabling session upload progress tracking by setting session.upload_progress.enabled to 0 is recommended. In PHP 8.5, setting fatal_error_backtraces to 0 disables backtrace logging for fatal errors. Both settings require restarting all workers. Users should also review settings that emit warnings before request initialization and fix code that causes fatal errors or timeouts from attacker requests. Suppressing error display is not a sufficient countermeasure. PHP versions 8.1 and earlier are no longer supported by the project, but minimal source code fixes were provided for versions 7.4, 8.0, and 8.1 to support users who build from source or lack vendor long-term support. Users of older versions are advised to check vendor fix availability or migrate to supported versions.