PHP maintainers released an urgent security update on October 21, 2026, for two critical vulnerabilities that can lead to unauthenticated remote code execution (RCE). The issues affect PHP 8.2 through 8.5 and sit in core request handling: one involves out-of-memory recovery, the other state that can outlive the request that created it.
Both vulnerabilities received a CVSS 4.0 score of 9.2. The practical route depends on PHP's server API (SAPI), configuration, extensions, and application behavior, but the PHP project urged every web-facing installation to update. Apache with mod_php has the clearest application-independent exposure described in the advisories; PHP-FPM and other SAPIs also have relevant attack paths.
CVE-2026-109618: RCE via OOM corruption
PHP can use an early exit when an allocation runs out of memory. If that happens while request data is only partly initialized, the exit can leave internal state inconsistent. Request cleanup may later treat that incomplete state as valid, opening a memory-corruption path.
The upstream advisory describes multipart request parsing as one way to reach memory exhaustion within ordinary PHP limits. For example, request structure can consume more memory internally than its encoded body suggests. On Apache mod_php, the confirmed attack can happen before application code runs. The PHP Foundation also reported RCE through application-level paths under PHP-FPM, so teams should not assume that using FPM alone removes the risk.
CVE-2026-109619: RCE via stale global state
Some PHP worker state can point to memory owned by one request. If a fatal error interrupts cleanup, or state is repopulated after a reset, the worker can retain a pointer after that memory has been freed. A later request handled by the same worker may use the stale state before normal initialization replaces it.
The advisory documents confirmed paths involving fatal-error backtraces and session upload progress. Researchers demonstrated RCE against mod_php and validated a session-related path in PHP-FPM. Which path applies depends on the PHP version and how the application and server are configured. This is a cross-request lifecycle problem: the vulnerable worker must process the relevant requests, and worker pools or recycling can change reliability without fixing the underlying flaw.
A rushed release after a disclosure leak
PHP had planned to release the fixes on October 22. The CVE identifiers leaked on October 20, and the PHP project moved publication forward to October 21. The PHP Foundation says proof-of-concept material circulated during the disruption; at the time of the public release, the PHP security team had not identified a functional exploit. That was a point-in-time assessment, not a reason to delay patching.
The rapid schedule put pressure on maintainers, hosting providers, Linux distributors, and application teams to coordinate updates across a large PHP ecosystem. Distributors and long-term-support vendors received patches in advance, so package availability may differ by platform. Check the advisory from your operating-system or hosting provider as well as the upstream PHP release notice.
Who is affected and what to install
For the PHP 8.2–8.5 branches, install the fixed release for the branch you run:
- PHP 8.2: 8.2.35
- PHP 8.3: 8.3.36
- PHP 8.4: 8.4.27
- PHP 8.5: 8.5.12
The PHP advisory covers web-serving installations, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, and LiteSpeed. PHP 8.1 and earlier may also need attention; older branches are outside this article's version range, so follow your vendor's backport guidance or move to a supported, fixed build.
What administrators should do
- Inventory every PHP runtime. Check web servers, containers, control panels, staging systems, and less visible services. The command-line PHP version may differ from the version serving requests, so verify each SAPI and deployed image.
- Upgrade and restart. Apply the fixed PHP package or image, then restart PHP-FPM, Apache, or the relevant workers. Confirm the active runtime reports the patched version; a package update does not replace workers that are still running old code.
- Use temporary mitigations only as a bridge. For CVE-2026-109618, the PHP advisory recommends administratively setting memory_limit=-1 and enforcing decoded request-size and multipart limits at the proxy or web-server layer. For CVE-2026-109619, disabling session.upload_progress.enabled can block the confirmed session path; PHP 8.5 deployments can also disable fatal_error_backtraces to block one confirmed path. Restart workers after changing settings. These controls do not cover every variant and are not substitutes for upgrading.
- Review exposure during the vulnerable period. Look for unexplained PHP worker crashes, unexpected child processes, unusual outbound connections, and unauthorized file changes. Logs can help an investigation, but a clean log does not prove the issue was not exploited.
- Respond to suspected compromise. Isolate the affected service, preserve relevant logs and images, rotate credentials available to its worker account, and investigate other systems reachable from that host.
Takeaway
CVE-2026-109618 and CVE-2026-109619 are separate bugs in sensitive parts of PHP's request lifecycle, and either can put a web server at risk of code execution. Upgrade PHP 8.2–8.5 to the fixed branch release, restart every serving worker, and verify the runtime behind each site. Use configuration mitigations only to reduce exposure while the update is being completed.