“My host says it patched PHP2Shell”: how to verify that your website is actually protected

Since the PHP2Shell releases of 21 October 2026, almost every hosting provider has published a status update or sent an email. Most say some version of "our servers are patched". That is usually true, but it is not something you can verify by reading the email, and three things regularly go wrong: the patch is rolled out to part of the fleet first, the package is installed but the PHP workers were never restarted, or your own account still points at an end-of-life version that no patch covers.

Here is how to check each of those, from the least to the most technical.

1. Check the version your site actually uses

Start with what your site reports: WordPress Tools > Site Health > Info > Server, a temporary phpinfo page, or the PHP selector in your hosting panel. Our version-check guide walks through each option.

Compare the result with the fixed releases: 8.2.35, 8.3.36, 8.4.27 or 8.5.12. If you see one of those or higher, the runtime is patched and you can stop here.

If the number is lower, do not panic yet. There are two possible explanations: the host has not patched, or the host uses a package that carries the fix without carrying the new version number.

2. Understand why version numbers mislead

Linux distributions and several hosting platforms backport security fixes. They apply the fix to the version they already ship and bump only the package revision. Ubuntu 24.04, for example, ships PHP 8.3.6 and will keep reporting 8.3.6 after the fix. The same applies to Debian, Red Hat, AlmaLinux and Rocky packages, to cPanel's EasyApache builds and to CloudLinux's alt-php builds.

So "8.3.6" on its own means nothing. You need to know whether that specific package contains the fix for CVE-2026-109618 and CVE-2026-109619.

3. Ask the host the right question

If you are on shared or managed hosting, you cannot inspect packages yourself, but you can ask precisely. A good support ticket reads:

Which PHP package version is installed on the server that serves my domain, does that package include the fixes for CVE-2026-109618 and CVE-2026-109619, and have the PHP-FPM or Apache processes been restarted since the package was installed?

A host that has done the work can answer all three in one line. Vague replies ("we are protected", "our firewall blocks it") are a signal to push further or to move the site.

Also check the host's status page for a dated entry. Hosts that depend on an upstream vendor for packages, such as cPanel or CloudLinux shops, sometimes published "waiting for vendor builds" notices first, so make sure the entry you are reading is the final one.

4. Check it yourself on a VPS or dedicated server

With shell access you can verify all three points.

The package version and its changelog:

# Debian / Ubuntu
dpkg -s php8.3-fpm | grep Version
apt changelog php8.3-fpm | head -40

# RHEL / AlmaLinux / Rocky
rpm -q php-fpm
rpm -q --changelog php-fpm | head -20
dnf updateinfo list --cves | grep CVE-2026-1096

# cPanel EasyApache 4 and CloudLinux alt-php
/opt/cpanel/ea-php83/root/usr/bin/php -v
/opt/alt/php83/usr/bin/php -v

The changelog entry should name the CVE ids. On Ubuntu and Debian you can also search the distribution's security notices (USN and DSA) for the php package; if there is no notice for your release yet, the package is not fixed, whatever the version string says.

The restart. An updated package does not replace code already loaded into running processes. Compare when the service started with when the package was installed:

systemctl show php8.3-fpm --property=ActiveEnterTimestamp
ls -l --time-style=long-iso /usr/sbin/php-fpm8.3

If the service started before the binary was written, restart it (systemctl restart php8.3-fpm, or systemctl restart apache2 for mod_php). The same applies to containers: a rebuilt image protects nothing until the containers are recreated from it.

Your own version choice. On cPanel, Plesk and DirectAdmin each domain selects its own PHP version. The host can patch every supported branch and your site is still exposed if the selector points at PHP 7.4 or 8.1, because no patch exists for those. Switch to a supported branch; our end-of-life article explains what to expect.

5. What external scanners can and cannot tell you

Several online tools promise to scan a URL for PHP2Shell. Treat them with care. From the outside, a scanner can only read what the server exposes, usually the X-Powered-By header, and most well-configured servers hide it (expose_php = Off). A scanner that says "not vulnerable" may simply mean "could not see the version". A scanner that attempts the actual exploit against your site is something you should only run with your host's agreement.

The reliable checks are the ones above: the package, the changelog, the restart and your own version selection.

A short checklist

1. Site reports 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 or higher: done.
2. Lower number on a distribution or vendor package: find the changelog or security notice naming the CVEs.
3. Confirm the PHP processes were restarted after the package landed.
4. Confirm your own domain is not pinned to PHP 8.1 or older.
5. Keep the host's written confirmation with your records.

If you would rather have someone run through this for you, send us your website address and hosting provider and we will confirm where you stand.