PHP's Critical Security Release, and the Countdown to 8.6

Two unauthenticated remote code execution flaws in PHP were patched on 21 October 2026. Here is what changed, who is affected, what to upgrade to, and where PHP 8.6 stands.

October 28, 2026 · PHP · Security · Dev Tools

This is a busy week for PHP. On 21 October the project shipped emergency releases for two critical flaws, and the next major version, PHP 8.6, is in its final test builds. If you run PHP anywhere that serves web requests, the first part of this post is the one to read today.

Everything below comes from the official PHP news archive at php.net, with secondary write-ups cited where they add detail.

Two critical flaws, patched on 21 October

PHP's security team announced the release on 20 October, and the fixed versions shipped on 21 October. Both flaws are rated 9.2 under CVSS v4.0, and both allow remote code execution without logging in.

  • CVE-2026-109618 is an out-of-memory error that leaves request data partly initialised. Cleanup code then processes that invalid state.
  • CVE-2026-109619 is stale global state. PHP keeps references to request data after the memory has been freed, and a later request on the same worker can use them.

The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.2 reaches end of life on 31 December 2026, so it is worth moving to 8.3 or later soon.

Who is at risk? PHP's advisory names every setup that serves web requests: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. The write-up from Qualys, which quotes PHP's own guidance, says mod_php is the most urgent, because the flaw can be triggered before application code runs. Qualys also reports that public proof-of-concept code has appeared, and that PHP has validated remote code execution against PHP-FPM under suitable application conditions. Those exploitation details come from secondary coverage, so treat them as a reason to act rather than a precise threat model.

Older branches are a separate problem. PHP 8.1 and earlier are no longer supported upstream. PHP has published source backports for 7.4, 8.0 and 8.1, and some Linux distributions and hosts ship their own fixes. Check your vendor before assuming you are patched.

What to do today

  1. Upgrade to the fixed version for your branch, or install your vendor's backported build.
  2. Restart every PHP worker after the upgrade. Long-running PHP-FPM pools keep the old code until they restart.
  3. If you cannot upgrade straight away, PHP's guidance is to set session.upload_progress.enabled=0, tighten post_max_size and request limits, and on PHP-FPM consider pm.max_requests=1 if performance allows. These reduce exposure but do not replace the update.

PHP also published a smaller follow-up. On 23 October it warned about an upload-progress session issue, CVE-2026-115560, and advised disabling session.upload_progress until the next bugfix release. On 26 October it rebuilt the Windows binaries with Brotli 1.2.1 to fix CVE-2026-111497. The PHP runtime versions did not change for that one.

Here is how the security releases have landed through 2026, counted from the news archive. The October batch is the critical fix above:

Most of the 2026 security releases list no CVE numbers on the archive page, so the count shows how often PHP ships fixes, not how serious each one was.

PHP 8.6 is nearly done

The security fix above also went into the 8.6 branch. PHP 8.6.0 RC4 arrived on 21 October as an early test build that already includes both RCE fixes. It is not for production. Release candidates are for checking that your code and dependencies still run, so this is the moment to test a staging copy of your application.

The schedule has moved a little. The official timetable had RC4 on 22 October, and the archive now lists RC5 for 5 November. Reports that PHP 8.6 is due on 19 November are consistent across sources, but check php.net for the final date. RC1 was skipped after a packaging mistake, so the first public candidate was RC2.

Test builds came out steadily through the summer and autumn:

A few things are worth doing with 8.6 in mind:

  • Run your test suite against the release candidate, not only against 8.5.
  • Watch for deprecation notices in logs during staging, since these become the next round of breaking changes.
  • Check that your framework, Composer packages and hosting image support 8.6 before you plan the upgrade. Frameworks often take a few weeks after a release to catch up.

What about PHP 9?

Nothing official yet. The RFC index and the internals mailing list are focused on 8.6, including a vote in July on the minimum supported versions for that release. Discussions about pattern matching and larger generic-type proposals are open, but none of the results we found tie them to a PHP 9 scope or date. When PHP 9 has an official plan, it will appear on php.net first.

Where to follow along

If you upgrade today, you are already ahead of most of the internet. If you have not, the next step is the same as it was on 21 October: update, restart the workers, and then test 8.6 in staging.