Blog · 2026-10-21 (updated 2026-10-26) · Gardience Engineering

PHP2Shell (CVE-2026-109618): find and patch every server

How to check whether a server is exposed to PHP2Shell, the fixed PHP versions per distribution, the commands to patch one server, and a live test patching 600 exposed Debian web servers at once.

Update, October 26, 2026: CISA added both CVEs to its Known Exploited Vulnerabilities catalog today, which means attackers are using them, and updated its alert "Critical Vulnerabilities in PHP Require Immediate Patching." If you have not patched yet, treat this as urgent.

PHP2Shell is two critical PHP flaws, CVE-2026-109618 and CVE-2026-109619, whose details leaked before the planned disclosure. Any PHP that serves web requests is in scope: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. The UK's NCSC advised updating internet-facing PHP right away, or taking it offline until you can.

This guide gives the check and patch commands for Debian and Ubuntu, RHEL and its rebuilds, and Windows, then what it looked like when we patched 600 exposed web servers at once in a live test.

The fixed versions#

Upstream PHP fixed both flaws in 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Distributions ship their own builds, so check your distribution's own fixed version, not the upstream number:

Debian's status is on its security tracker. Ubuntu backports fixes into the version it already ships, so on Ubuntu php -v can still show an older upstream number after patching. Trust the package version, not php -v.

PHP 8.1 and older get no upstream fixes. Use your distribution's backport if it has one, or move to a supported branch.

Debian and Ubuntu#

Check which PHP packages are installed and whether the fix is waiting:

dpkg-query -W 'php*-fpm' 'php*-cli' 'libapache2-mod-php*' 2>/dev/null
sudo apt-get update -q && apt list --upgradable 2>/dev/null | grep -i php

If a php package shows up as upgradable to the fixed version in the table above, that server is exposed and the fix is one command away:

sudo apt-get install --only-upgrade 'php8.2*'      # or php8.4*, php8.3*: the branch you run
sudo systemctl restart php8.2-fpm                  # PHP-FPM
sudo systemctl restart apache2                     # if you use mod_php

On Ubuntu, compare the package version with Ubuntu's CVE page, not the number php -v prints (Ubuntu backports).

RHEL, Rocky Linux, AlmaLinux, Oracle Linux#

Check what is installed, which PHP module stream is enabled, and whether your distribution has published the advisory:

rpm -qa 'php*' | sort
dnf module list --enabled php
sudo dnf updateinfo list --cve CVE-2026-109618 --cve CVE-2026-109619

When the advisory is published, updateinfo lists it and this installs only that fix, within your enabled stream:

sudo dnf upgrade --cve CVE-2026-109618 --cve CVE-2026-109619
sudo systemctl restart php-fpm
sudo systemctl restart httpd                       # if PHP runs inside Apache

If updateinfo lists nothing yet, your distribution has not shipped the fix: watch Red Hat's CVE page (or your rebuild's). If you install PHP from a third-party repository such as Remi, update from there with sudo dnf upgrade 'php*'.

Windows#

PHP on Windows does not come from Windows Update. Find every copy and its version:

where /r C:\ php.exe
C:\php\php.exe -v                                  # repeat for each path found

Download the fixed build of your branch (8.5.12, 8.4.27, 8.3.36 or 8.2.35) from windows.php.net, with the same architecture and thread safety you run now (IIS with FastCGI uses the non-thread-safe build). Replace the files in the PHP folder, keep your php.ini, then restart what runs PHP: iisreset, the IIS application pool, or the Apache service.

After patching, on any system#

Restart what runs PHP. A long-running PHP process keeps the old code in memory until it restarts. Debian's package normally restarts PHP-FPM during the upgrade, but restart it yourself to be sure.

Then check the result on the page itself. A one-line index.php that prints PHP_VERSION shows what the web server is actually running, not just what is installed.

Patching a whole fleet: a live test on 634 servers#

Checking and patching one server is easy. The hard part is knowing which of hundreds of servers run PHP, patching all of them with someone signing off, and proving afterwards that it happened. So we built a fleet and did it.

The setup (AWS, October 21, 2026): 600 Debian 12 web servers running nginx and PHP-FPM 8.2.32, the vulnerable version, plus 34 Windows Server 2022 servers that needed their own updates. All 634 run the standard Salt agent and report to one Gardience 1.7.1 server.

Find: Gardience's CVE lookup checks every Debian machine against the Debian security tracker's own data. It found CVE-2026-109618 and CVE-2026-109619 on all 600 web servers, each marked "exposed, fix available," and correctly showed the 34 Windows servers, which do not run PHP, as not exposed.

Patch: one governed run for the whole fleet. A non-admin requested it; Gardience refused that person's attempt to approve their own request; an admin approved it. Gardience patched all 634 machines, Linux and Windows together, in 43 minutes, then rebooted them onto the new kernel the same way. All 634 answered again 3 minutes after the reboot.

Prove: after a rescan, the same lookup shows 0 machines exposed. Asked directly on each machine rather than through the console, all 600 web servers have php8.2-fpm 8.2.35-1~deb12u1 installed and their pages report PHP 8.2.35. Every request, approval and per-machine result is in Gardience's tamper-evident audit log.

What a package check does not see#

Be honest with yourself about coverage. A check based on distribution packages, ours included, does not see:

• PHP inside containers. Rebuild the images on a fixed base and redeploy.
• PHP you compiled yourself, or installed from a control panel's own builds (cPanel EA-PHP, Plesk). Update those through that tool.
• PHP on Windows. Windows security data from Microsoft covers Windows itself, not PHP, so a Windows CVE check will not flag it. Look for php.exe and check its version.

Questions#

Which PHP versions fix PHP2Shell?#

Upstream 8.5.12, 8.4.27, 8.3.36 and 8.2.35. On Debian, php8.2 8.2.35-1~deb12u1 (bookworm) and php8.4 8.4.27-1~deb13u1 (trixie). Ubuntu backports the fix, so check the package version on Ubuntu's CVE page.

Do I need to restart anything after updating?#

Yes. Restart PHP-FPM, and Apache if you use mod_php, so the running processes load the fixed code.

Is PHP on Windows affected?#

Yes. PHP2Shell is a flaw in PHP itself, so PHP on Windows under IIS or a bundle like XAMPP is affected too. Update it from php.net's Windows builds.

How do I find every exposed server at once?#

Ask every machine for its installed PHP packages and compare them with your distribution's security data. Gardience does this daily on every Debian, Ubuntu and RHEL-family machine; look up the CVE on the Vulnerabilities page to see every exposed machine, then patch them in one approved run.