Security Notes.
On 21 October the PHP project published a critical advisory with a short instruction: update now. Two remote code execution flaws, CVE-2026-109618 and CVE-2026-109619, are both rated CVSS 9.2. The first is triggered when PHP runs out of memory halfway through setting up a request and later cleans up data that was never fully initialised. The second lets internal state from one request outlive its memory, so the next request served by the same worker can pick it up. Every PHP setup that serves web traffic is affected — PHP-FPM, mod_php, php-cgi, FrankenPHP and LiteSpeed — with mod_php at the highest risk.
The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The advisory is clear that there is no complete workaround: patching is the only safe option.
What we did before the fix existed. The vulnerabilities were announced ahead of the release, so for the hours in between we reduced exposure on the servers we look after. We turned off session upload progress, which the advisory lists as a partial mitigation for the second flaw, and enforced strict session mode as extra hardening. Both settings went into every PHP runtime on each host and inside application containers, and we checked them against the PHP workers actually answering requests rather than trusting the config files.
Patching the same day. Once the releases were out, the usual distribution packages and official container images had not caught up yet. Rather than wait, we built the fixed versions from the official, checksum-verified PHP sources, kept each server's existing extensions and settings, and rebuilt OPcache to match. Applications still on PHP 8.0 or 8.1, which no longer receive public releases, got the PHP project's official security backports instead of an emergency version jump. Container-based applications were moved to the patched 8.4.27 image, with the base image pinned so a future build cannot quietly fall back to a vulnerable one.
Checking, not assuming. A version number alone proves nothing when a patched build and an unpatched one can report the same string. So every active web pool was verified for the engine and OPcache build it really runs, and the public storefronts, login pages and demo sites were checked afterwards. All twenty-three active PHP pools across our own and our clients' environments passed.
What this means for your store. If you run Magento or any other PHP application and haven't updated since 21 October, treat it as urgent. Check the PHP version your web workers actually run, not just the command line, and plan the move off PHP 8.0 and 8.1 if you still depend on them. Security backports buy time; they are not a long-term home.
If you'd like a second pair of eyes on your stack, or want us to handle updates like this for you, get in touch — keeping stores safe and running is a big part of what we do every day.