Michael JohnsonOn October 21, 2026, PHP announced two critical vulnerabilities that could allow unauthenticated remote code execution. On the same day, the project released fixes for branches 8.5, 8.4, 8.3, and 8.2 and recommended that users update without delay. Installations serving web requests may be vulnerable, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, and LiteSpeed, PHP reports.
The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. The releases address CVE-2026-109618, involving state corruption under memory exhaustion, and CVE-2026-109619, an error that could allow the state of one request to persist in a worker process and be used while handling the next. Versions below those listed are affected. The project no longer provides its own updates for PHP 8.1 and older branches, so administrators of those systems should check whether fixes are available from their distribution vendor or LTS provider.
Two errors in the web request lifecycle
In CVE-2026-109618, request handling may be interrupted by memory exhaustion while internal data is still only partially initialized. During shutdown, PHP may then access an invalid state. In its advisory, the developers describe scenarios involving multipart requests and exhaustion of the memory limit. For Apache mod_php, a scenario in which the issue occurs before application code runs has been confirmed; PHP also notes that the risk is higher for this configuration.
CVE-2026-109619 affects state retained by a worker process between requests. If an operation fails before the data is cleared, memory from the previous request is freed while a reference to it remains. The next request handled by the same process may access the stale state before normal initialization. In the project advisory, PHP describes confirmed paths involving early diagnostic operations and file-upload progress handling; whether a particular path applies depends on the configuration, application, and extensions in use.
Both vulnerabilities received a CVSS 4.0 score of 9.2. According to PHP, the confirmed impact includes code execution with the privileges of the web worker. For the memory-exhaustion flaw, the advisory confirms a full HTTP attack scenario against mod_php; for PHP-FPM, it describes code analysis and conditions for susceptibility, so these findings should be distinguished when assessing a specific deployment.
What administrators should check
First, identify the PHP versions actually serving web traffic: a single server may run separate CLI, FPM, and Apache builds, while containers and cluster nodes are updated independently. Install the corresponding fixed release for each supported branch, or a vendor package with a confirmed patch. Then restart all PHP workers and check their versions after the restart—replacing files without restarting leaves the old processes running.
For PHP 8.1 and older, check support status and whether a backported fix is available from the distribution or LTS provider. If no such package exists, plan a move to a supported branch. PHP says Linux distribution vendors received patches in advance; their package version numbers may differ from official PHP releases, so verify that the fix is included.
Temporary settings and request filtering may reduce some attack paths, but the project calls updating the only complete way to address both issues. The practical priority for teams is to inventory all web workers, install the fixed package, restart processes, and verify the result on every node. This is what addresses the confirmed vulnerabilities, rather than relying on web-server configuration alone.