How to fix PHP2Shell: upgrade PHP and restart workers

Target versions

• PHP 8.5.12 or later in the 8.5 branch
• PHP 8.4.27 or later in the 8.4 branch
• PHP 8.3.36 or later in the 8.3 branch
• PHP 8.2.35 or later in the 8.2 branch
• Anything older: move to one of those, or confirm a vendor backport and treat a backport as a bridge. CISA says to take unpatched PHP offline if you cannot update, explicitly including PHP 8.1 and earlier.

Source tarballs and Windows builds are on the PHP downloads page. Linux distributions and LTS vendors received patches ahead of the public release, according to php.net, so the distro package is often the right path. The same note says the volunteer Remi repository at rpms.remirepo.net would not have the updates on 21 October, and urges people who rely on it to switch to distribution packages or build from source.

Debian, Ubuntu, and other apt systems

Refresh metadata and install the updated php packages your archive actually published. Names track the minor branch (php8.3-fpm, php8.3-cli, php8.3-common, and the Apache module package if you use mod_php). If the candidate version is still below the fix, you are waiting on the distro, not on a missing flag.

sudo apt-get update
apt-cache policy php8.3-cli php8.3-fpm php8.3-common
sudo apt-get install --only-upgrade php8.3-cli php8.3-fpm php8.3-common
php8.3 -v
# Web SAPI, not just the CLI:
php-fpm8.3 -v
sudo systemctl restart php8.3-fpm
# If Apache loads mod_php, restart Apache as well:
sudo systemctl restart apache2

RHEL, Alma, Rocky, Fedora: dnf or yum

sudo dnf clean expire-cache
sudo dnf update php php-cli php-fpm php-common
php -v
php-fpm -v
sudo systemctl restart php-fpm
# mod_php under httpd:
sudo systemctl restart httpd

Docker and other images

Rebuild and redeploy. Pulling a new base image does nothing until the workload that serves traffic is replaced. Official image tags usually follow PHP’s version; confirm the tag exists on Docker Hub before pinning it. Google Cloud’s note for Cloud Run and GKE is the same idea: rebuild the image you deploy, unless you are on a serverless base image Google says it is replacing for you.

FROM php:8.3.36-fpm
# or: php:8.3.36-apache, php:8.4.27-fpm, php:8.2.35-fpm, php:8.5.12-cli

# then, on the host:
# docker pull php:8.3.36-fpm
# docker build -t your-app:php2shell-fix .
# redeploy and confirm the running container's PHP version

cPanel

1. Update cPanel itself so EasyApache has a patched PHP build available. Menus move; the cPanel documentation is the authority if the labels differ.
2. In WHM, open EasyApache 4 and provision a PHP version at or above the fix for that branch. MultiPHP Manager is where domains are pointed at a specific PHP version.
3. Switch internet-facing domains off any PHP 8.1 or older handler unless your vendor has stated that the build includes the backport.
4. Restart Apache and PHP-FPM from WHM, then check a domain’s PHP version the same way you would check a pool, and remove any temporary probe page.

Plesk

1. Install Plesk and system-package updates. The Plesk documentation covers the current click-path.
2. Under Tools & Settings, review Updates and the PHP handler list. Domain PHP Settings shows which version a subscription actually runs.
3. Select a patched handler (8.2.35, 8.3.36, 8.4.27, or 8.5.12, or a vendor build you have verified). Apply it to public sites first.
4. Restart the PHP service Plesk is using and confirm with a version check against the domain, not only the panel host.

宝塔面板 (BT Panel)

宝塔’s notice, updated 22 October 2026, says the Linux and Windows panels have synced 8.2.35, 8.3.36, 8.4.27, and 8.5.12. Linux-only packages numbered 7.4.34, 8.0.31, and 8.1.35 are 宝塔 builds, not PHP project releases. The click path and the incomplete Windows setting are on the BT Panel page.

mod_php compared with PHP-FPM

Both are in the PHP project’s at-risk list. mod_php is the highest risk because the demonstrated unauthenticated path fires before application code. Restarting Apache is what reloads mod_php. PHP-FPM is a separate process: restart every pool (systemctl restart php8.3-fpm, or the equivalent unit), and remember that pools can pin their own binary. php on your shell PATH can be a different build from the pool. FrankenPHP, php-cgi, and LiteSpeed are named by PHP as serving web requests and therefore in scope; follow those vendors’ upgrade instructions rather than assuming an apt php-fpm package covers them.

Interim measures, which PHP says are incomplete

Use these only as a bridge copied from the php.net advisory. They reduce specific paths. They do not make a host safe. Put them in php.ini or in an admin-level pool or Apache setting (php_admin_value). ini_set() and per-directory .user.ini run too late for the session-upload path, according to PHP.

CVE-2026-109618

• memory_limit=-1, locked so the application cannot set a finite limit again. PHP says this removes the controllable memory-limit failure and that an underlying allocation failure can still reach the bug.
• A low post_max_size. PHP suggests 8M when the application does not need uploads, and 32M when it does, with upload_max_filesize kept below post_max_size.
• Request-size limits at the web server or proxy, including requests that have no usable Content-Length. PHP lists decoded request size, input field count, multipart part count, header count, and nesting depth.
• A container or cgroup limit as an availability boundary that kills the affected worker. PHP says not to substitute RLIMIT_AS or RLIMIT_DATA, because those can cause the vulnerable allocation failure.

CVE-2026-109619

• session.upload_progress.enabled=0, then restart every worker. PHP says this blocks the confirmed session paths and not other variants.
• On PHP 8.5 only, fatal_error_backtraces=0, then restart. PHP says this blocks the confirmed fatal-backtrace path only.
• Remove invalid or deprecated per-request settings that emit diagnostics before initialization. Turning errors off with error_reporting, display_errors, or @ does not close the bug.
• Fix fatal errors and execution timeouts an attacker can reach, including failures in callbacks and in upload or import cleanup. That is the project’s wording; it is a hardening hint, not a claim that bug-free application code makes FPM safe.

Web application firewalls

CISA says a web application firewall may provide some protection until systems are updated. Cloudflare says managed rules covering this issue were deployed for customers on free and paid WAF plans starting 21 October 2026 at 03:02 UTC, developed with the PHP Foundation and others while the bug was still under embargo, and that customers should patch anyway. A rule can be bypassed. Cloudflare’s own post says it watched payloads change as attackers tried to get around the rules. Keep the WAF. Do not use it as the fix.

After the upgrade

• Confirm the version on the SAPI that answers HTTP requests, then restart it. Expel and the University of Toronto advisory both stress the restart.
• Prioritize internet-facing systems, then anything that processes untrusted uploads or imports, then appliances. The UK NCSC and the Canadian Cyber Centre both say third-party products that bundle PHP need their own vendor updates.
• If a host sat exposed and you could not patch quickly, CISA suggests looking for PHP workers launching shells or downloading tools. The UK NCSC says to look for backdoors before you trust an upgraded host that was exposed, and points UK organizations at assured incident-response providers when that review is beyond the team. We do not have a verified indicator list to add to that advice.
• The NCSC-NL notes linked from the UK advisory are a starting inventory of products, not a certificate that an unlisted product is fine.