Disabling session.upload_progress Before the php2shell Patch Lands

TL;DR

---

The PHP security team has announced an emergency security release for October 21, 2026 at 14:00 UTC (23:00 in Japan).
The official notice only says there are two critical vulnerabilities and gives their severity score.
Meanwhile, posts on X and blogs from security vendors are already passing around CVE numbers and code locations under the nickname php2shell, and those reports place at least one of the bugs in the session.upload_progress handler, which PHP enables by default.
That handler can be switched off with the session.upload_progress.enabled setting, so you can turn it off while waiting for the fix.
One researcher, however, claims this only blocks one of the two bugs.
Everything here reflects what was known at 13:00 JST (04:00 UTC) on October 21 and may change once the fixed versions are out.

How to turn off session.upload_progress.enabled

Session Upload Progress writes the progress of a file upload into the session (the mechanism the server uses to remember per-user state) under $_SESSION, so a separate request can read it back and draw a progress bar.

The PHP manual lists the default value of session.upload_progress.enabled as 1 (enabled).
When it is enabled and a POST contains a field named after session.upload_progress.name (default PHP_SESSION_UPLOAD_PROGRESS), PHP records the progress.
That field is added by whoever sends the request, so the handler runs even if your application never implemented a progress bar.

The manual has long recommended disabling this setting in applications that do not use upload progress bars, because the client-supplied file name and field name are written to the session without validation, which makes any local file inclusion bug trivial to exploit.
Turning it off only stops progress tracking, so the only visible effect is on applications that show an upload progress bar, and even there the upload itself still goes through.

The setting cannot be changed with ini_set() in PHP code (the manual lists it as INI_PERDIR), so it has to go into php.ini or a per-directory configuration file.
Where to put it depends on how PHP runs on your server.
mod_php, PHP-FPM, and CGI/FastCGI are the different ways a web server can run PHP, and the “Server API” row in phpinfo() tells you which one you have: Apache 2.0 Handler means mod_php, while FPM/FastCGI or CGI/FastCGI means one of the others.

Environment	Where	What to write	When it applies
Shared hosting (e.g. Sakura, Xserver in Japan)	The php.ini editor in the control panel	session.upload_progress.enabled = 0	Depends on the host
Server you manage yourself	php.ini	session.upload_progress.enabled = 0	Restart PHP-FPM, or Apache for mod_php
No php.ini access, PHP running as an Apache module (mod_php)	.htaccess	php_flag session.upload_progress.enabled off	Only if Apache allows AllowOverride Options or All
No php.ini access, PHP running as CGI/FastCGI (PHP-FPM etc.)	.user.ini	session.upload_progress.enabled = 0	Up to 5 minutes, since user_ini.cache_ttl defaults to 300 seconds

On Sakura Internet’s shared hosting in Japan, open the php.ini settings page (“php.ini設定”) under script settings in the server control panel and add the line, as described in Sakura’s support page.
What you write there applies under /www.
On PHP 8 and later, it is added on top of Sakura’s default settings.
Before PHP 8, Sakura’s defaults are ignored and only what you wrote takes effect, so writing just this one line moves every other directive off Sakura’s defaults.
Dropping a php.ini into a folder to override settings is an old trick, but it is not in the official help, so if you use it, check in phpinfo() that the value actually changed.

On Xserver, another Japanese host, you set it per domain under “php.ini設定” in the server panel (Xserver manual).

.user.ini is read only by the CGI/FastCGI SAPI and ignored under the Apache module (PHP manual).
Conversely, php_flag in .htaccess only works when PHP runs as an Apache module (PHP manual).
In other setups, putting it in .htaccess can take the whole site down with a 500 error, so load a page right after the change and remove the line if you get an error.

To confirm the change, put a file containing only <?php phpinfo(); in your web root, open it in a browser, and check that session.upload_progress.enabled shows 0 (Off).
phpinfo() dumps a lot of server configuration and environment details, so delete that file as soon as you are done.
Running php -i on the command line shows the CLI configuration, which is separate from what the web server uses.

What the setting may not block

GMO Flatt Security’s write-up (in Japanese) lists disabling it as a stopgap until the fix ships, but says it cannot claim the mitigation is 100% effective, only that it should help with some probability.

J4ck3LSyN, the researcher who reported reproducing the bugs on X, writes in their analysis that disabling the setting blocks only one of the two bugs.
They claim the other one is triggered in the multipart parser (the POST format used for file uploads), regardless of this setting.

CERT-EU, which publishes security information for EU institutions, recommends isolating internet-facing applications if you cannot patch right away, and does not mention disabling the setting (CERT-EU advisory).

Measure	Recommended by	Caveat
Update to the fixed version	PHP, CERT-EU, Huntress, and others	Version numbers come with the 14:00 UTC release
session.upload_progress.enabled = 0	Flatt Security, J4ck3LSyN	Claimed to block only one of the two bugs
Take apps off the internet, or put them behind a VPN or a WAF (a filter that stops web attacks before they reach the app)	CERT-EU, Huntress	Also needed for end-of-life PHP versions that will not get a fix

The official PHP notice

The notice was posted on php.net on October 20, 2026.

Item	Official notice
Release	October 21, 2026, 14:00 UTC (23:00 JST)
Count	Two critical vulnerabilities
Severity	Both CVSS v4.0 9.2
CVE IDs	Not listed
Affected and fixed versions	To be published with the release
Earlier release	Possible if details become public or active exploitation appears

CVSS is a common 0–10 scale for vulnerability severity, and 9.0 or higher is the top “Critical” band.
The notice asks all PHP users to prepare so they can upgrade as soon as the release is available, but says nothing about where the bugs are or how they are triggered.

How the leak got ahead of the release

According to Huntress, on the morning of October 20 (US time) someone posted on Hacker News that two critical PHP vulnerabilities were about to be disclosed.
The post was deleted quickly, but screenshots spread on social media, and a few hours later the security firm watchTowr confirmed the vulnerabilities were real and said it had reproduced CVE-2026-109618.
PHP’s release ended up on October 21, one day earlier than originally planned.

As of its post, Huntress had not seen in-the-wild exploitation across the customer environments it monitors.
It also notes that a short video of an exploit was posted once and then taken down.

What outside sources say about php2shell

Outside sources say at least one of the php2shell bugs is a use-after-free (UAF), a bug where a program keeps using memory after freeing it, so an attacker who places their own data in that freed region may hijack execution.
That would allow remote code execution (RCE): running arbitrary code on the server over the network.

Source	Claim	How firm
CERT-EU advisory 2026-018	CVE-2026-109618 and CVE-2026-109619, possible unauthenticated RCE	States it is based on leaked information, not an official disclosure
J4ck3LSyN’s analysis	Heap (memory allocated at runtime) UAF in php_session_rfc1867_callback() in ext/session/session.c. The X post calls it two UAFs, while the analysis places the second bug in the multipart parser	The author’s own testing. They say they will check whether their root-cause analysis was right once the official advisory is out
GMO Flatt Security’s write-up	Memory corruption related to the Session Upload Progress feature in ext/session	Inferred from where the company’s own research overlaps with the php2shell reports. Warns it may contain inaccuracies

Flatt Security’s post also quotes the log from a video a researcher shared.
The log shows a command running as the web server user www-data (uid=33) on Ubuntu 26.04’s PHP 8.5.4 package with Apache prefork/mod_php.
Flatt Security’s own reproduction results are not in the post.
J4ck3LSyN, for their part, says they verified the bugs against PHP 8.4.4 and 8.2.34 source.

The count and CVSS in the leaks match the official notice, multiple organizations cite the same CVE IDs, and Flatt Security and J4ck3LSyN point to the same feature for the vulnerable code.
Still, PHP has not yet said what the two bugs are.

Affected versions so far

CERT-EU, citing a social media post, says all PHP versions from 5 onward may be affected.
Huntress notes reports that fixes will only ship for supported PHP 8 branches and says environments on PHP 5, 7, 8.0, or 8.1 will need to upgrade or isolate.
J4ck3LSyN’s analysis lists 8.5.12, 8.4.27, 8.3.36, and 8.2.35 as targets to update to, but those are the author’s guesses, and the official fixed versions arrive with the 14:00 UTC release.

What to check when the fix ships on October 21 at 14:00 UTC

PHP has not disclosed any of the following yet.

Question	What outside sources say right now
CVE IDs and what the two bugs are	CVE-2026-109618/109619. At least one is said to be a UAF in session.upload_progress
Affected and fixed versions	Unconfirmed claims that everything from PHP 5 on is affected
Which SAPIs are affected (mod_php, PHP-FPM, etc.)	The researcher post quoted by Flatt Security claims reproduction across several setups, including mod_php and php-fpm
Exploitable without authentication?	CERT-EU says unauthenticated RCE is possible
Does session.upload_progress.enabled=0 block it?	Flatt Security expects some benefit; J4ck3LSyN says it blocks only one of the two