Karvin Ong

Let’s talk

,

PHP’s October 2026 security release: update, restart, verify

On 21 October 2026 the PHP project released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. All four fix two remote code execution vulnerabilities rated CVSS 9.2. If you run PHP in production, this one is not a “next maintenance window” update.

Key takeaways

  • Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35; they fix CVE-2026-109618 and CVE-2026-109619 (CVSS 9.2).
  • Restart PHP-FPM, Apache and long-running workers, or the old code keeps running.
  • mod_php is the highest-risk configuration.
  • Verify the version the web server actually runs, not just the CLI.
  • PHP 8.2 reaches end of life on 31 December 2026.

What was fixed

  • CVE-2026-109618: RCE via out-of-memory corruption. Out-of-memory handling can interrupt PHP while internal request data is only partly initialised, and request clean-up may then treat that data as valid.
  • CVE-2026-109619: RCE via stale global state. Request-owned internal state can survive after its memory is freed, and a later request handled by the same worker may use it before it is reset.

Both were pre-announced on 20 October. The PHP team is clear that updating is the only complete fix; the temporary mitigations it describes are partial. It also identifies mod_php (PHP embedded in Apache) as the highest-risk configuration, because Apache worker processes are long-lived and shared across requests.

How I approach the update

1. Find every PHP runtime, not just the obvious one

A single site often has several: PHP-FPM for web requests, the CLI for cron and queue consumers, and PHP inside Docker images used for builds or local development. They can be on different versions, so check each one.

# CLI version
php -v

# What the web server actually runs (FPM, mod_php)
php-fpm8.3 -v            # adjust to the installed version
apache2ctl -M | grep php # is mod_php loaded?

2. Update the way the server was built

  • Distribution packages: distributions often backport security fixes without changing the upstream version number, so check the package changelog or security advisory for the two CVE IDs rather than relying on php -v alone.
  • Docker images: rebuild from the updated base image and redeploy. A running container doesn’t change because the tag was updated.
  • Managed hosting and PaaS: confirm with the provider when their PHP builds include the fix. On platforms where the provider controls the runtime, that is the only route.

3. Restart the long-lived processes

Installing a new package doesn’t replace code already loaded in memory. PHP-FPM pools, Apache with mod_php, and long-running workers such as queue consumers keep running the old binary until they are restarted. A patched package with an unrestarted FPM pool is still a vulnerable server.

4. Verify, then record it

Confirm the running version from the web side (a phpinfo page restricted to your IP, or your monitoring agent’s environment data), not just the shell, and note the date and version against each site. When the next advisory lands, that record tells you in minutes which sites are already done.

Plan the next one now: PHP 8.2 ends on 31 December 2026

PHP 8.2 reaches end of life at the end of this year, after which it receives no security fixes at all. For eCommerce platforms the PHP version is tied to the application version, so moving off 8.2 usually means a platform upgrade too. That is a project to schedule now, not in the week a 2027 vulnerability is announced.

Sources

Platform: , ,