What to do about PHP2Shell

I manage my own server

Update PHP from wherever it came from: your Linux distribution, a third-party repository, your control panel or a container image. Then restart every PHP process and check the fix is really running.

1. Find every PHP that serves websites

Servers often have several PHP versions installed, and the command-line php is not necessarily the one serving your sites. List what's installed and running:

# Debian / Ubuntu: installed PHP packages and running FPM services
dpkg -l | grep -E '^ii +php[0-9.]*-(fpm|cgi|common)|libapache2-mod-php'
systemctl list-units --type=service | grep -i php

# Red Hat / AlmaLinux / Rocky
rpm -qa | grep -Ei '^php|^ea-php|^alt-php'
systemctl list-units --type=service | grep -i php

2. Update from your PHP's source

Fixes were released on 21 October 2026. Where your PHP comes from decides how you update it, and what version number counts as fixed.

Ubuntu packages

Fixed in USN-8948-1. Ubuntu keeps its own version numbers, so a fixed server will not show 8.3.36. Check the package version instead:

Older releases (20.04 and earlier) get fixes through Ubuntu Pro (ESM) only. See USN-8948-2.

sudo apt update && sudo apt upgrade
dpkg -l | grep -E 'php8\.[0-9]-(fpm|cli)|libapache2-mod-php'

Debian packages

Fixed in bookworm (12) with php8.2 8.2.35-1~deb12u1 (DLA-4848-1) and trixie (13) with php8.4 8.4.27-1~deb13u1 (DSA-6574-1). Both come from the security repository, so make sure it's in your sources.

sudo apt update && sudo apt upgrade
dpkg -l | grep -E 'php8\.[24]-(fpm|cli)'

Ondřej Surý's packages (packages.sury.org or the ondrej/php PPA)

Very common on Ubuntu and Debian servers that run several PHP versions. Updated builds for the supported branches are in the repository. Update the same way as above, and restart every phpX.Y-fpm service you have installed.

Red Hat Enterprise Linux, AlmaLinux and Rocky Linux

Red Hat is releasing fixes stream by stream; see its security bulletin. Red Hat rates the flaws Important and says mod_php in its default setup is at higher risk than PHP-FPM. AlmaLinux and Rocky Linux rebuild Red Hat's fixes, usually within a day or two, so check their errata pages. Fixed packages may keep older version numbers, so check the changelog (step 4).

sudo dnf upgrade 'php*'
rpm -q --changelog php-cli | grep -E 'CVE-2026-10961[89]'

Remi's repository

On release day the PHP project advised Remi users to switch to distribution packages, because Remi had no updates yet. Fixed builds (8.2.35, 8.3.36, 8.4.27 and 8.5.12) have since appeared in Remi's repository. Update with dnf upgrade 'php*', or dnf upgrade 'php8*-php*' for the parallel-install packages, and restart the matching FPM services.

cPanel (EasyApache 4)

EasyApache 4 release 25.91 updated ea-php82 to 8.2.35, ea-php83 to 8.3.36, ea-php84 to 8.4.27 and ea-php85 to 8.5.12. ea-php74, ea-php80 and ea-php81 got the fix as a backport with no version change. Updates normally arrive with cPanel's nightly updates; to apply them now:

dnf clean all && dnf upgrade 'ea-php*'      # yum on older systems
/scripts/restartsrv_httpd
/scripts/restartsrv_apache_php_fpm

CloudLinux (ea-php and alt-php)

CloudLinux has released fixed ea-php and alt-php packages, and its native OS PHP is rolling out more slowly. Its fixed builds keep older version numbers: a fixed ea-php84 shows 8.4.26, not 8.4.27. So check the changelog, not the version. CloudLinux also notes that security-only update filters won't pick these up, so run a normal update. See CloudLinux's post.

dnf clean all && dnf upgrade 'ea-php*' 'alt-php*'      # yum on CloudLinux 7
rpm -q ea-php84-php-cli --changelog | grep -E 'CVE-2026-(109618|109619)'

Plesk

Plesk's PHP updates of 21 October moved PHP to 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and backported the fix to 8.1.34, 8.0.30 and 7.4.33, which keep those numbers. Plesk's own panel PHP was updated in Obsidian 18.0.81 Update 4 and 18.0.80 Update 11. Install updates from Tools & Settings, Updates, or with plesk installer update, then restart the PHP-FPM services and the web server.

Docker official PHP images

The official php images were rebuilt for 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Images for PHP 8.1 and older are no longer maintained and won't be fixed. Pull the new base image, rebuild your own images on top of it and redeploy:

docker pull php:8.4-fpm          # your tag
docker build --pull -t my-app .
docker run --rm my-app php -v

Built from source

Build 8.2.35, 8.3.36, 8.4.27 or 8.5.12. For 7.4, 8.0 and 8.1, the PHP project published minimal source patches in branches named PHP-<version>-CVE-2026-109618-109619. Read the PHP advisory.

3. Restart PHP, every worker

Both flaws involve state left behind inside long-running PHP processes. A package update doesn't replace processes that are already running, so restart every PHP-FPM service and the web server, including any using mod_php:

# Debian / Ubuntu (repeat for each installed version)
sudo systemctl restart php8.3-fpm
sudo systemctl restart apache2   # or nginx

# Red Hat / AlmaLinux / Rocky
sudo systemctl restart php-fpm
sudo systemctl restart httpd     # or nginx

For LiteSpeed, restart the LiteSpeed service, which also restarts its PHP (lsphp) processes. For containers, redeploy from the updated image. Restarting PHP inside a running container isn't enough.

4. Check the fix is really there

Distribution and vendor builds often keep the original version number and add the fix as a patch. So 8.1.2 on Ubuntu can be fixed while 8.1.2 elsewhere is not. The suffix after the number, such as -1ubuntu2.21 or +deb12u3, identifies the build.

Look for the CVE numbers in the package changelog:

# Debian / Ubuntu (change php8.1-fpm to your package)
apt changelog php8.1-fpm 2>/dev/null | grep -E 'CVE-2026-10961[89]'

# Red Hat / AlmaLinux / Rocky
rpm -q --changelog php-fpm | grep -E 'CVE-2026-10961[89]'

If both CVE numbers appear in the changelog of the package version you have installed, and PHP has been restarted since, you're patched. For upstream builds without a suffix, compare against the fixed versions.

If you can't update today

The PHP advisory lists these measures. It's explicit that they reduce exposure but don't make a server safe: updating is the only complete fix.

For CVE-2026-109619:

• Set session.upload_progress.enabled = 0 in php.ini, the FPM pool or the server configuration, then restart every PHP worker. Don't rely on ini_set() or a .user.ini file, because they take effect too late. This only disables upload progress bars, which few sites use.
• On PHP 8.5, also set fatal_error_backtraces = 0 and restart every worker.

For CVE-2026-109618:

• Set memory_limit = -1 in a way applications can't override, for example php_admin_value[memory_limit] = -1 in the FPM pool. Check that nothing sets a limit again further down. This removes PHP's own memory cap, so contain each worker with a container or cgroup memory limit instead. The advisory warns not to use RLIMIT_AS or RLIMIT_DATA (such as systemd's LimitAS=), because those can trigger the flaw.
• Lower post_max_size to 8M if the site takes no uploads, or 32M if it does, with upload_max_filesize below it. Where you can, also limit request size, form field count and multipart parts at the web server or proxy.

For both: put a firewall service in front. Cloudflare's managed rules for PHP2Shell are active on every plan with the firewall turned on, including free. If you can't apply the update or these measures soon, CISA and the UK NCSC advise taking the system offline until you can. See how to take a site offline properly.

Once you're patched, check the server for signs of compromise.