PHP vulnerability (PHP2Shell): what to check and ask your host to do

On 21 October 2026 the PHP developers released emergency fixes for two critical vulnerabilities in PHP itself, named PHP2Shell. WordPress, WooCommerce, PrestaShop and many custom-built websites run on PHP. If your website uses any of them, this affects you too. The good news: the fix is ready, and checking whether you have it takes a few minutes.

In this guide you will find: what happened, how to check your PHP version without a developer, what to do today and what to ask your host or website contractor to do. I describe the situation as of 30 October 2026. The patched versions may still change, so before updating check them in the security announcement on php.net.

What happened

Two memory handling bugs were found in PHP: CVE-2026-109618 and CVE-2026-109619. A specially crafted request to a website can make the server execute someone else’s code. The attacker doesn’t need to log in or know any password. It’s enough that the website runs on a vulnerable version of PHP.

The PHP team rated both vulnerabilities 9.2 on the CVSS scale from 0 to 10, meaning critical. Patchstack described reports of attacks from hosting companies that came in a few hours before the fixes were released, and on 26 October the US agency CISA added both vulnerabilities to its catalog of vulnerabilities exploited in attacks (KEV). CERT Polska (Poland’s national computer security incident response team) issued an announcement on the matter.

There is no reason to panic, but there is a reason to check your website today.

Who the PHP vulnerability affects

The vulnerability is in PHP itself, not in a plugin or theme. That is why it affects every website that runs on PHP:

• WordPress and WooCommerce, regardless of plugins and theme,
• PrestaShop, Joomla and other website and store systems written in PHP,
• your own PHP scripts and forms, even on simple websites,
• tools on the server, such as phpMyAdmin.

According to the PHP announcement, all PHP installations that serve websites are at risk, regardless of how PHP is run on the server. Important: updating WordPress or plugins won’t fix this. The fix has to be installed in PHP on the server, and on regular hosting the provider does that.

Versions 8.1 and older no longer get releases from the PHP developers. Given how serious these vulnerabilities are, the PHP team prepared only minimal patches for 7.4, 8.0 and 8.1, for people who compile PHP themselves. Don’t count on that with typical hosting: the safe way out is moving to 8.3 or 8.4.

How to check whether your website is exposed

What counts is the full version number, with the third number at the end. “8.3” alone is not enough: version 8.3.35 is vulnerable, while 8.3.36 is not.

WordPress: without logging in to the server

1. Log in to the WordPress dashboard.
2. Go to Tools → Site Health and open the Info tab.
3. Expand the Server section. Next to “PHP version” you will see the full number, for example 8.3.36.

In PrestaShop you will find the PHP version under Advanced Parameters, in the information about the store’s configuration.

Hosting panel

In the hosting panel, in the PHP settings, you usually see only “8.3” or “8.4”, without the third number. That is enough to check that the website isn’t running on a version without support (8.1 or older). Ask your host for the full number and the fix; a ready message is below. I describe where to change the version in the OVHcloud, home.pl and nazwa.pl panels in the guide on the end of PHP 8.2 support.

A test file, only for a moment

If you have access to the server via FTP, upload a file named version.php with this content:

<?php
echo PHP_VERSION;

Open it in the browser, write down the result and delete the file right away. Don’t leave a file with phpinfo() on the server either: it’s a ready-made cheat sheet for anyone looking for weak points.

Watch out for servers with Ubuntu

On VPS servers where PHP comes from system packages, the number can be misleading. Ubuntu applies the fix to an older version and keeps its main number. In Ubuntu 24.04 the patched package has the number 8.3.6-0ubuntu0.24.04.13, not 8.3.36. In that case, ask the server administrator or the website contractor about the status of the fix.

What to do today

1. Check your PHP version using one of the methods above and compare it with the table.
2. If your version is lower than in the table, write to your host. On shared hosting, PHP is updated by the provider, not by you.
3. If you have PHP 8.1 or older, change the version to 8.3 or 8.4 as soon as possible: a backup, a test on a copy of the website, the change in the panel. It isn’t a single click, because old plugins may stop working. CISA recommends taking such websites offline until then, unless your host confirms a fix for your version in a system package.
4. If you have PHP 8.2, version 8.2.35 closes these vulnerabilities, but support for 8.2 ends on 31 December 2026. This is a good moment to move to a newer version right away.
5. Make a fresh backup of your files and database and store it off the server.
6. While you’re at it, update WordPress, the theme and plugins following the guide to updating safely. That won’t fix PHP, but it will close other ways in.
7. Don’t install “plugins that fix PHP2Shell” or scripts from forums. A plugin won’t change PHP on the server, and unknown code may contain malware.

A message to your host, to copy:

Hello, My website [website address] runs on your hosting (account: [login or customer number]). Please confirm that PHP on my account already has the fixes for the PHP2Shell vulnerabilities (CVE-2026-109618 and CVE-2026-109619), meaning at least version 8.2.35, 8.3.36, 8.4.27 or 8.5.12, or a system package with this fix, and that the PHP processes were restarted after the update. Please also let me know whether the server logs show any attempted attacks on my website since 20 October. Thank you.

If after a few days your host doesn’t confirm the update, and the panel doesn’t even offer version 8.3 or 8.4, that is a signal to change providers. As part of the domain and hosting service (from PLN 390 net a year) I move websites to a server in Poland or the EU with current PHP.

What to ask your website contractor or server administrator to do

If the website runs on a VPS, in a container or on the contractor’s server, PHP is updated by whoever manages that server. A list for them:

• Update PHP to the version from the table or to the patched distribution package (Ubuntu: USN-8948-1, Debian 13: DSA-6574-1, Debian 12: DLA-4848-1).
• Restart all PHP processes (PHP-FPM, Apache with mod_php). Without a restart, the old version keeps running in memory.
• Apache with mod_php first. The PHP team considers the risk to be highest there.
• Docker images with PHP have to be rebuilt on the new version and redeployed.
• A web application firewall (WAF) can, according to CISA, partly reduce the risk until the update, but it doesn’t replace it.
• Windows servers: on 26 October PHP released rebuilt packages 8.5.12-1, 8.4.27-1, 8.3.36-1 and 8.2.35-1 with a patched Brotli library (CVE-2026-111497). I write about that vulnerability in the guide Node.js and Brotli vulnerability (Node2Shell).

If the update has to wait, the PHP announcement gives a temporary setting. It has to be entered in php.ini or in the PHP-FPM pool configuration (not via ini_set() or a .user.ini file), and then the PHP processes have to be restarted:

session.upload_progress.enabled = 0

This is only partial protection. According to the PHP team, it blocks the confirmed attack paths through the session, but not all variants, and according to Tanium it doesn’t protect against CVE-2026-109618. Only an update gives full protection.

The third vulnerability: CVE-2026-115560

On 23 October the PHP team described another vulnerability, also related to session upload progress. The 21 October versions don’t remove it. According to PHP, it is a threat only with an unusual combination of server settings and application code, so the fix will go into the next regular release, not an emergency one.

Until then, PHP recommends the setting session.upload_progress.enabled = 0, the same as above. If this setting is already active on the server, keep it after the update too. After the change, check the forms where customers upload files. On the day I’m finishing this guide, the fix isn’t out yet, so keep an eye on the news on php.net.

Could someone have already gotten into the website

The first attack attempts were recorded before the fixes were even released. That is why, after updating, it’s worth checking that nobody managed to leave themselves a backdoor. Warning signs:

• new administrator accounts that nobody at the company created,
• unknown files on the server, especially .php files in the images directory,
• redirects to other websites or strange subpages in Google results,
• messages from your host about malware, or a sudden increase in server load.

Ask your host or contractor to review the logs since 20 October. CISA points out, among other things, PHP processes that launch a system shell or download tools. If you find signs of a break-in, change your passwords, restore a clean backup and report the incident to CERT Polska through the form at incydent.cert.pl. I will describe a step-by-step action plan in a separate guide, “Business website vulnerability: what to do in the first 24 hours”.

I show how to check the PHP, CMS and plugin versions on your website in How to check your PHP version and what your website runs on.

Summary

PHP2Shell is two critical vulnerabilities in PHP itself, not in WordPress or plugins. Check the full PHP version number, compare it with the table and ask your host to confirm the fix. Stopgap settings only reduce the risk; full protection comes from the update.

If you don’t want to keep track of this yourself, as part of technical maintenance I monitor your website, make backups and install security updates, urgent ones within 2 days. The Watch plan costs from PLN 149 net a month, and Standard (from PLN 349) and Pro (from PLN 749) give a faster response and work hours each month. If you want to check how secure your website is beyond PHP itself, order a security audit or simply write to me. I reply within 24 hours, and new clients get a 20% discount on their first order.