PHP2Shell · CVE-2026-109618 · CVE-2026-109619

PHP2Shell patch not working? 7 reasons a server still shows as vulnerable

Updated 23 October 2026 · By Dean, founder of Entidex Ltd

Not sure if your site is exposed? Three questions, two minutes.

A PHP2Shell patch usually looks like it is not working because PHP was not restarted, the site runs on a different PHP build from the one that was updated, or the fixed package never installed. Work through the seven checks below, then confirm with the package changelog for CVE-2026-109618 and CVE-2026-109619 and the PHP that is actually running.

Why does my server still show as vulnerable after the PHP2Shell patch?

A server can still show as vulnerable to PHP2Shell after an update for seven common reasons:

PHP was not restarted, so the old code is still in memory.
The site runs on a different PHP build from the one you updated.
The fixed PHP package did not actually install.
PHP runs inside a Docker or other container.
The site is on end-of-life PHP with no backported fix.
An online scanner is giving a false result.
The server was compromised before the patch.

Did you restart PHP-FPM after the PHP2Shell update?

Not restarting PHP is the most common reason a PHP2Shell patch looks like it is not working. Installing new PHP packages does not replace code already running: PHP-FPM pools, Apache with mod_php and LiteSpeed keep the old, vulnerable code in memory until they restart.

To find PHP processes still running deleted (old) code, run:

sudo ls -l /proc/*/exe 2>/dev/null | grep -E 'php.*\(deleted\)'

Then restart the services that serve your sites:

sudo systemctl restart php8.3-fpm     # one per PHP-FPM version in use
sudo systemctl restart apache2        # or httpd, or lsws for LiteSpeed

On cPanel, restart PHP-FPM from WHM under Restart Services. On Plesk, restart PHP-FPM for each PHP version under Tools & Settings > Services Management.

Is your site using a different PHP from the one you updated?

Many servers have several PHP versions installed, and the PHP version on the command line is often not the one serving the website. Updating php and checking php -v can leave PHP2Shell open on the PHP-FPM build your site actually uses.

cPanel (EasyApache ea-php), Plesk and CloudLinux (alt-php) install each PHP version separately, and each site can use a different one. Check the PHP version per site in cPanel MultiPHP Manager or in Plesk under each domain's PHP settings, then update and restart every PHP version a site uses. Our guide to which PHP versions are safe shows how to list every PHP-FPM build.

Did the PHP2Shell update actually install?

A PHP2Shell update can fail to install without an obvious error. Common causes are a stale package list, packages held at an old version, or a third-party PHP repository that has not published the fix yet.

# Debian / Ubuntu
sudo apt update
apt list --upgradable 2>/dev/null | grep -i php
apt-mark showhold | grep -i php

# Red Hat / AlmaLinux / Rocky
sudo dnf check-update 'php*'

Any PHP package still listed as upgradable has not been updated. A package on hold will not update until the hold is removed. Once the update is in, the package changelog should list both CVE numbers:

apt changelog php8.3-fpm | grep -E 'CVE-2026-10961[89]'
rpm -q --changelog php-fpm | grep -E 'CVE-2026-10961[89]'

Is PHP running inside a Docker container?

Updating PHP on the host does not update PHP inside a Docker or other container. Each container carries its own PHP from its image, so a container built before 21 October 2026 is still exposed to PHP2Shell.

Check the PHP version inside each container that serves websites with docker exec <container> php -v. To fix it, rebuild the image on a base image with a fixed PHP version (8.5.12, 8.4.27, 8.3.36 or 8.2.35 or later) and redeploy the container. Restarting an old container does not fix PHP2Shell.

Are you on end-of-life PHP with no backport?

PHP 7.4, 8.0 and 8.1 got no new PHP release for PHP2Shell. On those versions, an update only fixes PHP2Shell if your distribution, host or support vendor shipped a backported package. If the package changelog for your PHP 8.1 or older does not list both CVE numbers, the update you installed did not include the PHP2Shell fix. See your options for PHP 7.4 and 8.1.

Is an online scanner giving a false PHP2Shell result?

Online vulnerability scanners usually judge PHP2Shell from the PHP version a website advertises in its headers. That version is often hidden, and it does not show distribution backports, so an online scanner can call a patched site vulnerable or an exposed site safe. A scanner result is a prompt to check the server, not proof either way.

Was the server compromised before the PHP2Shell patch?

Patching closes PHP2Shell but does not remove an attacker who got in first. PHP2Shell exploit code was public on 20 October 2026, before the fix. After patching, look for:

PHP files in upload, cache or temporary folders, such as wp-content/uploads or /tmp
files with random names or recent change dates in the site folders
WordPress core files in wp-admin or wp-includes changed since 20 October 2026
new administrator accounts, cron jobs or SSH keys you did not create

If you find any of these, treat the server as compromised and get help before relying on the patch.

How do I confirm the PHP2Shell patch worked?

A PHP2Shell patch has worked when every PHP that serves a site is on a fixed version or has both CVE numbers in its package changelog, and no PHP process is still running old code. The free read-only PHP2Shell Check script checks all of this in one run on Linux: every PHP build including cPanel, Plesk and CloudLinux, the package changelog, processes that need a restart, PHP inside containers, and signs of compromise. It exits 0 when no action is needed, 1 when action is needed and 2 when it could not confirm.

curl -fsSLO https://entidex.com/downloads/php2shell-check.sh
sudo bash php2shell-check.sh

The script never changes anything. Only run it on servers you own or are authorised to manage.

How can Entidex Ltd help when a PHP2Shell patch is not working?

Patch Check, £49 per server. Run one command on your server and the report comes straight to us. It is checked automatically within a minute, and once payment has cleared you get a signed, dated result with a link your insurer or client can verify.

Emergency Fix, £149 or £299 per server. One command checks your server for compromise first, shows you the plan and changes nothing until you approve. It then updates PHP through your server package manager, restarts it, checks your sites still load and sends a signed, dated "fixed" result. £149 per server on supported PHP (8.2 to 8.5), £299 per server on PHP 8.1 or older. Limited slots each day. See prices. If it finds signs of compromise, or anything it cannot fix safely, it stops and we take over.

What else do people ask when a PHP2Shell patch is not working?

I updated PHP but my server still shows as vulnerable to PHP2Shell. Why?

The most common reason is that PHP was not restarted, so the old code is still running. Other reasons are a different PHP build serving the site, an update that did not install, PHP inside a container, or end-of-life PHP with no backport.

Does restarting the server fix PHP2Shell?

Restarting only makes an installed update live. If the fixed PHP package was never installed, a restart changes nothing. Install the update first, then restart PHP-FPM, Apache or LiteSpeed.

Does patching remove an attacker who already got in?

No. PHP2Shell exploit code was public before the fix, so a server can have been compromised before it was patched. Patching closes the door but does not remove web shells or new admin accounts. Check for signs of compromise after updating.

Can an online scanner tell me if the PHP2Shell patch worked?

Not reliably. Online scanners usually read the PHP version a site advertises, which is often hidden and does not show distribution backports. The reliable check is on the server: the installed package changelog and the PHP actually running.

Not sure where you stand? Take the free self-check: entidex.com/php2shell#check