The Dockerfile of this blog is based on the php:8.4.27-fpm-alpine image, and the PHP in Herd on my machine reports 8.4.27 too. That works out nicely, because 8.4.27 is the first release of the 8.4 branch that fixes two critical vulnerabilities announced on October 21, 2026. Both are rated CVSS v4.0 9.2 and both lead to remote code execution without authentication. The 10.0 score that circulated on the internet the day before the announcement was wrong.
What gets fixed
The fixes shipped in versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Branches 7.4, 8.0 and 8.1 are vulnerable as well. PHP published only minimal source-level fixes for them, so check what your distribution released. Distributions often fold the fix into their package without changing the version number.
The bug CVE-2026-109618 comes from running out of memory. When a request hits memory_limit at the wrong moment, PHP leaves internal data half initialized and later reads it as valid. Datadog broke it down on the example of a hash table insert: the counters go up before the key is allocated, and when the allocation fails, the table keeps an entry nobody filled in. Cleanup at the end of the request treats it as a finished value and calls a callback based on the leftover data, whose content the attacker can influence. In Datadog's lab the attack got as far as a call to system().
The second bug, CVE-2026-109619, is about state that outlives its request. Part of the data a worker keeps between requests points into the memory of one particular request. When a fatal error interrupts cleanup, the next request on the same worker follows the pointer into freed memory (a use-after-free). The bug can be triggered, among other ways, through session.upload_progress.enabled, which is on by default and runs even without session_start(). On PHP 8.5, fatal_error_backtraces leads there too.
I did not try the exploit and I will not, so this rests on the PHP Foundation announcement and the Datadog analysis. With mod_php, the first bug shows up while the request is being processed, before a single line of your application runs. With PHP-FPM, which this blog runs on, the PHP Foundation confirmed exploitation through application code. According to Datadog, login in the application does not stop the attack, because PHP processes the request before the application code, so you cannot rely on Laravel middleware.
Attackers were ahead. AWS reportedly caught exploitation attempts as early as October 17, four days before the release. And that is how the embargo fell: Calif, who reported the first bug, accidentally published a video demonstrating the exploit, and Chainguard shipped an image with the fix more than six hours before the coordinated release.
What to do
Only the update reliably helps. Only the second bug can be mitigated: set session.upload_progress.enabled=0, plus fatal_error_backtraces=0 on PHP 8.5, in php.ini, in a file in conf.d (the official image loads no php.ini) or in the PHP-FPM pool configuration (not through ini_set(), that comes too late). Then restart the workers.
With containers, rebuild the image and deploy new containers. php -v on the host says nothing about the container. This shows the version of an official image:
docker exec <container> php -v
And check the logs to be safe. According to Datadog, a failure during request initialization leaves an Allowed memory size ... exhausted line with Unknown on line 0. A single occurrence proves nothing, several in a row are worth a look:
docker logs <container> 2>&1 | grep 'Allowed memory size' | grep 'Unknown on line 0'