Update, 23 October 2026: a third PHP remote code execution vulnerability, CVE-2026-115560, is not fixed by these releases and needs a configuration mitigation until the next PHP release. Read what to do.

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.

All PHP users are strongly encouraged to update immediately. 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.

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.

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.

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.
  • 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

Two critical, remotely exploitable flaws without authentication are the kind of issue attackers scan for quickly. Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 today, cover every server and image, and verify the result. If you need a hand checking your platform, schedule a Cloud Security Review and PHP Hardening Audit and we will check it with you.