Website security

PHP2Shell: is your website affected, and what should you do?

By Bhavesh Narsai · Published 23 October 2026

Two critical security flaws in PHP were made public this week, and the security world has nicknamed them PHP2Shell. PHP is the software most small business websites run on underneath, including every WordPress site. Here is what it means in plain English, how to tell in a few minutes whether your site is exposed, and what to ask your host.

What is PHP2Shell?

PHP2Shell is the name given to two security flaws in PHP itself, announced on 20 October 2026 and fixed in releases published on 21 October. Both are rated critical, 9.2 out of 10. Both can let an attacker run their own code on the server that hosts your website, without needing a login. That is the worst kind of web vulnerability, because from there an attacker can change your site, add spam or malware, or read whatever the server can read.

In technical terms, one flaw is memory corruption when PHP runs out of memory part-way through a request, and the other is data from one visitor's request being left behind and read by a later one. The second can also leak what was in memory, which can include passwords and keys. You do not need to understand either to deal with it. What matters is the version number.

The flaws are in PHP, not in WordPress or any plugin, so updating WordPress does not fix them. They affect every common way of running PHP on a web server, and security researchers rate the traditional Apache setup (mod_php), which is still common on cheap shared hosting, as the most exposed.

Is my website affected?

First, does your website run on PHP at all? If it is built on WordPress, WooCommerce, Joomla, Drupal or most website software you install yourself, or it sits on cPanel or Plesk hosting, the answer is almost certainly yes. If it is built on Wix, Squarespace or Shopify, the platform runs the servers and it is their job to patch them, so there is nothing for you to do.

If it does run on PHP, the version decides it:

One wrinkle: hosts on Ubuntu, Debian or Red Hat often patch PHP without changing the version number. A version like 8.1.2-1ubuntu2.24 might carry the fix even though 8.1.2 looks old. That is why the only reliable answer for an older-looking version comes from your host, not the number.

How do I check which PHP version my website runs?

Any one of these will tell you, and none of them takes more than a few minutes:

• Your hosting control panel. In cPanel, look for "Select PHP Version" or "MultiPHP Manager". In Plesk, it is under PHP Settings for your domain.
• Inside WordPress. Go to Tools, Site Health, then the Info tab, and open the Server section. It shows the PHP version the site is actually running.
• From the outside. Many servers announce their PHP version to anyone who asks. My free PHP and WordPress security check reads it, compares it with the official support schedule and tells you in plain English whether it is out of date. If your server hides the version, it will say so, which is good practice, and then one of the two methods above will tell you.

What should I do now?

1. Ask your host whether you are on a fixed version. Many hosts patched on release day; SiteGround, for example, published that it had applied the fixes across all its servers on 21 October. Ask in writing so you have the answer on record.
2. If you are on PHP 8.1 or older, upgrade. Most hosts let you switch version in the control panel. Take a full backup first, switch to PHP 8.4 or newer, then check the main pages, the contact form and the checkout if you have one. Old themes and plugins are the usual thing to break.
3. Update WordPress, your plugins and your theme too. They do not fix PHP2Shell, but newer PHP versions need reasonably current plugins, and you will want them working after the switch.
4. If you run your own server, follow the official advisory, apply the update or your distribution's package, and restart every service that loads PHP. The fix is not active until the PHP workers restart.

PHP has published temporary settings that reduce the risk for people who cannot update straight away, such as switching off session upload progress. They are a stopgap for whoever manages the server, not a replacement for updating, and the PHP team is clear that updating is the only complete fix.

Is anyone actually exploiting it?

Attempts have started. When CISA published its alert on 21 October it had not seen the flaws being exploited. By 22 October, Rapid7 reported several public proof-of-concept exploits and multiple reports of exploitation attempts, and Cloudflare reported attack traffic aimed at both flaws. The early exploits only work on specific combinations of server and PHP version, but researchers expect reliable ones soon. With PHP running such a large share of the web, this is a "patch this week" problem, not a "patch eventually" one.

Why are so many websites still on old PHP?

Because nothing on the website changes when PHP goes out of date. The site looks and works exactly the same the day after its PHP version reaches end of life as the day before. Nobody gets an email. Qualys, which tracks software across its customers, found that around 71% of PHP installations with a known version were already on branches that no longer get security fixes.

That is the real lesson of PHP2Shell for a small business. Updating once fixes this week's problem. Knowing the day your PHP version falls out of support, or your host falls behind on a security release, fixes the next one. Site Monitor now watches exactly that, every week, along with your security certificate and the files that should never be public.

Common questions

Sources

• PHP: 2026 news archive, the official security release announcement
• CISA: Critical Vulnerabilities in PHP Require Immediate Patching
• Rapid7: CVE-2026-109618 and CVE-2026-109619
• Qualys: how to find, mitigate and patch PHP2Shell

Also worth a read: what website maintenance actually involves.