PHP2Shell Stopgap: Disabling session.upload_progress and Other Temporary Measures

By Umair Ali Sadaqat · Updated October 22, 2026 · Editorial policy

A stopgap, not a fix. The temporary settings the PHP team lists for servers that cannot update yet, where each one must be set, what it blocks, and what it can break.

Read this first: these settings are a stopgap. The PHP security team says plainly that only updating is a complete solution, and that the measures below "reduce exposure to specific attack paths but do not make an installation safe". Use them to buy hours or days while you arrange the update to 8.2.35, 8.3.36, 8.4.27 or 8.5.12. Then remove the ones that cost you something. (What the flaws are: Black October overview.)

Where these settings must go

All of them must apply before PHP parses the request. That means:

php.ini for the PHP build that serves the site,
the PHP-FPM pool file (php_admin_value[...]), or
the web server configuration (php_admin_value / php_admin_flag in Apache for mod_php).

They do not work through ini_set() in your code or through an FPM .user.ini file. After changing them, restart every worker. A reload that keeps old workers alive is not enough.

On shared hosting you cannot set these yourself; ask your host (see the shared hosting guide).

For the stale global state flaw (CVE-2026-109619)

1. Turn off upload progress tracking

``ini session.upload_progress.enabled = 0 ``

In an FPM pool: php_admin_flag[session.upload_progress.enabled] = off.

This blocks the confirmed session-based paths, not every variant. What it can break: upload progress bars that rely on PHP's session upload progress feature. Most modern upload widgets track progress in the browser instead, so many sites see no change. Test a large upload after applying it.

2. On PHP 8.5 only: turn off fatal error backtraces

``ini fatal_error_backtraces = 0 ``

This blocks the confirmed fatal-backtrace path only. You lose stack traces for fatal errors in logs until you turn it back on, so note it for whoever debugs production.

3. Remove noisy per-request settings

The advisory warns about invalid or deprecated settings applied per request that emit diagnostics before startup finishes. Look in .htaccess, pool files and per-directory configs for old or misspelt directives and remove them. Hiding the messages with error_reporting, display_errors or @ does not help.

4. Fix fatal errors attackers can reach

Fatal errors and execution timeouts in callbacks, upload or import handling and cleanup are part of the attack surface. Your error logs show which public URLs produce them.

For the memory corruption flaw (CVE-2026-109618)

5. Remove the PHP memory limit

``ini memory_limit = -1 ``

Set it so applications cannot override it (php_admin_value in the pool or Apache), and check that no pool, directory or app puts a finite limit back. Even then, an underlying allocation failure can still reach the bug.

What it costs: a runaway script can now use all available memory. That is why the next two items go with it.

6. Lower the maximum request size

``ini post_max_size = 8M ; sites without uploads ; post_max_size = 32M ; sites that need uploads upload_max_filesize = 6M ; keep below post_max_size ``

Ideally also enforce limits at the web server or proxy: decoded body size, number of input fields, number of multipart parts, header count and nesting depth, including for requests with no usable Content-Length. What it can break: large media uploads, product imports and backup restores through a web interface.

7. Contain memory at the container or cgroup level

Use a container or cgroup memory limit as the safety net, ideally one that kills only the affected worker. The advisory warns not to use RLIMIT_AS or RLIMIT_DATA for this, because those can trigger the very allocation failure the bug needs.

A sensible order

If you only have a few minutes: item 1, then items 5 to 7 together, then restart every worker. Then schedule the update for the soonest window you can get.

After you update

Once PHP is on a fixed release, restore the settings you changed for convenience: the memory limit and upload sizes in particular. Keep any request-size limits that suit your site anyway. Then check whether anything happened before you acted, using the compromise checklist.

Source: php.net security advisory, 21 October 2026.

Move your site to WeInc

A site with no PHP server has no PHP settings to tune during an emergency. Move your site to WeInc: first month free with code BLACKOCTOBER, until November 21, 2026. New customers only. Claim the offer

Related guides and tools

Start building

How we research, test and update this page: our editorial policy. We.Inc is our own product.