On 21 October 2026 php.net shipped PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. All four fix the same two bugs, CVE-2026-109618 and CVE-2026-109619, both rated CVSS v4.0 9.2 and both reachable by an unauthenticated remote request. The advisory lists every PHP installation that serves web requests as affected: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. It calls mod_php the highest-risk setup, because a demonstrated exploit fires before any application code runs. Your framework, WAF rules in PHP and login checks never get a say.
This guide gets a self-hosted box or container to a fixed build and, more importantly, proves that the process answering HTTP is the fixed one. It should take about 15 minutes per server.
What the two bugs are
- CVE-2026-109618 (RCE via OOM corruption). Out-of-memory handling can interrupt PHP while internal request data is only partly initialised; request cleanup then treats that data as valid.
- CVE-2026-109619 (RCE via stale global state). Request-owned state can outlive the memory behind it, and a later request on the same worker can use it before normal initialisation resets it.
Both are fixed in exactly the four releases above. There is no fixed 8.1 or older from php.net.
Step 1: find the version the web worker actually runs
The trap is that php -v reports the CLI binary. FPM, mod_php and FrankenPHP can be a different build, and a running FPM master keeps the old code in memory until it is restarted. Check what the web server answers with. Drop a throwaway file into the document root, request it, then delete it:
echo '<?php echo PHP_VERSION, " ", PHP_SAPI, "\n";' | sudo tee /var/www/html/ver-7f3a.php
curl -s https://your-site.example/ver-7f3a.php
sudo rm /var/www/html/ver-7f3a.phpTypical output:
8.3.30 fpm-fcgiThe second word tells you the SAPI: fpm-fcgi, apache2handler (mod_php), cgi-fcgi or frankenphp. Then compare the version against the fixed release for its branch. This script does the comparison and exits non-zero when the build is not fixed, so you can loop it over hosts:
#!/usr/bin/env bash
# usage: ./php-patched.sh 8.3.30
v="${1:?usage: php-patched.sh <version>}"
case "${v%.*}" in
8.5) min=8.5.12 ;;
8.4) min=8.4.27 ;;
8.3) min=8.3.36 ;;
8.2) min=8.2.35 ;;
*) echo "$v: no php.net fix on this branch, upgrade or use a vendor backport"; exit 2 ;;
esac
if [ "$(printf '%s\n%s\n' "$min" "$v" | sort -V | head -n1)" = "$min" ]; then
echo "$v: fixed (>= $min)"
else
echo "$v: VULNERABLE (needs $min or later)"
exit 1
fiOne caveat: distributions that backport security fixes often keep the old upstream version number. A Debian or Ubuntu package can say 8.2.x with a lower patch number and still carry the fix. For distro packages, check the changelog for the CVE IDs instead of trusting the number:
apt changelog php8.2-fpm 2>/dev/null | grep -m3 -E 'CVE-2026-10961(8|9)'No match means the package you have does not mention the fix yet.
Step 2: upgrade, by how PHP got onto the box
Distro or PPA packages (php-fpm or mod_php)
Upgrade only the PHP packages, then restart the service that holds the interpreter. On Debian or Ubuntu with an FPM pool for 8.3:
sudo apt-get update
sudo apt-get install --only-upgrade 'php8.3*'
sudo systemctl restart php8.3-fpmFor mod_php the interpreter lives inside Apache, so restart Apache rather than reload it:
sudo systemctl restart apache2Whether your distribution has published a fixed package yet is up to its security team. If apt offers nothing new, check the distro's security tracker for the two CVE IDs before assuming you are covered.
Official Docker images
Floating tags like php:8.3-fpm only move when you pull, and a cached base layer can quietly keep the old build. Pin the fixed patch release and rebuild without the cache:
FROM php:8.3.36-fpmdocker build --pull --no-cache -t myapp:php-8.3.36 .
docker run --rm myapp:php-8.3.36 php -r 'echo PHP_VERSION, "\n";'Then redeploy and re-run the Step 1 check against the live site, not the image.
FrankenPHP
FrankenPHP embeds libphp, so the PHP fix arrives only with a FrankenPHP build that links a fixed PHP. Upgrading a system PHP package next to it changes nothing. Print what the binary carries:
frankenphp versionIf the PHP version it reports is below the fixed release for its branch, update the FrankenPHP binary or image and restart it. The Step 1 file works here too and reports frankenphp as the SAPI.
