PHP2Shell workarounds: what to change if you can't update PHP today

PHP fixed PHP2Shell (CVE-2026-109618 and CVE-2026-109619) on October 21, 2026, in 8.2.35, 8.3.36, 8.4.27, 8.5.12. Updating to the fixed release for your line is the fix. When a host or developer can't update today, PHP's security advisories list temporary settings that close some of the ways in. Proof-of-concept code is reportedly public, and security researchers reported attempts to use it within days of the fix.

The 4 workarounds at a glance

Below, each one in plain words, with the exact line your host or developer needs. If you manage your own server, apply all the ones that fit your PHP version, then restart PHP.

For CVE-2026-109619: leftover state between requests

In plain words: Leftover state from 1 request can be reused by the next, letting an attacker run code. 2 settings reduce the ways in.

Turn off upload progress tracking (session.upload_progress.enabled)

Turn off upload progress tracking, then restart every PHP worker.

session.upload_progress.enabled = 0

Upload progress tracking is the PHP feature behind some file upload progress bars. If your site has an upload form with a progress bar, test it after the change.

On PHP 8.5 only: turn off fatal error backtraces

On PHP 8.5 only, turn off fatal error backtraces, then restart every PHP worker.

fatal_error_backtraces = 0

This setting decides whether fatal error messages include a backtrace. Turning it off changes only how much detail those messages carry for whoever reads the error log. It doesn't exist on older PHP lines, so skip it there.

For CVE-2026-109618: a memory error while reading form data

In plain words: A memory error while PHP reads form data can let an attacker run their own code. 2 settings reduce the ways in, and they belong together.

Remove the per-request memory limit, and cap requests at the web server

Remove the per-request memory limit with a setting the app cannot override (php_admin_value), and enforce request size limits at the web server or proxy instead.

php_admin_value[memory_limit] = -1

The line as written is the form a PHP-FPM pool file uses. On other setups, your host or developer sets the same value in the server's own configuration, so neither the app nor a per-folder setting can bring a memory limit back.

The 2nd half matters as much as the first. With PHP's own memory cap removed, request size limits have to be enforced in front of PHP, at the web server or proxy (for example client_max_body_size in nginx or LimitRequestBody in Apache).

Keep post_max_size small

Keep post_max_size small (8M with no uploads, 32M with uploads) and upload_max_filesize below it.

post_max_size = 8M

On a site that takes file uploads, the line becomes post_max_size = 32M, with upload_max_filesize set below it. Uploads larger than the limit will fail, so tell anyone on your team who uploads big files.

Restart every PHP worker

PHP reads its settings when a worker starts. A worker that was already running keeps the old values until it restarts, so a change to php.ini does nothing for it until then. Whether the server runs PHP through PHP-FPM, Apache mod_php, php-cgi, FrankenPHP or LiteSpeed, every worker has to be restarted. On a server with several PHP versions or pools, that means each one that serves the site.

Afterward, ask your developer to confirm the new values are the ones the website actually runs with, not just what the command line reports.

Who can apply these workarounds

Whoever controls PHP's configuration and can restart PHP. In practice:

• Shared hosting (cPanel, GoDaddy, Bluehost, HostGator, Hostinger, DreamHost, Namecheap): your host. Customers often can't change these settings or restart PHP, and a setting the app can't override is server-level by design.
• Managed hosting (WP Engine, Kinsta, SiteGround, Cloudways): your host's support team, or your developer where the plan lets them change PHP settings and restart PHP.
• A VPS or dedicated server, often run through a control panel like Plesk: your developer or whoever set up the server.
• [Webflow](/platforms/webflow), [Shopify](/platforms/shopify), [Squarespace](/platforms/squarespace) or [Wix](/platforms/wix): there's no PHP for you to configure. The platform runs the servers.

On PHP 7.4, 8.0 or 8.1, PHP published the fix only as source code to build by hand, so ask your host whether it's applied and plan a move to PHP 8.2 or later. PHP versions has every line's status.

A note you can send your host

If someone else runs your server, you don't need to touch any of this yourself. Copy this note, add your website address, and send it to your host's support or your developer:

Subject: PHP2Shell (CVE-2026-109618, CVE-2026-109619) on our website

Hi,

PHP released fixes for PHP2Shell on October 21, 2026. Could you tell us which PHP version serves our website, [your website address], and whether it is a fixed release (8.2.35, 8.3.36, 8.4.27, 8.5.12, or later on the same line)?

If PHP can't be updated today, could you apply PHP's temporary workarounds from the advisories and restart every PHP worker, then let us know when the full update is planned?

Thank you.

When they reply, run PHP Scanner again. If your server shows its version, the result should list the fixed number. If it's hidden, How to check your PHP version shows where to confirm it.