PHP CVE-2026-109618 and CVE-2026-109619: how to apply the patches

Status at 10:40 UTC: the fixed PHP is not out yet. PHP releases it on 21 October 2026 at 14:00 UTC. Ubuntu, Debian, Red Hat and the third-party repositories follow after that. This post updates as the packages arrive.

This post shows how to install the fix on Ubuntu, Debian and Red Hat, what to restart, and how to check that the fix is running. Do these steps once the fixed packages are out. Until then:

• Find out where your PHP comes from, and which steps below apply to you.
• Keep the early mitigation steps in place.

After the patch runs, you can undo most of those mitigations. See roll back the early mitigations .

Like the early mitigation post, most of this post was written with Claude and Codex. Every command was tested in containers, against the current packages. Point your LLM at this page now. Let it map out your servers, and run the steps once the fixed packages are out.

Updates#

• 21 October, 11:30 UTC. CloudLinux is preparing fixed alt-php packages. See which PHP your distribution ships .
• 21 October, 11:11 UTC. Nils Adermann confirmed Ondřej’s PPA will get the fix (no time given). See which PHP your distribution ships .
• 21 October, 10:40 UTC. Remi’s repository will not ship the fix today. See third-party repositories .
• 21 October, 10:25 UTC. Published before the release, so you can prepare. The fixed version numbers get added here after 14:00 UTC.

The short version#

1. Find out where your PHP comes from: your distribution, a third-party repository, Docker or FrankenPHP.
2. Once it is out, install the fixed PHP from that same source.
3. Restart every process that runs PHP.
4. Check that no process still runs the old PHP.
5. Roll back the early mitigations you no longer need.

Which PHP versions get a fix#

The PHP project only fixes the versions it still supports (supported versions ):

Distributions can still patch older versions themselves. Ubuntu, Debian and Red Hat each do this for some releases. None of them had published anything about these CVEs at 09:40 UTC. Check their trackers for the current status:

• Ubuntu: CVE-2026-109618 , CVE-2026-109619
• Debian: CVE-2026-109618 , CVE-2026-109619
• Red Hat: CVE-2026-109618 , CVE-2026-109619

Running PHP 8.1 or older? Plan the move to 8.4 or 8.5#

A backported fix from your distribution fixes this bug. It does not protect an old PHP version against the next bug. PHP itself no longer reviews or fixes that branch. Install the fix that is available today. Then move to PHP 8.4 or 8.5. PHP 8.2 loses security support on 31 December 2026. Skip it.

On Ubuntu, the easiest way is often a release upgrade. 24.04 ships PHP 8.3 and 26.04 ships PHP 8.5. See how to upgrade Ubuntu LTS .

If your distribution will not patch your PHP version:

• Keep the early mitigations in place.
• Move to a supported PHP version as fast as you can.
• Until then, taking the site offline is the only safe option.

Which PHP your distribution ships#

Checked in containers on 21 October 2026.

Watch out for these:

• On RHEL 8, a plain dnf install php installs PHP 7.2. That module stream is still the default. It has been retired since 2021. It gets no fixes. The same goes for the 7.3 and 8.0 streams on RHEL 8 and the 8.1 stream on RHEL 9 (lifecycle ).
• Ubuntu and Red Hat often backport fixes into the old version number. Ubuntu 24.04 still calls its PHP 8.3.6. The package version changes, the PHP version does not. So check the package version, not php -v.
• Debian ships the new upstream release instead. On bookworm, expect a new 8.2.x and on trixie a new 8.4.x.

Many servers that run a recent PHP use a third-party repository. These ship the upstream release:

• Ubuntu 22.04 and 24.04: Ondřej Surý’s ppa:ondrej/php .
• Ubuntu 26.04, Debian 11, 12 and 13: Ondřej’s packages.sury.org . The PPA is moving there.
• RHEL, AlmaLinux and Rocky 8, 9 and 10: Remi’s repository .

Remi’s repository will not ship the fix on 21 October. The PHP Foundation says to move to your distribution’s PHP packages, or build PHP from source. Composer co-creator Nils Adermann said Ondřej’s packages (packages.sury.org, the ppa:ondrej/php PPA) will have the update, but gave no time. Ondřej himself has not posted an ETA (tracking issue ).

CloudLinux is preparing fixed alt-php packages. It will post the timeline after the upstream release (CloudLinux ).

Remi still patches PHP 7.4, 8.0 and 8.1, but makes no promise about it (Remi’s blog ).

Ubuntu and Debian#

The steps are the same for Ubuntu’s own packages, Debian’s own packages, the ondrej PPA and packages.sury.org. Replace 8.3 with your PHP version.

See which PHP packages you have, and their versions:

$ dpkg -l 'php*' | awk '/^ii/{print $2, $3}'
php-common 2:93ubuntu2
php8.3-cli 8.3.6-0ubuntu0.24.04.12
php8.3-common 8.3.6-0ubuntu0.24.04.12
php8.3-fpm 8.3.6-0ubuntu0.24.04.12
php8.3-opcache 8.3.6-0ubuntu0.24.04.12
php8.3-readline 8.3.6-0ubuntu0.24.04.12

Fetch the package lists and see which PHP updates are waiting:

$ sudo apt-get update
$ apt list --upgradable 2>/dev/null | grep php

Upgrade only the PHP packages. This never installs a package you did not have. Keep the quotes, so your shell does not expand the *:

$ sudo apt-get install --only-upgrade 'php8.3*' libapache2-mod-php8.3

libapache2-mod-php8.3 is for Apache with mod_php. If it is not installed, apt skips it. Run this once for every PHP version on the server.

Check that the fix is installed. On Ubuntu, the package changelog lists the CVE:

$ zgrep -E 'CVE-2026-10961[89]' /usr/share/doc/php8.3-fpm/changelog.Debian.gz

On Debian, the PPA and packages.sury.org, the changelog may only say “New upstream version”. Compare the version from dpkg -l with the fixed version in the table above .

Notes:

• Use zgrep on the local file, not apt changelog. On Ubuntu, apt changelog php8.3-fpm returned a 404 for packages in universe. php8.3-fpm is in universe.
• Ubuntu 18.04 and 20.04 need Ubuntu Pro with ESM Infra turned on. sudo pro fix CVE-2026-109618 shows whether a fix is available for your system. On an end-of-life release such as 25.10, pro fix wrongly reports “does not affect your system”.
• Some mirrors of the ondrej PPA lag behind. If apt-cache policy php8.3-fpm does not show the new version, point your sources at ppa.launchpadcontent.net.
• The php8.3-fpm package restarts PHP-FPM itself after the upgrade. Restart it anyway, see what to restart .

Red Hat, AlmaLinux and Rocky Linux#

The steps are the same for Red Hat’s own packages and for Remi’s modular repository.

See which PHP packages you have, and which module stream is active (RHEL 8 and 9 only, RHEL 10 has no modules):

$ rpm -qa 'php*' | sort
$ dnf module list --enabled php
php  8.2 [e] common [d], devel, minimal PHP scripting language

Upgrade only the PHP packages:

$ sudo dnf upgrade 'php*'

Check that the fix is installed:

$ dnf updateinfo list --security | grep php
$ rpm -q --changelog php-fpm | head -5

Notes:

• The changelog is not always useful. On the 8.2 and 8.3 streams it only says “rebase to 8.2.33”, without CVE numbers. Then compare the version with the table above . On the 8.0 default stream of RHEL 9, rpm -q --changelog php-fpm | grep CVE does list the CVE numbers.
• Red Hat was about four weeks behind PHP on the last regular release. On 21 October, RHEL 9 still had 8.2.33 and 8.3.33. PHP had released 8.2.34 and 8.3.35 on 24 September. A critical fix may be faster. Remi’s repository does not help here. It will not have the fix on 21 October (PHP Foundation ).
• Remi’s SCL-style packages have their own names, such as php84-php-fpm. Upgrade them with sudo dnf upgrade 'php84-*' and restart php84-php-fpm.
• dnf updateinfo needs security metadata. AlmaLinux and RHEL have it. I could not test it on Rocky.

To move to a newer module stream on RHEL 8 or 9, for example from 7.4 to 8.2, reset the module first. Without the reset, dnf refuses to switch streams:

$ sudo dnf module reset -y php
$ sudo dnf module enable -y php:8.2
$ sudo dnf distro-sync -y

What to restart#

A running process keeps the old PHP in memory until it restarts.

I tested the PHP-FPM and Apache rows. I replaced the PHP files on disk, then checked what each process ran. After an FPM reload, the master and every worker ran the new binary. After apachectl graceful and after apachectl -k restart, Apache still ran the old libphp8.3.so. Only a full stop and start loaded the new one.

Check the version FrankenPHP runs:

$ frankenphp version
FrankenPHP v1.13.1 PHP 8.4.26 Caddy v2.11.7

Check that nothing runs the old PHP#

The upgrade replaces the PHP files on disk. A process that still runs the old PHP shows the old file as (deleted). This command lists every such process. Empty output means everything runs the new PHP:

$ sudo grep -lE ' /(usr|lib|opt).*\(deleted\)$' /proc/[0-9]*/maps

The pattern only matches files under /usr, /lib and /opt on purpose. OPcache keeps a deleted /dev/zero mapping in every PHP-FPM process. A broader pattern would flag every PHP-FPM process, even before the upgrade.

On Ubuntu and Debian, needrestart does the same check:

$ sudo needrestart -b -r l
NEEDRESTART-SVC: php8.3-fpm

On Ubuntu 24.04 servers, needrestart is installed and restarts these services after every apt run (Ubuntu Discourse ).

Roll back the early mitigations#

Patch first. Check that nothing runs the old PHP. Only then roll back:

Running PHP 8.1 or older without a fix from your distribution? Keep every mitigation in place until you have moved to a supported PHP version.