php2shell Needs the PHP Patch, Not Just session.upload_progress=0

TL;DR

---

php2shell is the nickname for two critical PHP vulnerabilities that can allow remote code execution (RCE).
In the previous post I covered turning off session.upload_progress.enabled as a stopgap until PHP’s official fix.
Since then, GMO Flatt Security, the firm that first suggested that setting, has revised its view and now expects the attack to remain possible with the setting alone.
A PHP core developer has also posted that updating PHP is the only mitigation.
Sites that turned the setting off still need to update.

The official fix and the two vulnerabilities

PHP released 8.5.12, 8.4.27, 8.3.36, and 8.2.35 at 14:00 UTC (23:00 JST) on October 21 (official security advisory).
The CVE IDs are CVE-2026-109618 and CVE-2026-109619, and both can allow unauthenticated remote code execution.
Every PHP installation that serves web requests is affected, and the advisory lists PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed.
PHP rates mod_php as the highest risk, and says a demonstrated exploit lets a single unauthenticated request start the attack before any application code runs.

CVE	Official name	What it is
CVE-2026-109618 (GHSA-w8hw-w9fx-j79w)	RCE via OOM corruption	Out-of-memory handling can interrupt PHP while internal request data is only partly initialized. Request cleanup may then treat that half-built data as valid
CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp)	RCE via stale global state	Per-request internal state can outlive the memory behind it. The next request handled by the same worker may use that stale state before initialization resets it

The session.upload_progress.enabled setting the previous post suggested turning off appears in the advisory as one of the mitigations for CVE-2026-109619.
CVE-2026-109618 is a separate path that this setting does not block.

Source patches for PHP 8.1 and older

Official fixed releases cover 8.2 through 8.5, and the PHP project does not update 8.1 or older.
Because these bugs are so severe, though, the PHP security team published minimal source patches for 7.4, 8.0, and 8.1.
They are meant for people who build from source or have no LTS vendor.
These are not numbered releases, and there are no tarballs or Windows binaries.
The patches live in php/php-src on GitHub as one branch per series, each with a single fix commit on top of that series’ last commit.
If you only want the fix, you can download that commit as a .patch file.

Series	Branch	Fix only
7.4	PHP-7.4-CVE-2026-109618-109619	712e60f9.patch
8.0	PHP-8.0-CVE-2026-109618-109619	82f8f31b.patch
8.1	PHP-8.1-CVE-2026-109618-109619	1d7dec17.patch

The commit message reads “Minimal mitigation for EOL version.”, and the advisory calls them “minimal source-backports.”
Nothing was published for 7.3 or older, and PHP installed through shared hosting or packages will not pick these patches up on its own.
On 8.1 or older, the options are a backport (only the fix, carried into an older version) from your distribution or LTS vendor, or moving to a branch that has a fixed release.
Ubuntu’s USN-8948-1 also ships a fixed package for the 8.1 in Ubuntu 22.04 (Ubuntu Security Notice).

If you use Remi’s repository

The advisory says the volunteer-maintained Remi repository (rpms.remirepo.net) will not have updates on October 21.
It urges people who rely on it to switch to distribution packages or build from source so they can update right away.
As of 23:20 JST, Remi’s blog had no post about the fixed versions.

PHP’s mitigations if you cannot update yet

PHP says only an update is a complete fix, then lists settings that block specific attack paths for those who cannot update right away. It also states that none of them make an installation safe.

Target	Setting	PHP’s caveat
CVE-2026-109618	Set memory_limit=-1 in a way applications cannot override, such as php_admin_value in the FPM pool (the per-pool PHP-FPM worker config) or Apache config	Removes the PHP memory-limit failure, but an underlying allocation failure can still reach the vulnerable code
CVE-2026-109618	Lower post_max_size: 8M if you do not need uploads, 32M if you do. Keep upload_max_filesize below it	None
CVE-2026-109618	Limit request size, input field count, multipart part count, header count, and nesting depth at the web server or proxy	The limits must also apply to requests without a usable Content-Length
CVE-2026-109619	Set session.upload_progress.enabled=0 and restart every worker	Put it in php.ini, the FPM pool, or server config. Do not rely on ini_set() or FPM .user.ini. Blocks only the confirmed session paths
CVE-2026-109619	On PHP 8.5, set fatal_error_backtraces=0 and restart every worker	Blocks only the confirmed fatal backtrace path

With memory_limit=-1 PHP has no memory cap of its own, so PHP recommends a container or cgroup memory limit as a separate boundary, ideally one that kills only the affected worker.
It also lists removing invalid or deprecated per-request settings that emit diagnostics, and fixing fatal errors and timeouts an attacker can trigger.

The previous post showed how to turn the setting off with .user.ini where php.ini cannot be changed, but PHP says not to rely on FPM .user.ini, so servers that used that method still need the update.

Why turning off session.upload_progress does not stop php2shell

The first version of GMO Flatt Security’s write-up, published around 11:00 JST on October 21, said disabling session.upload_progress.enabled had a certain chance of helping.
At 11:13 JST the same day, PHP core developer Gina Peter Banyard replied to a post suggesting the setting might stop the bug (Mastodon post):

The only thing I can say is that the only mitigation is patching / upgrading PHP. I sadly know too much.

Banyard posted this personally. PHP’s official announcement does not list a configuration workaround either.

In an update at 14:00 JST, Flatt Security rewrote that section to say disabling the setting only mitigates the issue and is not expected to prevent the attack. The updated text says it “may help, but the attack is still possible.”
The same update asks readers to apply the patch as soon as it is released, and says code claiming to exploit the bug has started circulating online.

Some projects turned the setting off and took their service down anyway.
GrapheneOS, which develops an Android-based OS, says it applied three measures, session.upload_progress.enabled = Off, blocking requests with multipart/form-data, and Zend memory manager debug settings, and still decided to take its forum offline (GrapheneOS post).

As the previous post explained, turning the setting off only removes the upload progress display, so it is fine to leave it off until you apply the fix.

Where the fix is published

Where you get the fix depends on how PHP was installed on your server.

How PHP was installed	Where the fix comes from	Who applies it
Shared hosting, managed hosting	Your hosting provider	The provider. Check their notice and phpinfo()
Built from php.net source	php.net downloads, php/php-src on GitHub	You
Windows builds	php.net Windows downloads	You
Ubuntu, Debian distribution packages	The distribution’s security updates	You (apt)
RHEL, AlmaLinux, Rocky Linux	The distribution’s errata (fix advisories)	You (dnf)
Ondřej Surý’s PPA, Remi’s repository	Each repository	You
Official Docker php images	Docker Hub	You (rebuild and redeploy)

Distribution packages such as Ubuntu’s and Debian’s usually backport only the fix, so the PHP version number often stays the same (Patchmon’s write-up).
php -v alone will not tell you whether a package is fixed, so check the package changelog for CVE-2026-109618 and CVE-2026-109619.

According to PHP’s supported versions page, 8.2 through 8.5 are supported, and 8.2 receives security fixes only until December 31, 2026.
Huntress cites the view that fixes will ship only for supported 8.x branches, and says environments on PHP 5, 7, 8.0, or 8.1 will need to upgrade or isolate.

The fixed versions are 8.5.12, 8.4.27, 8.3.36, and 8.2.35; the earlier 8.5.11, 8.4.26, 8.3.35, and 8.2.34 do not contain this fix (php.net ChangeLog).

How to apply the PHP fix in each environment

Shared hosting

On shared hosting the provider manages the PHP binary, and you cannot install the fix yourself.
Wait for your provider’s notice, then check that “PHP Version” in phpinfo() shows the fixed release.
If your control panel lets you choose a PHP version and you are on 8.1 or older, there is no official PHP fix for it, so move to a branch that gets the fix.
Before switching, check that your CMS and plugins run on that branch.

Ubuntu, Debian

sudo apt update
# replace 8.3 with the branch you use
sudo apt install --only-upgrade 'php8.3-*'
apt changelog php8.3-fpm | grep -E 'CVE-2026-10961(8|9)'

If the apt changelog output shows CVE-2026-109618 and CVE-2026-109619, the package includes the fix.
If the fix has not reached your distribution yet, the command prints nothing.
You can follow the status in Ubuntu Security Notices and the Debian Security Tracker.

RHEL, AlmaLinux, Rocky Linux

On RHEL-family systems PHP ships as AppStream modules, which let RHEL offer several versions side by side, so servers on the same OS can run different branches.
Before updating, check which stream is enabled with dnf module list php.

dnf module list php
sudo dnf upgrade 'php*'
rpm -q --changelog php-fpm | grep -E 'CVE-2026-10961(8|9)'

Docker

Running containers do not switch over just because you pulled a new image.
If you build your own image on top of the official one, rebuild that too, then recreate the containers.

docker pull php:8.3-fpm
docker compose build --pull
docker compose up -d

Restart after updating

Updating the package leaves running PHP-FPM or Apache processes on the old PHP.
The “Server API” line in phpinfo() tells you which one you run: FPM/FastCGI or Apache 2.0 Handler.
PHP-FPM, which runs PHP in its own processes, is restarted with sudo systemctl restart php8.3-fpm (php-fpm on RHEL-family systems).
If PHP runs inside Apache as mod_php, restart Apache.
php -v and php -i on the command line show the CLI PHP, so they cannot tell you whether the web server’s PHP has been updated.
After restarting, check the version with phpinfo() opened in a browser.
A phpinfo() file exposes the full server configuration, so delete it once you are done.

Services taken offline as a precaution

Organizations have been taking services offline ahead of the release.
For Japan, piyolog has tallied company announcements and counts 19 organizations that have either already shut down or scheduled emergency maintenance around 23:00 JST.
In the table below, entries whose window starts after 21:30 JST were not yet offline at the time of writing.

Organization	What is offline	Window (JST)
BASE	Web service, PAY ID app, API	Oct 21 15:50 to Oct 22 07:00 (planned)
CoDMON	All services, including the parent app	Phased from Oct 21. Expected back early Oct 22
GMW (pictSQUARE, MXentry)	All features of its online event and entry management services	From Oct 21. Aiming to resume on Oct 22
AlphaPolis	All websites and apps it runs	From an announcement in the 17:00 hour on Oct 21. Back after a safety check
TechBowl	All features of TechTrain and DirecTrain	From Oct 21 17:00. No restart date
JCS	ezblox	Oct 21 19:00 to Oct 22 09:00 (planned)
Cygames	Shadowverse: Worlds Beyond game and official site	From Oct 21 23:00. End not announced
Cygames	Granblue Fantasy	Oct 21 23:00 to Oct 22 07:00 (planned)
root ip	IP management system	Oct 21 22:30 to Oct 22 01:00 (planned)
Xserver	Service website, account management panel, new sign-ups, renewals, payments. Customer servers keep running	From Oct 21 16:00. Expected back late Oct 21 to early Oct 22
Shifter	Some dashboard features. Live sites unaffected	Oct 21 15:00 to Oct 22 10:00
InfiniCLOUD	New storage upgrades, account registration	From Oct 21. Planned to resume mid next week
Topping	New plugin downloads, contact form	From an announcement in the 18:00 hour on Oct 21, until the fix is in place
GrowthArts	Buyback form	From an announcement in the 16:00 hour on Oct 21. Back after the fix is confirmed
HID-Labs	All related websites and new orders	Sites down by Oct 21 23:00
YASUDA	Official site and online store. Shipping continues as usual	Around Oct 21 16:30 to the morning of Oct 22 (planned)
Kimble	Homepage	From an announcement in the 16:00 hour on Oct 21. No restart date
INGAGE	Company website	From an announcement in the 17:00 hour on Oct 21. Back in stages after the 23:00 release
Spell Fragments	Developer website. Gameplay unaffected	From an announcement in the 17:00 hour on Oct 21. Back after the security update
Bunfree (Bungaku Free Market) office	Official site. Web catalog and entries continue	From Oct 21 16:00. Back after the fix is applied

Links for the organizations without one here are in piyolog’s post.
CoDMON, Xserver, and AlphaPolis only cite a software vulnerability and do not name PHP.
Xserver has also taken its service website down, and when I opened it in the 21:00 hour JST it returned 503.
Sakura Internet announced maintenance on part of its shared hosting from 13:00 on Oct 21 to 08:00 on Oct 22, but piyolog says any link to this issue is unclear.

piyolog’s tally also lists organizations that announced a response without shutting down.
Six Apart plans maintenance to update PHP on the cloud edition of Movable Type after the fix is released, and Alfasado is asking PowerCMS users to consider temporarily taking affected sites offline.
Kagoya Japan says it is investigating the impact.

Outside Japan, status pages and posts also announced shutdowns.

Organization	What is offline
BambooHR (HR software)	Web app and website
addy.io (email forwarding)	Web system. Email delivery continues
GrapheneOS (Android-based OS)	Forum (described as its only PHP software)

Status per distribution channel

Distribution packages and official Docker images come separately from each provider, so check each channel on its own.
The table reflects the status as of 23:20 JST (14:20 UTC) on October 21.

Channel	Status
php.net	Source and Windows builds of 8.5.12, 8.4.27, 8.3.36, 8.2.35 are out
Ubuntu	Released in USN-8948-1. 22.04: 8.1.2-1ubuntu2.28, 24.04: 8.3.6-0ubuntu0.24.04.13, 26.04: 8.5.4-0ubuntu1.5
Debian	Not yet in the Security Tracker
Ondřej Surý’s PPA	8.3 still at September’s 8.3.35
Remi	No update on October 21 (per PHP’s advisory)
Official Docker php images	No 8.5.12 or other fixed tags yet
RHEL	Not yet in Red Hat’s CVE database

Ubuntu’s version numbers carry only the backported fix and do not match php.net’s numbers.
On Ubuntu or RHEL-family systems, use the commands in Ubuntu, Debian and RHEL, AlmaLinux, Rocky Linux to check that the changelog lists the CVE IDs.