What was fixed

The PHP project released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. These releases fix two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, that can allow unauthenticated remote code execution: an attacker who can reach an affected application may be able to run their own code on the server without logging in.

These emergency releases do not address the newly disclosed CVE-2026-115560. All PHP users should still apply the emergency updates immediately. Our first post on these releases explains how to update. For the technical details of each flaw, rely on the official sources: the PHP 8 changelog and the CVE records for CVE-2026-109618 and CVE-2026-109619.

New: CVE-2026-115560 (23 October 2026)

PHP disclosed CVE-2026-115560, a separate potential remote code execution path involving session serialization and session upload progress. No fixed PHP release for this CVE was available as of 23 October 2026. PHP plans to publish a full advisory and fix with its next regular release, rather than an out-of-band update.

The issue requires all of the following unusual conditions:

  • session.serialize_handler is configured as php_binary or php_serialize;
  • application code changes the handler to php using ini_set() before calling session_start();
  • session.upload_progress.enabled remains enabled.

Applications that never switch the session serialization handler at runtime are not exposed through this specific attack path. However, if you cannot confidently rule out the conditions, apply the mitigation below. See the PHP security team's notice and Canadian Cyber Centre update.

Which version you need

  • PHP 8.5: update to 8.5.12 or later.
  • PHP 8.4: update to 8.4.27 or later.
  • PHP 8.3: update to 8.3.36 or later.
  • PHP 8.2: update to 8.2.35 or later.

Important: These version numbers address CVE-2026-109618 and CVE-2026-109619 only. They are not fixed versions for CVE-2026-115560.

Older branches, such as PHP 8.1 and earlier, no longer receive security fixes from the PHP project. If you still run one, treat the move to a supported branch as urgent, not as a later project.

Find every PHP you run

The hardest part is often not the update, it is the inventory. PHP hides in more places than the main web server:

  • web servers running PHP-FPM or an Apache module;
  • Docker images, including the ones you only build in CI;
  • scheduled jobs and workers that run the PHP command line;
  • shared or managed hosting, where the provider updates PHP for you.

On a server, check the command line and the PHP the web server actually uses, which can differ:

php -v
php-fpm8.4 -v          # the FPM binary name follows your version
php -r 'echo PHP_VERSION, PHP_EOL;'

How to update

Debian and Ubuntu. Install the security updates from your package source, then restart PHP and the web server:

sudo apt update
sudo apt upgrade
sudo systemctl restart php8.4-fpm   # or apache2, nginx and your PHP-FPM version

Red Hat, Rocky, Alma and Fedora. The same idea with dnf:

sudo dnf upgrade 'php*'
sudo systemctl restart php-fpm httpd

Docker. Rebuild every image on the latest base image and redeploy it everywhere, not just in production. --pull makes the build fetch the new base image instead of reusing a cached one:

docker build --pull -t my-app .

LineXa Studio. PHP backends are built from the official php:<version>-apache image. Deploy them again so the image is rebuilt, then check the version your service reports.

Managed hosting. Check your provider's status page or ask support which PHP release you are on, and when the fix is applied.

Mitigate CVE-2026-115560 now

Until PHP publishes a fixed release, disable session upload progress in the effective PHP configuration for the affected runtime. This is a temporary mitigation, not a substitute for patching the original two vulnerabilities.

; php.ini or the relevant PHP-FPM pool configuration
session.upload_progress.enabled = 0

Restart all PHP workers (not merely a configuration reload), then verify the setting in the web-serving SAPI. CLI and PHP-FPM can load different configuration files.

php -i | grep 'session.upload_progress.enabled'
# Check the web-serving PHP-FPM pool configuration too.
# Restart the correct service, e.g.:
sudo systemctl restart php8.4-fpm

For Docker images based on official PHP images, bake the setting into the image and redeploy every replica:

RUN printf '%s\n' 'session.upload_progress.enabled=0' \
    > /usr/local/etc/php/conf.d/99-session-security.ini

Check whether any application feature relies on session-based upload progress; disabling it may affect upload progress indicators but does not disable ordinary file uploads. If you already applied this mitigation for CVE-2026-109619, keep it in place.

Check the result

After the update, confirm it really took effect: a PHP-FPM pool that was not restarted keeps running the old code.

  • Run php -v again, and check the FPM binary too.
  • Confirm session.upload_progress.enabled=0 in the effective web runtime where mitigation is required, and review any runtime changes to session.serialize_handler.
  • Restart PHP-FPM and the web server, then test the application.
  • On Debian, Ubuntu and Red Hat style systems, distributions often backport security fixes without changing the PHP version number. In that case php -v may still show an older version: check your distribution's security advisory for these two CVEs and the package version that fixes them.

In short

Three PHP CVEs now need attention. Patch CVE-2026-109618 and CVE-2026-109619 using the October emergency releases, then mitigate CVE-2026-115560 by disabling session upload progress until the next fixed release if the vulnerable application pattern cannot be ruled out. Verify every runtime and monitor PHP advisories. If you need a hand checking your platform, schedule a Cloud Security Review and PHP Hardening Audit and we will check it with you.