The October 2026 PHP security release fixes two critical remote code execution bugs, and on Magento the question that decides your urgency is how PHP is wired into the web server. PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 shipped on October 21, 2026. Both flaws are rated 9.2 under CVSS 4.0, neither needs a login, and the worst case runs before a single line of Magento code executes. Mitigations exist, but none of them make a store safe.
What changed in the PHP RCE security release
PHP patched CVE-2026-109618 and CVE-2026-109619 in every supported branch on October 21, after a public warning one day earlier that a critical release was coming. The PHP news archive carries both the advance notice and the advisory, which tells all PHP users serving web traffic to update immediately.
The first bug, CVE-2026-109618, sits in out of memory handling. When an allocation fails at the wrong moment, PHP abandons a request while some of its internal data is only half set up, and the cleanup step then treats that data as valid. The GitHub advisory for CVE-2026-109618 lists several ways a crafted multipart request can drive memory use up while staying inside the configured limits: a body without a usable length, parts with an unbounded number of headers, and empty file fields that do not count toward the upload cap but still allocate arrays.
The second, CVE-2026-109619, is a use after free across requests. A worker keeps some global state pointing at memory that belonged to the previous request. If the next request on the same worker touches that state before it is reset, an attacker who shapes the heap can take over the process. Session upload progress is one of the known paths, and the PHP team followed up on October 23 with a related, less likely variant tied to switching the session serializer at runtime.
mod_php vs PHP-FPM: who is most exposed
Apache with mod_php carries the highest risk, because the PHP team demonstrated an exploit where an unauthenticated request triggers the bug during request startup, before any application code runs. Apache always calls PHP's shutdown routine, even when startup failed, and that routine is where the corrupted state gets used.
PHP-FPM is susceptible but harder to hit. When request startup fails, FPM kills the child process instead of cleaning up, which removes the easiest path. The advisory still rates FPM as exposed through memory exhaustion later in a request, and says no complete FPM exploit has been shown. FrankenPHP behaves like mod_php on shutdown and is likely exposed in the same application independent way. LiteSpeed and php-cgi are listed as at risk too.
For Magento this splits the market cleanly. Most modern Magento and Hyvä storefronts run nginx in front of PHP-FPM, which is the lower risk path. The stores still on Apache with mod_php are usually the older ones on shared or legacy managed hosting, and those are the stores least likely to have someone watching the PHP announcements. A pre-authentication bug with a working exploit against that setup should be patched within days, not in next month's maintenance window.
FPM is still not safe. Magento is a memory hungry application with large imports, layered navigation queries and admin grids that can all reach the limit under hostile input. Treat FPM as buying you a little time to schedule the patch properly, nothing more.
Why the mitigations do not fit Magento
The interim mitigations for CVE-2026-109618 clash with how Magento is tuned, so on a Magento host updating PHP is the only realistic fix. The PHP team suggests removing the memory limit entirely, with memory_limit=-1 set where applications cannot override it, plus a low post_max_size of 8M or 32M. On a Magento web pool, an unlimited memory setting turns one bad admin export or runaway query into a worker that eats the whole server. Adobe documents a finite memory_limit as a required PHP setting for a reason.
The size cap is a problem of its own. Catalog imports, media uploads and some B2B quote attachments regularly exceed 32M. Stricter limits at nginx or the load balancer on header count, multipart parts and body size are worth adding anyway. They are not a fix.
The CVE-2026-109619 mitigation is easier. Setting session.upload_progress.enabled=0 and restarting every worker has no visible effect on a typical Magento storefront, since checkout and admin uploads do not rely on PHP's upload progress feature. If you cannot patch today, apply this one today.
The Magento version trap: PHP 8.1 and PHP 8.2
Stores on Magento 2.4.6 running PHP 8.1 have no official patched build, because the PHP project stopped shipping 8.1 builds when that branch left support. The PHP team made an exception and published minimal source backports for 7.4, 8.0 and 8.1, but a store owner on managed hosting rarely compiles PHP. In practice the fix there comes from the Linux distribution or an LTS vendor, or from moving to PHP 8.2.
That move is itself short lived. The Adobe Commerce system requirements pair 2.4.6 with PHP 8.2 and 8.1, 2.4.7 with 8.3 and 8.2, 2.4.8 with 8.4 and 8.3, and 2.4.9 with 8.5 only. Upstream support for PHP 8.2 ends on December 31, 2026. A 2.4.6 store that jumps to 8.2 this week to get the RCE fix will be back on an unsupported runtime in ten weeks. That is the real argument for planning the 2.4.7 or 2.4.8 upgrade now, while the PHP patch is fresh in everyone's mind. We laid out a similar triage logic for last month's release in our PHP 8.4.26 streams vs curl breakdown.
What we would do this week
Patch PHP on every Magento host this week, then prove the patch is live on the web workers, not just on the command line.
First, find the SAPI. Check whether each environment serves PHP through FPM, mod_php or something else. Anything on mod_php goes to the top of the list, including forgotten staging servers that are reachable from the internet.
Second, update to the fixed version for your branch and restart every PHP worker. The stale state bug lives in long running workers, so an updated binary with old workers still running is not patched. Reload FPM pools, restart Apache, and redeploy containers built from images that predate October 21.
Third, verify on the web path. php -v on the shell reports the CLI binary, which is often a different package from the FPM one. Check the version through an FPM status page or a protected diagnostic endpoint, then remove that endpoint.
Fourth, disable session upload progress as a belt and braces setting, and add request size and header limits at the edge.
Finally, put the Magento and PHP version pairing on the roadmap. If the store is on 2.4.6 or PHP 8.2, the end of year deadline is close enough that the upgrade belongs in the next sprint plan, not the next budget cycle.