PHP2Shell: What CVE-2026-109618 and CVE-2026-109619 Mean for Your PHP Server

CVE-2026-109618 concerns out-of-memory handling. PHP jumps out of the current context when it runs out of memory, and some contexts can leave request memory uninitialized when that happens. The cleanup that runs at the end of the request may then read that invalid memory.

CVE-2026-109619 concerns state that outlives a request. PHP has global state that temporarily points into request memory, and in some scenarios it is not reset correctly. A later request handled by the same worker can use that state after the memory behind it has been freed.

Neither flaw is trivial to exploit. The scores reflect high attack complexity, and reliability depends on the build, worker count, and memory layout. Public exploit code varies in quality too. That has not stopped attackers from trying at scale.

PHP's advisory lists PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, and LiteSpeed as at risk, but the evidence differs by setup. Full code execution has been validated against mod_php over HTTP with default limits. For FPM the picture is more conditional: the session upload progress path was validated against both mod_php and FPM, while PHP says no complete FPM exploit has been demonstrated for CVE-2026-109618.

One detail removes a common assumption. Session upload progress is enabled by default, and PHP says no application call to session_start() is required for that path. An application that never uses sessions is not automatically out of reach. Running FPM lowers your risk in some scenarios, but it is not a reason to delay.

PHP planned a coordinated release at 14:00 UTC on October 21. Details leaked first, and proof-of-concept code was public by about 02:00 UTC that day. Amazon says it found an exploit attempt in its honeypot telemetry dated October 17, four days before disclosure, which is why compromise checks should look back further than the patch date.

Reports since then fill in the picture, with some caveats. watchTowr says its honeypots saw exploitation in the wild, and Patchstack reported incidents through hosting partners within hours, according to Recorded Future. Arctic Wolf saw widespread scanning, along with requests reusing older techniques that have nothing to do with these bugs. Recorded Future cautions that reporting does not establish the full extent of successful compromises.

Move to PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35, or later. PHP 8.1 and older get no releases, though the project published minimal source backports for 7.4, 8.0, and 8.1. Treat those as a bridge and plan the upgrade, keeping in mind that PHP 8.2 itself reaches end of life on December 31, 2026.

Version numbers can mislead in both directions. Distribution packages often backport fixes while keeping an older version number, so check your vendor's advisory. The php -v command can also report a different binary from the one serving web requests. Confirm what your web server actually runs, and restart the workers afterward so that the new code is loaded.

Downstream products take time. The Dutch NCSC's tracker listed 948 products on November 4, with 215 marked vulnerable, 185 fixed, and 93 under investigation. Hosting panels have moved at their own pace as well: CloudLinux and Plesk both published updates, and Plesk notes that its own panel engine needed patching too.

PHP calls updating the only reliable mitigation, and Amazon notes there are no configuration-only workarounds that fully address both issues. The partial measures are still useful if you truly cannot patch today. They include setting memory_limit to -1, disabling session.upload_progress.enabled, and on PHP 8.5, disabling fatal_error_backtraces.

Each has limits. PHP says an unlimited memory_limit is not a complete mitigation, since an underlying allocation failure can still reach the vulnerable path, and it removes a safeguard against runaway scripts. Disabling upload progress blocks the confirmed session paths but not every variant. Security vendors disagree on how much these settings help, so use them only to buy a few hours. Web application firewall rules, including the Imunify360 rulesets CloudLinux describes, are interim measures as well.

A patched server can still be a compromised server. Because exploitation appears to predate disclosure, review your logs from at least October 17. Preserve logs first, since many servers rotate them quickly. If you find a sign of compromise, isolate the host, rotate every secret PHP could read, and rebuild from a known good state instead of cleaning in place.

Coding assistants generate PHP readily, and plenty of revenue-earning products sit on WordPress, Laravel, or a generated store. A generated Dockerfile might pin php:8.1-apache because it appeared in a tutorial, and that single line would mean mod_php, on an unsupported branch, with no upstream release coming. The application can look completely healthy the whole time.

PHP2Shell was not caused by anyone's code quality. It does show what happens to software nobody owns. A team with an inventory and a tested deploy pipeline could patch within hours of October 21. A site whose builder has moved on could stay exposed for months while automated attacks continue.

If you are earning money on a PHP stack and cannot quickly say which version is running, it is worth bringing in an experienced engineer. They can confirm what is deployed, review it for compromise, upgrade off unsupported branches, and set up a routine so the next advisory takes an afternoon. That is the work behind our production hardening engagements and retainers.