PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35: critical remote code execution fixes, and how to patch without Docker surprises
PHP fixed two critical unauthenticated RCE bugs on 21 Oct 2026. Who is affected, how to check the version your web server really runs, and three Docker traps we hit while patching.
On 21 October 2026 the PHP project released 8.5.12, 8.4.27, 8.3.36 and 8.2.35. According to php.net, they fix two critical vulnerabilities that can allow unauthenticated remote code execution. Both are rated CVSS v4.0 9.2. If you serve web requests with PHP, plan to update today.
What was fixed
The project's security advisory lists two issues:
- CVE-2026-109618 (GHSA-w8hw-w9fx-j79w, "RCE via OOM corruption"): out-of-memory handling can interrupt PHP while request data is only partly initialized, so request cleanup may treat invalid data as valid.
- CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp, "RCE via stale global state"): request-owned state can survive after its memory is freed, and a later request handled by the same worker may use it before it is reset.
All versions below 8.2.35, 8.3.36, 8.4.27 and 8.5.12 are affected. The advisory calls updating the only complete fix.
Who is affected
Anything that serves web requests with PHP. The GitHub advisories discuss Apache mod_php, PHP-FPM, LiteSpeed (LSAPI) and FrankenPHP. The php.net announcement says the risk is highest for mod_php, "with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs."
Per the advisories, PHP-FPM looks susceptible by source analysis, and a session-lifecycle path was validated for the second bug; for FrankenPHP the analysis says it is likely susceptible to application-independent attacks for the first bug. The details differ per SAPI, so treat all web SAPIs as in scope.
One note on wording: php.net describes a demonstrated exploit. We did not find a primary source stating that attacks in the wild have been observed, so we do not claim that here.
Versions and end of life
- Fixed: 8.5.12, 8.4.27, 8.3.36, 8.2.35.
- PHP 8.2 reaches end of life on 31 December 2026.
- PHP 8.1 and older no longer receive updates from the project. The advisory says some vendors provide backports.
- Debian's tracker lists fixes in bookworm (php8.2 8.2.35-1
deb12u1) and trixie (php8.4 8.4.27-1deb13u1) at the time we checked.
If you cannot update immediately
The advisory lists partial mitigations that do not make an installation safe:
memory_limit = -1 ; set via php_admin_value so it cannot be overridden
session.upload_progress.enabled = 0 ; then restart workers
; PHP 8.5 only:
fatal_error_backtraces = 0
It also suggests lowering post_max_size (8M without uploads, 32M with uploads) and limiting multipart parts, headers and uploads, or blocking multipart requests at the frontend if you do not use them.
Check the version you actually run
php -v reports the CLI binary, not necessarily what answers HTTP requests. Check the web SAPI:
# inside the container or on the host that serves traffic
php -r 'echo PHP_VERSION, " ", PHP_SAPI, PHP_EOL;' # CLI only, a hint
php-fpm -v # FPM binary
For the real answer, ask a running web process: a temporary page that prints PHP_VERSION and PHP_SAPI (delete it afterwards, and never leave phpinfo() public).
Then restart every PHP process. A new binary on disk changes nothing for processes that are already running. Long-running workers (Octane, RoadRunner, FrankenPHP worker mode, queue workers, schedulers) keep the old code until restarted.
What we did at Woodander
We patched our own stack the same day. Three things cost us time, and they apply to most Docker setups.
1. Images lag behind the release. Hours after the release, the dunglas/frankenphp:1-php8.4-bookworm image still shipped PHP 8.4.26, while the official php:8.4-zts-bookworm image already had 8.4.27. We built our own base: the official PHP ZTS image, with the FrankenPHP binary copied from the upstream image (it links libphp.so dynamically). We verified that the web SAPI served 8.4.27 and will switch back once upstream rebuilds. Note that frankenphp version keeps printing the PHP version the binary was built against, so verify with a real request, not the banner.
2. The package registry was overloaded. PECL returned 504 errors while everyone rebuilt, and our build of the redis extension failed. The GitHub tag tarball of phpredis is not a drop-in replacement: it lacks the liblzf submodule. Retrying after PECL recovered worked. Cache or vendor your extension builds, and keep a known-good image so you can roll back.
3. ufw does not protect Docker-published ports. A "allow only Cloudflare" rule in ufw does not apply to ports published by Docker, because Docker's iptables rules run first. Put the restriction in the DOCKER-USER chain, or use Cloudflare Tunnel so the origin has no public port. Verify from outside:
curl -sS -m 5 -o /dev/null -w '%{http_code}\n' http://YOUR_ORIGIN_IP:PORT/
If that answers, your origin is reachable directly, whatever ufw status says. That matters most while you are patching.
Checklist
- Snapshot the server or keep the previous image tag.
- Update to the fixed version for your branch (or a vendor package that backports the fix).
- Restart everything that runs PHP: FPM, Apache, FrankenPHP, queue workers, schedulers.
- Verify the version per process, through the web SAPI.
- Make sure the origin is not directly reachable if you rely on a CDN or firewall.
- Check for compromise: unknown files in web roots and upload directories, new cron jobs, unusual processes, unexpected outbound connections, and PHP error logs with crashes or fatal errors. The advisory notes that clean logs do not prove safety.
