How to Check Whether Your Server Is Patched Against PHP2Shell

Two PHP vulnerabilities, nicknamed PHP2Shell, were disclosed on October 21, 2026. They are tracked as CVE-2026-109618 and CVE-2026-109619, and both carry a CVSS v4.0 score of 9.2. If your site or app runs on PHP, there is one practical question to answer today: is the PHP on your server actually patched?

The answer is not always as obvious as reading a version number. This guide covers what was fixed, how to check your own setup in two commands, and what to do if the answer is no.

What PHP2Shell is and which versions are fixed

PHP2Shell is the name used for a pair of flaws in PHP itself, not in WordPress, a theme or a plugin. Public write-ups, including Cloudflare's, describe them as memory handling bugs that can allow remote code execution, among other impacts. Because the problem sits in the language runtime, updating your CMS does not fix it. Only a patched PHP does.

The PHP project released fixes in these versions:

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35

PHP 8.1 and older are end of life and get no fix from the PHP project. If you are still on one of those branches, the real answer is to move to a supported version, not to wait for a patch that is not coming.

What we know about exploitation

Reports differ a little, so here is the careful version. AWS, watchTowr, SecurityWeek and Sophos reported exploitation attempts in the wild. CISA said on October 21 that it had not observed exploitation. Both statements can be true at the same time, since attempts and confirmed successful attacks are not the same thing. Either way, a critical flaw with public details is worth closing quickly rather than debating.

Why the version number can mislead you

Most people run php -v, see something like 8.3.x, and either panic or relax. Neither reaction is reliable. Linux distributions often backport a security fix into an older package and keep the same version number. A server can therefore be patched while still reporting a version that looks old, or look current while running a build from before the fix.

That is why the build date matters. A patched build should show a build date of October 21, 2026 or later.

How to check your PHP version and build date

Connect to your server over SSH and run these two commands:

php -v
php -i | grep -i "build date"

The first prints your PHP version. The second prints the build date. You can also create a temporary page that calls phpinfo() and read the same field in your browser, then delete the page right away so it does not stay public.

One catch: php -v reports the command line PHP. Your website may be served by a different binary, such as PHP-FPM or an Apache module, and some servers have several PHP versions installed side by side. If the CLI looks fine, check phpinfo() through the web server too, so you are looking at the PHP that actually handles your visitors.

If you use shared or managed hosting

You usually cannot update PHP yourself on these plans, and you do not need to. Your host manages the runtime. The right move is to check with your host, read their status page or announcement, and use the build date check above if they give you a way to view PHP info.

Several providers have published their own notices about PHP2Shell. We list them here as references so you can see what a host announcement looks like:

• Hostinger: protections against the PHP2Shell vulnerabilities
• SiteGround: critical PHP vulnerabilities, October 2026
• WP Engine: status incident page
• cPanel: critical PHP security release
• Cloudflare: WAF protection for the PHP vulnerabilities

A WAF rule is a useful extra layer, but it is not a replacement for a patched PHP. Keep it enabled while you update, not instead of updating.

If you run your own VPS or server

On a self-managed server, nobody will patch PHP for you. The steps below are typical Debian and Ubuntu commands. Adjust them for your distribution and your setup.

sudo apt update && sudo apt upgrade

Then restart the PHP service so the new binaries are actually loaded. Replace 8.4 with the version you run:

sudo systemctl restart php8.4-fpm
sudo systemctl restart apache2

Use the PHP-FPM line if your web server talks to PHP-FPM, and the Apache line if you run PHP as an Apache module. If you use nginx with PHP-FPM, restarting PHP-FPM is the part that matters.

A few honest caveats. If your server uses a third party repository for PHP, such as Ondrej Sury's packages (the PPA on Ubuntu or packages.sury.org), the exact fixed versions may only arrive through that repository. Backported builds may keep the old version number, which is again why the build date is the check to trust. If you are on PHP 8.1 or older, plan an upgrade to a supported branch and test your application on it first.

A short checklist

1. Run php -v and note your version and whether it is on a supported branch.
2. Run php -i | grep -i "build date" and look for October 21, 2026 or later.
3. Update your packages, or ask your host to confirm they have done it.
4. Restart PHP-FPM or Apache so the update takes effect.
5. Check again, including phpinfo() for the PHP your website really uses.

How to confirm it worked

After the update and the restart, repeat the checks. You want to see the build date of October 21, 2026 or later, and a version that matches or exceeds the fixed releases for your branch where the package carries the upstream number. If the build date is still old, the update did not reach that binary. Look for a second PHP installation, a missing repository, or a service that was not restarted.

We have already updated PHP on our servers at Pro Gineous. If you run a self-managed VPS (plans start from $6.96/mo), PHP on that machine is yours to update, so the steps above apply to you.

Whatever your setup, the whole check takes a couple of minutes. Run the two commands, read the build date, and you will know where you stand.