Your host says PHP is patched. Here is how to check.

by

If your host says your server is patched against PHP2Shell but your PHP version number has not changed, they may well be right. Many hosting vendors fix the flaw inside the build you already run rather than moving you to a new release, and the version string stays where it was. The version number cannot settle the question either way. Three other checks can, and they take about ten minutes.

What PHP2Shell is

On October 21, 2026, the PHP project released fixes for two critical flaws, CVE-2026-109618 and CVE-2026-109619, together nicknamed PHP2Shell. Help Net Security reports that a working exploit needs a single unauthenticated request, and that it runs before any of your application code does. It affects the common ways PHP is served, including PHP-FPM, Apache with mod_php and LiteSpeed.

Researchers at Wiz demonstrated remote code execution against WordPress, Drupal and Joomla without logging in. They also showed that an attacker could read PHP’s process memory, which “may contain passwords, authentication tokens, API keys and certificates”.

The timeline was short. Amazon’s threat intelligence team recorded an exploitation attempt on October 17, four days before the public disclosure, and the security firm Sansec warned of mass exploitation within 15 minutes of the fixes being released.

The fixed upstream versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

Why the version number cannot tell you

Most websites do not run PHP exactly as the PHP project ships it. They run a build packaged by a Linux distribution, a control panel vendor or the host itself. When a critical fix lands, those packagers often take the fix and apply it to the version they already ship, because that is faster and less likely to break customer sites than a full upgrade in the middle of an emergency.

The result is a patched server that still reports the old number. AlmaLinux says it plainly in its own advisory: “Don’t rely on php -v: our fixes are backported, so the upstream PHP version number doesn’t change.” Qualys gives the same warning, and TuxCare notes that security scanners which only compare version numbers can flag patched servers as vulnerable.

It also works the other way. A server can have the fixed package installed and still be exposed, because PHP worker processes that were already running keep the old code in memory until they are restarted.

Three checks you can do yourself

1. Look at the build date, not just the version. On a server you can reach over SSH, run:

php -v

The first line shows the version and the date the build was made. A build dated October 21, 2026 or later, on a version that otherwise looks old, is the usual sign of a backported fix. It is good evidence, not proof.

2. Check what the website itself runs. The command line and the web server do not always use the same PHP. Upload a small file with a random name, such as check-7f3k2.php, containing:

<?php
header('Content-Type: text/plain');
echo PHP_VERSION, "\n", PHP_SAPI, "\n";

Open it in a browser and compare the result with what your host told you. Then delete the file, because it reveals details about your server.

3. Ask for the evidence. A support agent can tell you “yes, we are patched” without checking anything. Instead, ask for the specific package release or vendor advisory that includes the fix for CVE-2026-109618 and CVE-2026-109619, and ask whether PHP was restarted afterwards. A host that has done the work can answer both in one reply. If the answer is vague, treat the server as unpatched until it is not.

The bigger problem: versions that will not get a fix

Everything above assumes your PHP version is still supported. Many are not.

The PHP project released fixes for the 8.2 to 8.5 branches only. For 8.1, 8.0 and 7.4, its security team published minimal source patches for people who compile PHP themselves, but no official release. If your host does not backport the fix into one of those older versions, it will not arrive.

That is not a rare situation. Shodan banner counts published on October 20 found that 59 percent of internet-facing hosts that report their PHP version, 883,717 of about 1.5 million, run a branch with no official release. Those figures count servers, not websites, and some of those servers will have vendor backports. On the WordPress side, WordPress.org’s own statistics show 35.1 percent of WordPress sites running a PHP version that is no longer supported.

If your site is on PHP 8.1 or older, the question is no longer “has my host patched this?” It is “when are we moving to a supported version?” Older plugins and themes are usually what break in that move, so test it on a staging copy before switching the live site.

What helps while you wait

Updating PHP is the only complete fix, as Qualys and Wiz both say. Until it is done, these reduce the risk:

  • A web application firewall. Cloudflare deployed rules for the known exploit paths to all of its customers, including those on the free plan. If your site already runs behind Cloudflare, those rules are already working for you. They block known attack patterns, not every possible one.
  • Turning off session upload progress. Setting session.upload_progress.enabled = 0 blocks the confirmed session-based attack path. Qualys notes that it only works when set in php.ini, the PHP-FPM pool or the server configuration, followed by a restart. Setting it in a .user.ini file or in your application’s code does not count. On shared hosting, that means your host has to do it.
  • Taking a critical site offline briefly. If a site handles customer logins or sensitive documents and cannot be patched quickly, a maintenance page for a day costs less than a breach.

After the patch is in

Three things are worth doing once the fix is confirmed.

Confirm the restart. Ask your host, or check yourself if you run the server, that PHP-FPM or the web server was restarted after the update. TuxCare’s advice is to record which package was installed, which advisory it addresses and which process is actually serving requests.

Rotate secrets. The memory disclosure means anything PHP held in memory before the fix could have been read without a trace in your application logs. Changing database passwords, API keys and the authentication keys and salts in WordPress’s wp-config.php is a reasonable precaution, especially if your server ran unpatched while attacks were already under way.

Look for signs of a visit. Check for administrator accounts you do not recognize, PHP files in your uploads folder, and core files modified since mid-October. Wiz also suggests watching for repeated HTTP 500 errors and unusually large session cookies in your logs. If anything looks wrong, treat it as an incident rather than a cleanup: find out how they got in before restoring anything.

Where we sit

We manage and host websites, and PHP2Shell is a good example of why we confirm a fix by evidence rather than by a version number. If you would like a second pair of eyes on whether your own server is really patched, send us the output of the two checks above and we will tell you what it shows.

Sources