PHP session upload progress vulnerability after the PHP2Shell patch

Originally published at hamzaahmadaslam.com.

How this article was made: drafted with AI assistance from a researched brief, then checked against primary documentation before publishing.

The PHP session upload progress vulnerability remains open after the PHP2Shell patch. On 23 October 2026, php.net warned about an unlikely remote code execution path tracked as CVE-2026-115560; the 21 October security releases still fix the two original PHP2Shell vulnerabilities. Set session.upload_progress.enabled=0 in server-level PHP configuration and restart your PHP workers until the next regular bugfix release.

What changed after the PHP2Shell security releases?

The PHP project published an informational advisory on 23 October, two days after releasing fixes for CVE-2026-109618 and CVE-2026-109619.

The new advisory describes an unlikely route to remote code execution (RCE), where an attacker can cause a server to run code.

Date	Event	Source
21 Oct 2026	PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 released with fixes for the two original PHP2Shell vulnerabilities.	php.net
21 Oct 2026	Issue #24481 opened, reporting a separate unserialize() use-after-free problem.	php-src GitHub
22 to 23 Oct 2026	Hosted Power released updates to its php_uploadprogress_guard extension, including version 3.2.4 on 23 October.	Hosted Power GitHub
23 Oct 2026	PHP published the session upload progress advisory and assigned CVE-2026-115560 to the remaining vector.	php.net

The earlier CVE-2026-109619 advisory recommended disabling session upload progress. That blocked its confirmed session-related attack paths, but not every variant of CVE-2026-109619. It offered no protection against CVE-2026-109618.

PHP says updating is the only complete response to the original vulnerabilities. Disabling upload progress adds protection against the remaining session-related risk.

What does PHP session upload progress do?

A session lets PHP retain temporary information between requests from the same visitor.

PHP can track file upload progress through session data. According to the PHP session upload progress manual, tracking starts when a multipart upload includes a form field named by session.upload_progress.name.

The default field name is PHP_SESSION_UPLOAD_PROGRESS. Another request can read the stored information to update an upload progress indicator.

The feature has existed since PHP 5.4.0 and is enabled by default.

Upload progress operates during request parsing, before the application's ordinary PHP code runs. That early processing is why it appeared in the original PHP2Shell advisory. The confirmed CVE-2026-109619 session path involved internal state surviving between requests.

The new advisory concerns a narrower combination of session settings.

Upload progress bars can use other methods, including JavaScript. Test your site's uploads after disabling this PHP feature instead of assuming every progress indicator depends on it.

Who faces the PHP session upload progress vulnerability?

PHP calls the CVE-2026-115560 scenario unlikely because all three conditions must occur:

1. The application configures session.serialize_handler as either php_binary or php_serialize.
2. Before calling session_start(), application code changes that handler to php using ini_set().
3. session.upload_progress.enabled remains enabled.

The serialize handler controls how PHP converts session information into a stored format and reads it back.

The names php, php_binary and php_serialize refer to different storage formats.

An application that uses php_serialize consistently does not match the described condition. Neither does one that uses the default php handler without changing it at runtime.

PHP explicitly says applications that never change their serialize handler at runtime can keep upload progress enabled.

How can a site owner check?

Ask your hosting provider or developer to confirm:

• Which session serialize handler is configured for your website.
• Whether plugins, themes or custom code change that handler during requests.
• Whether session upload progress is enabled in the running web server configuration.

A hosting dashboard showing session.serialize_handler=php provides only part of the answer. Application code may change that setting.

If nobody has checked the code, disabling upload progress is the simpler precaution.

How can a developer check the code?

Search the site's PHP files for references to the serialize handler.

From a WordPress installation directory, run:

grep -RIn --include='*.php' 'session.serialize_handler' wp-content/

Inspect matches in plugins, themes, must-use plugins and custom code. Search application and vendor directories outside wp-content when relevant.

Look for an ini_set() call changing session.serialize_handler to php before session_start().

Check the original handler value in php.ini and PHP-FPM pool settings. A search with no matches cannot establish safety when configuration changes occur elsewhere or use dynamically constructed code.

As of 23 October 2026, php.net has published neither a separate affected-version list nor a fix date for CVE-2026-115560.

Which PHP installations still need more urgent attention?

The narrow CVE-2026-115560 condition should not distract from servers still missing the original PHP2Shell fixes.

Servers running unsupported PHP versions

PHP 8.1 and older receive no new releases from the PHP project.

For the October emergency, PHP provided minimal source backports for PHP 7.4, 8.0 and 8.1 on branches named PHP-<version>-CVE-2026-109618-109619.

These help vendors build patched versions. They do not restore regular security support.

VirusTotal's 21 October exposure analysis shows how widespread older installations remain.

VirusTotal measurement	Approximate IP addresses
Fingerprinted as running PHP	5.1 million
Disclosing a PHP version	1.1 million
On supported branches 8.2 to 8.5	272,000
On end-of-life branches 5.4 to 8.1	758,000
Running PHP 7.4	187,000
Running PHP 5.4	119,000
Running the September releases immediately preceding the fixes	85,000

VirusTotal calculated these figures from Internet scans on 21 October, using rounded medians of seven runs.

These are exposure figures, not counts of confirmed vulnerable or compromised websites. A disclosed version cannot reliably show whether a distribution has applied a backported fix.

VirusTotal also warned that expose_php=Off only hides the version header. It does not remove a vulnerability.

Servers waiting for distribution packages

An operating system package may retain an older version number while incorporating security fixes.

Check the vendor's security notices and package changelog. Confirm that the installed build fixes both CVE-2026-109618 and CVE-2026-109619.

Disabling upload progress cannot compensate for missing fixes to other attack paths.

Servers that have not restarted PHP

A package update does not establish which PHP code existing processes are running.

PHP workers handle incoming requests. Existing workers may retain previously loaded code until they exit.

Restart the appropriate service after updating PHP. The guide to WordPress PHP workers explains how these processes handle WordPress requests.

Sansec updated its PHP2Shell research on 22 October. The company said mass exploitation was less likely than initially assessed because attacks required specific conditions and target knowledge. Sansec still advised updating PHP.

How do you disable session upload progress correctly?

Set session.upload_progress.enabled to 0 in configuration applied before PHP parses incoming requests.

The 21 October advisory names php.ini, an FPM pool or server configuration as suitable locations. Application-level changes happen too late.

Step 1: Find the active PHP configuration

Identify how your website runs PHP.

PHP-FPM, the FastCGI Process Manager, handles PHP requests through managed worker processes. A pool is a group of workers with its own configuration.

Apache mod_php runs PHP directly inside Apache processes.

Managed hosting providers may control these settings. Check the web server's PHP version and configuration files, since command-line PHP can use different settings.

Step 2: Edit php.ini

Find the php.ini file used by the website's PHP service.

Add or change:

session.upload_progress.enabled = 0

Check for another configuration setting that overrides it. Inspect each relevant PHP version or pool if the server hosts multiple sites.

This disables session upload progress tracking, not ordinary PHP file uploads.

Step 3: Configure a PHP-FPM pool

An administrator can enforce the setting in the relevant PHP-FPM pool:

php_admin_flag[session.upload_progress.enabled] = off

The php_admin_flag directive sets a Boolean PHP option administratively. PHP's FPM documentation confirms that values applied this way cannot be overridden using ini_set().

Check that you are editing the pool serving your website.

Step 4: Configure Apache mod_php

If Apache loads PHP as a module, use this directive in the appropriate server or virtual-host configuration:

php_admin_flag session.upload_progress.enabled off

The PHP manual states that php_admin_flag is unavailable in .htaccess.

Do not put this directive into .htaccess on a PHP-FPM server. It applies to Apache mod_php.

Step 5: Ask managed hosting to apply it at server level

Hosting control panels often expose PHP options through a PHP INI editor or PHP configuration screen.

Set session.upload_progress.enabled to Off or 0, then confirm where the panel writes it.

A panel may save the change only in .user.ini. PHP's advisory warns against relying on FPM .user.ini because it is processed too late for this protection.

If you cannot inspect the server configuration, send your provider this instruction:

Set session.upload_progress.enabled=0 in the PHP startup configuration or relevant PHP-FPM pool, restart every affected PHP worker, and confirm the running value for my website. Please do not rely only on .user.ini or application-level ini_set().

Step 6: Restart PHP workers

Restart the service running PHP after saving the configuration.

For example, on Debian or Ubuntu using the php8.4-fpm systemd service:

sudo systemctl restart php8.4-fpm

Use the service name matching your installation.

For Apache running PHP through mod_php, a Debian or Ubuntu example is:

sudo systemctl restart apache2

Other systems use different names. Managed hosts may provide a restart control or require support assistance.

Confirm every affected worker has restarted. Apply the change across all servers handling your website's PHP requests.

Step 7: Verify the setting from the website

Check both the startup configuration and the value reported by the running web PHP process.

An administrator can temporarily create a restricted diagnostics page:

<?php
phpinfo();

Open it through the website's normal web server.

Find session.upload_progress.enabled. Its running Local Value should be 0 or Off.

Also inspect the PHP version, Server API and loaded configuration file. A Local Value of 0 alone is insufficient if it came only from .user.ini. Confirm the startup configuration enforces it.

A phpinfo() page exposes server details. Restrict access and delete the file immediately after checking.

Do not rely on php -i or php --ini alone. Those commands inspect command-line PHP, which may use different configuration files.

What stops working when upload progress is disabled?

The change removes PHP's session-based upload progress tracking.

Applications reading progress from PHP session data may lose their progress indicators. Ordinary PHP file uploads remain available.

Test these workflows after making the change:

1. Upload an image through WordPress Media Library. Confirm it appears.
2. Add or replace a WooCommerce product image. Save and check the product page.
3. Submit a form plugin's file upload field. Confirm the attachment reaches its destination.
4. Watch any upload progress bar and confirm the upload finishes.

Also test custom upload and import workflows outside standard WordPress interfaces.

If something fails, check whether that feature reads PHP session upload progress information.

What does the Hosted Power guard change?

Hosted Power's php_uploadprogress_guard is an MIT-licensed PHP extension developed for the company's hosting fleet.

The project released updates on 22 and 23 October, reaching version 3.2.4 on 23 October.

Hosted Power says its extension detaches the upload progress handler at the parser level, including on patched PHP. It also claims protection for other PHP issues, including the separately reported unserialize() problem.

The vendor argues that normal applications do not need PHP's session upload progress feature enabled.

PHP's official position is narrower: applications that never switch serialize handlers at runtime can keep upload progress enabled, although PHP recommends disabling it until the next release.

The extension adds another component to maintain and test. It is a vendor-provided temporary protection, not a replacement for PHP security updates.

What is the separate unserialize() report?

A php-src issue opened on 21 October, #24481, reports a use-after-free condition during unserialize().

The unserialize() function rebuilds PHP values from serialized data. A use-after-free occurs when software accesses memory after that memory has been released.

The report describes a problem during internal cleanup when serialization-related operations occur again.

A commenter reports reproducing the memory error under Valgrind on PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 and 7.4.33. Valgrind is a tool for detecting incorrect memory access.

As of 23 October 2026, issue #24481 remains open with the label Status: Needs Triage. The page contains no PHP maintainer confirmation.

Hosted Power also says its tests reproduced the problem and that its extension contains a workaround. That is separate vendor testing.

The issue does not establish a connection to CVE-2026-115560, session upload progress or the confirmed PHP2Shell attack paths.

Avoid calling unserialize() on attacker-controlled data. Review existing uses where the data source is unclear, and watch for maintainer triage and any resulting PHP fix.

Session upload progress check

Copy this block into a hosting support ticket or deployment checklist.

Look: Active php.ini, PHP-FPM pool or Apache mod_php server configuration.
Set: session.upload_progress.enabled = 0 before request parsing.
Restart: The affected PHP-FPM service or Apache mod_php service; restart all workers.
Verify: Check the running web PHP value and confirm the server-level configuration.
Test: WordPress Media Library, WooCommerce product images and form file uploads.

Ask the host to confirm the PHP version and both original PHP2Shell fixes.

If the setting was already disabled correctly after 21 October and workers restarted, PHP says to keep it in place. No additional action is required for this advisory.

What should you watch for in the next PHP release?

Three items need follow-up after 23 October.

First, PHP says the next regular bugfix release will include the complete CVE-2026-115560 advisory. Its 23 October notice gives no release date.

Second, check the full advisory when available. The informational notice describes the unusual configuration condition but gives no separate affected-version list.

Third, plan your move away from PHP 8.2.

PHP 8.2 reaches end of life on 31 December 2026. End of life means the PHP project stops providing security fixes for that branch.

If your website still uses PHP 8.2, test an upgrade to a branch supported beyond that date.

Keep upload progress disabled until the next release and review PHP's updated guidance.

What should you do on your WordPress site today?

Confirm the installed PHP security update, upload progress setting and worker restart status.

For the original vulnerabilities, use the PHP2Shell security update guide and full response checklist. It covers fixed versions and the wider response to the 21 October releases.

If your site shows unauthorized file changes, unexpected PHP scripts or other suspicious behavior, investigate the installation. The WordPress malware removal service covers sites needing compromise investigation and cleanup.

For an already patched, normally operating site, confirm the server-level setting, restart PHP if needed, and test the uploads your business uses.