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

The fix is out: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP released them on 21 October at about 13:35 UTC (PHP’s advisory ). Ubuntu, Debian, Red Hat, Amazon Linux, Alpine and the big third-party repositories have fixed packages. Package status shows where you can get it.

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. After that, you can undo most of the early mitigation steps . 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.

Updates#

Package status#

Which sources have the fixed PHP. Every cell comes from the repository’s own package index, the same file apt, brew or pacman reads.

Last checked at 09:30 UTC on 24 October.

• ✔Fixed
• 8.4.26Vulnerable, shows the version it has
• —Branch not shipped
• ?Could not check

PHP’s own versions#

These sources ship PHP’s own version numbers. The fixed version for each branch is in the column header.

Distribution packages#

Ubuntu and Debian put the fix into the PHP version they already ship. So their version numbers differ from PHP’s. These are the package versions with the fix.

PHP 8.1 and older#

PHP no longer releases these branches. Some repositories patched them with PHP’s minimal patch. It turns off upload progress completely and adds no hard memory limit. A ✔ here means patched, not supported: plan the move to 8.2 or newer.

PHP built into other software#

Some software ships its own copy of PHP. apt, dnf or brew does not update that copy. You need a new release of the software itself. Each tile shows the PHP version in its newest release.

Notes#

Docker: the official php:8.x.y images contain the fix for every branch, on amd64 and arm64. Pull the new tag, rebuild your own images with docker build --pull, and recreate the containers. Chainguard ’s PHP images have had the fix since 07:41 UTC, according to the PHP Foundation . The update was merged in docker-library/php#1694 . The 8.5.12RC1 and 8.4.27RC1 images do not contain the fix. Debian 13’s fix is DSA-6574-1 . Debian 12’s fix is DLA-4848-1 .

packages.sury.org on arm64 is still building, three days after the release. Ondřej builds the arm64 packages in an emulator (qemu) on amd64 hardware, which is slow. One arm64 build takes about five hours. His build tool cannot spread builds over several machines, so he cannot simply add native arm64 builders. He says money is not the problem. He has ordered two Raspberry Pi 5 builders for the next release.

From 23 October, a temporary repository at packages.sury.org/freexian/ had Freexian’s arm64 builds of the same sources. Ondřej removed it on 24 October at 04:18 UTC, because the arm64 packages were “almost done”. If you used it, the cells above that are not ✔ are the packages it no longer gives you.

Until then on arm64:

• Ubuntu 22.04 and 24.04: the Launchpad PPA (ppa:ondrej/php) has every branch.
• Ubuntu 26.04 and Debian: use your distribution’s own PHP (see distribution packages ), the official Docker images, or wait.

Amazon Linux has the fix since 22 October: php8.2 to php8.5 on Amazon Linux 2023, and the php8.2 extra on Amazon Linux 2. php8.1 on Amazon Linux 2023 and the core php on Amazon Linux 2 get no fix (CVE-2026-109618 , CVE-2026-109619 ). AWS’s bulletin covers its other services:

• Elastic Beanstalk: new PHP platform versions for 8.2 to 8.5 have PHP’s fix. With managed platform updates on, they arrive in your next maintenance window. Otherwise, update the platform version yourself.
• Lightsail: new blueprints are out in all regions. Running instances are not updated, so create new instances from the new blueprints.
• WorkMail: runs PHP 8.3.36. No action needed.

I checked the fix in these changelogs:

• packages.sury.org and the ppa:ondrej/php PPA have the fix for every end-of-life branch, PHP 5.6 to 8.1. The new packages (php5.6 -104, php7.0 -92, php7.1 -80, php7.2 -66, php7.3 -35, php7.4 -31, php8.0 -25, php8.1 -9) were built on 21 October. Each one carries the patch Avoid-state-corruption-via-bailout by PHP core developer Arnaud Le Blanc, as Ondřej said . It is the same minimal patch PHP published for 7.4, 8.0 and 8.1: it turns off upload progress completely, and it adds no hard memory limit. On 22 October, Ondřej rebuilt 5.6, 7.0 and 7.1 (-105, -93, -81) with an older multipart fix (CVE-2023-0662) on top. A normal apt upgrade installs them. The 21 October builds already fix the two new CVEs.
• Ubuntu 8.3.6-0ubuntu0.24.04.13 says “SECURITY UPDATE: Remote RCE via state corruption issue”, with the patch CVE-2026-109618_109619.patch (Launchpad ).

Laravel Octane with FrankenPHP has its own binary. When Octane downloads FrankenPHP, it saves it in your project folder as frankenphp. Octane accepts any version from 1.13.0 up (source ). So an unfixed 1.13.0 or 1.13.1 still passes. Delete that file and start Octane again. If it finds no other FrankenPHP, it offers to download the newest one.

Swoole and RoadRunner use your installed PHP. Swoole is a PHP extension. RoadRunner starts your php binary for its workers. So upgrading PHP fixes them; restart them afterwards. swoole-cli is different: it ships its own PHP, so it is in the table above.

GitHub Actions with setup-php: a PHP version that is already on the runner is not updated to the newest patch release by default (README ). Add update: true to the step.

The release tags are genuine. On GitHub, the php-8.x.y tags point at commits that are not on any branch, which worried some people . The tags are signed by PHP’s release managers, and GitHub marks the signatures as verified.

The short version#

1. Find out where your PHP comes from: your distribution, a third-party repository, Docker or FrankenPHP.
2. 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#

Every version before the fixed ones is affected (GHSA-w8hw-w9fx-j79w , GHSA-6wmf-4rv5-p3rp ). The PHP project only releases fixes for the versions it still supports (supported versions ):

Distributions can still patch older versions themselves. Ubuntu fixed every release it supports, including PHP 8.1 on 22.04, and with Ubuntu Pro also 14.04 to 20.04 (USN-8948-1 , USN-8948-2 ). Red Hat fixed RHEL 8, 9 and 10, except the php:8.4 stream on RHEL 9. 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

For PHP 7.4, 8.0 and 8.1, the PHP security team published small source patches. They are for people who build PHP themselves, or who have no vendor that backports fixes (PHP’s advisory ). PHP calls them a “minimal mitigation for EOL version” (7.4 , 8.0 , 8.1 ). They are much smaller than the fix for the supported versions, and they switch session upload progress off completely, whatever your php.ini says. php -i and ini_get() can still show session.upload_progress.enabled as on, so a scanner that reads that setting flags a patched server by mistake. Ondřej’s PHP 7.4 package on packages.sury.org carries this same patch. If your app shows upload progress bars on these versions, they stop working. Zend says its commercial LTS builds of PHP 7.2, 7.3, 7.4 and 8.1 had the fix at release time (Matthew Weier O’Phinney, Zend ).

What the bugs are#

PHP published the details with the release. In short:

• CVE-2026-109618, “RCE via OOM corruption” (GHSA-w8hw-w9fx-j79w ). When PHP runs out of memory, it can stop in the middle of setting up a request. The cleanup that runs afterwards then trusts data that was never fully set up. The confirmed ways to run out of memory are in multipart request parsing.
• CVE-2026-109619, “RCE via stale global state” (GHSA-6wmf-4rv5-p3rp ). Some state from one request can survive after its memory is freed. A later request on the same PHP worker can then use it. The confirmed cases are the session upload-progress feature, and on PHP 8.5 the fatal_error_backtraces setting.

Who is at risk, according to PHP: every PHP that serves web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP considers the risk highest for mod_php. There, a single anonymous request can trigger the attack before any of your code runs. For PHP-FPM, PHP confirmed remote code execution through the upload-progress path, when the application does something that triggers a fatal error at the right moment. For the out-of-memory bug it has not shown a complete FPM exploit, but its own code review says FPM is affected.

The researchers who found the bugs, from Wiz, OpenAI and Calif, published php2shell.com and a technical write-up . They add two things:

• The bugs can also leak memory, without running any code. An attacker can read parts of the PHP worker’s memory, which can hold passwords, tokens, API keys and certificates from other requests. They showed this works against any PHP application.
• They reported the bugs to PHP on 24 August 2026. They showed remote code execution against WordPress, Drupal and Joomla, but say even a “Hello World” script on an affected PHP is vulnerable.

One detail differs between the sources. The table in Wiz’s blog lists the upload-progress bug under CVE-2026-109618. PHP’s advisory and php2shell.com list it under CVE-2026-109619. This post follows PHP. Both CVEs are fixed by the same update, so it does not change what you have to do.

The fix is one commit, 31c0ea7d7f (“Avoid state corruption via bailout”). PHP no longer jumps out of a request when memory runs out. It stops the request at a safe point instead, and it resets the leftover state before the next request starts.

After the upgrade: PHP now has a hard memory limit#

The fix adds a second, higher memory limit. When a process reaches it, PHP stops the process straight away, and shutdown functions do not run (php2shell.com , GHSA-w8hw-w9fx-j79w ). If you set memory_limit = -1 as a mitigation, set it back to a real limit after you patch.

The new setting is memory_hard_limit_percent. By default, the hard limit is twice your memory_limit when that is 1G or less, so 256M with the usual 128M. Above 1G, it is memory_limit plus 1G. A process that reaches it exits with code 137, so look for that in your PHP-FPM log after the upgrade. I checked these values in the PHP 8.5.12 source (Zend/zend_alloc.c). What PHP-FPM logs when a worker hits the hard limit, and what else changes for production, is in PHP’s new memory_hard_limit_percent setting .

PHP core developer Alexandre Daubois adds that a patched PHP still stops a worker that runs out of memory, only without the memory corruption. If your app accepts uploads, he suggests limiting the number of multipart parts and headers per part at the web server.

Is the fix incomplete?#

Not as far as anyone has shown. On 21 October some posts on X and Hacker News said 8.5.12 is “still vulnerable”. They all go back to one researcher, elise , who found a memory bug that still works on 8.5.12. She says it is a “different vuln, been around for a while”, so not a hole in this fix. PHP says its security team is aware of her report. PHP has not said how serious it is.

On 22 October she added that it does not need a malicious script. Malicious user input during a normal operation on a normal server can trigger it. She says turning it into remote code execution is possible in the right circumstances, but “really non-trivial”. Security researcher Hanno Böck had first called it local-only, and now agrees it can be triggered remotely. There is no fix for it yet, and no CVE. Install the 21 October releases anyway: they fix the two bugs that are already being exploited.

As of 23 October, 08:30 UTC, there is no new advisory, no new PHP release, and no published bypass. One researcher who first wrote that 8.5.12 “may still be vulnerable” took that back .

Known problems after the upgrade#

These bugs are new in the 21 October releases. None has a fixed release yet:

• Crash with zend_mm_heap corrupted on 8.4.27 and 8.5.12. It happens when the garbage collector cleans up SimpleXML objects. It comes from a normal bugfix in this release, not from the security fix. 8.3.36 and 8.2.35 contain only the security fix, so they do not have it. PHP fixed it in its source code on 22 October, so the next 8.4 and 8.5 releases will include the fix (#24488 ).
• Some out-of-memory errors now stop the worker with exit code 137. sprintf(), pack(), bin2hex() and ext/xml built with Expat can go past the new hard memory limit. 8.5.11 gave a normal “Allowed memory size exhausted” error for the same code (#24492 ). It was reported on 8.5.12 and 8.4.27, but the hard limit is in all four releases.
• Upload progress can wipe a session. This happens when a stored object has a property named __PHP_Incomplete_Class_Name or similar. Users get logged out (#24493 ). Rare.

None of these is a reason to stay on the old version. The old version can be broken into; these only crash or log out.

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.
• A third-party stopgap is hp_uploadprogress_guard . It is an open-source PHP extension that copies the official fix into an unpatched PHP 5.4 to 8.5, without rebuilding PHP. PHP did not write or review it, and I have not tested it.
• 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 has 8.2.35, 8.3.36, 8.4.27 and 8.5.12 for RHEL 8, 9 and 10, on x86_64 and aarch64, in the modular and the SCL-style repositories. It also patched 7.4, 8.0 and 8.1, but not 7.2 and 7.3. Some Remi mirrors lag behind. If dnf does not offer the fix, run sudo dnf clean metadata and try again.

Ondřej’s packages (packages.sury.org and the ppa:ondrej/php PPA) have the fix for every PHP version they ship, from 5.6 up (his tracking issue ). Some arm64 builds on packages.sury.org are still missing; see package status .

CloudLinux has fixed alt-php, ea-php and native PHP packages in stable on CloudLinux 7, 8 and 9 (CloudLinux ).

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 fixed every stream except php:8.4 on RHEL 9. That stream is listed as affected, with no fix yet (Red Hat ). Remi’s repository has a fixed 8.4 for RHEL 9.
• 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.