How to patch PHP2Shell on Ubuntu and Debian

Before you start

You need sudo on the server and about 15 minutes. Have a recent backup or snapshot, and if this is a busy production server, pick a quiet moment — restarting PHP drops in-flight requests.

Distributions received the PHP2Shell patches ahead of the public release and backport them into the PHP version they ship. That means your version number may not change — Ubuntu 24.04 stays on PHP 8.3.6, for example — so in step 3 we confirm the fix through the package changelog.

1. Find your PHP packages and where they come from

# Installed PHP packages and their versions
dpkg -l 'php*' 'libapache2-mod-php*' 2>/dev/null | awk '/^ii/ {print $2, $3}'

# Which repository a package comes from (replace 8.3 with your version)
apt-cache policy php8.3-fpm

The apt-cache policy output tells you the source:

• Ubuntu or Debian archive (archive.ubuntu.com, security.ubuntu.com, deb.debian.org, security.debian.org) — fixes arrive as backports from your distribution.
• Ondřej Surý’s repositories (ppa.launchpadcontent.net/ondrej/php or packages.sury.org) — popular for running newer PHP versions; these track upstream releases.

Also note which PHP serves the website — see how to check if the server has more than one version installed.

2. Upgrade PHP

sudo apt update
apt list --upgradable 2>/dev/null | grep -i php

Upgrade the PHP packages for your version. Listing them explicitly avoids surprise upgrades elsewhere:

# Example for PHP 8.3 with PHP-FPM — include every php8.3-* package you have installed
sudo apt install --only-upgrade php8.3-fpm php8.3-cli php8.3-common php8.3-opcache

# Apache mod_php users: include the module package too
sudo apt install --only-upgrade libapache2-mod-php8.3

Or, if you’re comfortable upgrading everything that has an update:

sudo apt upgrade

If nothing PHP-related is upgradable, your distribution or repository may not have published the fix yet — check the Ubuntu or Debian tracker for your release, and use the interim mitigations until it lands.

3. Confirm the fix is in the package

zgrep -E 'CVE-2026-10961(8|9)' /usr/share/doc/php8.3-common/changelog.Debian.gz

You should see both CVE IDs. If you use Ondřej Surý’s repositories, the package version should instead be at least the fixed upstream release (for example 8.3.36-…).

4. Restart PHP

Upgrading the files on disk doesn’t touch PHP processes that are already running. Restart whatever serves your site:

# PHP-FPM (Nginx, Caddy, or Apache + FPM)
sudo systemctl restart php8.3-fpm

# Apache with mod_php
sudo systemctl restart apache2

Nginx itself doesn’t need a restart. If the server uses unattended-upgrades, the package may already be installed while the old workers still run — the needrestart tool (sudo needrestart -r l) lists services still using outdated code.

5. Verify

# Service restarted after the upgrade?
systemctl status php8.3-fpm | grep Active

# Version of the FPM binary that serves the site
/usr/sbin/php-fpm8.3 -v

For a one-line verdict, run our open-source checker against the FPM binary:

npx php2shell-checker@latest --local --php /usr/sbin/php-fpm8.3

On distribution packages a version-only check can report VULNERABLE even after a backported fix — the changelog check in step 3 is the authority there.

Older Ubuntu and Debian releases

If your Ubuntu release is past standard support, security updates for its PHP packages may only be available through Ubuntu Pro (ESM), which is free for personal use on a small number of machines. For Debian releases past their security support window, check the Debian tracker for your release’s status. In both cases, PHP2Shell is a good reason to schedule an OS upgrade.

After patching

Attacks were observed from 17 October 2026, before the fix was public. Work through the compromise checklist, and rotate secrets your PHP apps hold in memory.

Prefer someone else to do this? We’ll patch it for you.