Your Host Says PHP Is Patched. Here's How to Actually Check

After the PHP2Shell vulnerabilities landed on 21 October, we did what everyone else did and went to check our own server. We expected it to take thirty seconds. It took considerably longer, because the two obvious ways to check PHP's version both gave us a misleading answer.

Neither trap is exotic. Both will catch anyone checking a site on ordinary shared hosting, which is most small business sites. So here is what went wrong, in order, and what actually works.

Correct as of 25 October 2026. This is a fast-moving situation and some of the detail below will have changed. Where it matters, we have said what is confirmed and what is not.

The short version

On shared hosting, php -v over SSH tells you about the command line PHP, which is frequently not the version your website runs. And a host that has patched by backporting the fix will keep the old version number, so a version that looks out of date may be perfectly safe. Check what the web server reports, not the CLI, and confirm the patch through your host's status page rather than by comparing version numbers.

Trap one: the version you see is not the version your site runs

We logged into our server and ran the obvious thing:

$ php -v
PHP 8.2.34 (cli) (built: Oct 21 2026 00:00:00) (NTS)

PHP 8.2.34. The fixed 8.2 release is 8.2.35. One version short — which looked, for a worrying minute, like a problem.

It was not, because our website does not run PHP 8.2 at all. That is the command-line interpreter, which on shared hosting is usually just whatever the server's default happens to be. The web server runs a completely separate PHP binary, chosen per site in your hosting control panel.

The only way to know what your site runs is to ask the web server. Put a file called phpcheck.php in your web root:

<?php
echo "SAPI: " . php_sapi_name() . "\n";
echo "VERSION: " . PHP_VERSION . "\n";

Load it in a browser, note what it says, then delete it immediately. Do not leave it there and do not use phpinfo() for this — it publishes your paths, extensions and configuration to anyone who finds the URL, and people do scan for exactly that file.

Ours said:

SAPI: litespeed
VERSION: 8.3.35

So the site was on 8.3.35, not the 8.2.34 the command line had reported. Entirely different branch. Had we acted on php -v we would have been reasoning about the wrong interpreter.

If you have no SSH access at all, you do not need it: your hosting control panel has a "PHP version" or "PHP configuration" page per site, and that is the number that matters. In WordPress, Tools → Site Health → Info → Server reports the same thing.

Trap two: a patched PHP usually keeps the old version number

Here is the part that produces most of the unnecessary panic this week.

Our site reported 8.3.35. The fixed 8.3 release is 8.3.36. By the arithmetic everyone has been doing, that is unpatched. It is not.

Shared hosts do not generally wait for upstream and install a whole new PHP release — that would change behaviour on thousands of customer sites at once. Instead they backport: take the specific security fix, apply it to the version they already ship, and rebuild. The result is a binary that contains the fix and still calls itself 8.3.35.

CloudLinux, whose alt-php builds run under an enormous share of cPanel and shared hosting, said exactly this — the fixes are backports, the reported version does not change, and you should check the package changelog for the CVE IDs rather than trusting php -v. Red Hat, Debian and Ubuntu all work the same way.

On our own server the tell was in the timestamps. Every PHP branch installed had been rebuilt within hours of each other on the day of disclosure:

php80  8.0.30  rebuilt 2026-10-21 11:26
php81  8.1.34  rebuilt 2026-10-21 11:22
php82  8.2.34  rebuilt 2026-10-21 11:19
php83  8.3.35  rebuilt 2026-10-21 12:11
php84  8.4.26  rebuilt 2026-10-21 13:49
php85  8.5.11  rebuilt 2026-10-21 13:47

Six PHP branches, every one of them rebuilt on 21 October, every one of them still carrying its old version number. Nobody rebuilds every PHP branch on a Tuesday afternoon for fun. That is a coordinated security backport, and the dates line up precisely with the embargo lifting.

So how do you actually confirm it?

In this order, stopping as soon as you get a clear answer:

1. Read your host's status page or security notice. This is the fastest and most reliable route, and every serious host published one within a day. Hostinger's says the fix reached all its hosting plans except VPS, with the rollout finished on 22 October. If your host has published that, you are done.
2. Check the package changelog, if you have root. On a cPanel or CloudLinux box, rpm -q --changelog alt-php83 and look for the CVE IDs. On Debian or Ubuntu, apt changelog php8.3. The CVE number appearing in the changelog is proof; a version number is not. On shared hosting you will not have access to this, which is fine — step 1 covers you.
3. Ask your host directly. "Has CVE-2026-109618 been patched on my server, and when?" is a reasonable support ticket and you should get a straight answer. A host that cannot answer it is telling you something useful about the host.
4. If you manage the server yourself, update and then restart your PHP workers. An updated package with the old process still running has changed nothing, because the running worker is still executing the old code in memory. This is the single most common way people patch and stay vulnerable.

What not to rely on

• Online "is my site vulnerable" scanners. Most of them read your version number from an HTTP header and compare it to a list — which, as above, gives the wrong answer on any host that backported the fix. They generate false alarms on patched servers and they will miss a genuinely unpatched one that hides its version.
• The X-Powered-By header. Often disabled, often stale, never authoritative.
• A WordPress plugin's security score. Useful for other things, not for this.
• Your own memory of what you set the PHP version to. Control panels change it during migrations and automatic upgrades more often than you would expect.

The wider point

The reason this was confusing is that a version number is a proxy for "is it safe", and on managed hosting it is a bad proxy. The thing you actually want to know is whether someone is responsible for patching your server and whether they did. If you can answer that in one sentence, you did not need any of the checks above. If you cannot, the version number was never going to tell you.

That is the gap our website care plans are meant to close — knowing which PHP every site runs, and getting a straight answer out within hours of something like this rather than within weeks. If you would rather just know where you stand right now, send us the domain and we will check what it is actually running. It takes a couple of minutes and there is no charge for it.