On 21 October 2026 the PHP project released an urgent security update. It closes two critical vulnerabilities that became known as PHP2Shell (CVE-2026-109618 and CVE-2026-109619). At 9.2 out of 10 on the severity scale, they come close to the maximum. What makes them treacherous: attackers need neither a password nor any other credentials. A single crafted request to the web server is enough to run their own code on the server.

According to the security researchers at Rapid7, this affects nearly every PHP installation that accepts web requests, whether it runs through PHP-FPM, Apache (mod_php) or LiteSpeed. And the flaw is already being exploited: Amazon recorded first attack attempts on 17 October, four days before the vulnerability was even made public. Since 21 October, the security company watchTowr has also seen attacks on its test systems.

Why WordPress sites are hit particularly hard

WordPress is built on the PHP programming language. On every page view the web server starts PHP in the background to assemble the requested page for the visitor. The problem with PHP2Shell: the vulnerabilities are not in WordPress itself but one floor down, in the server's PHP interpreter. According to Rapid7, one of the two can even be exploited before the first line of WordPress code runs.

For site owners that has a bitter consequence: an exemplary WordPress site with an up-to-date core, fresh plugins and a security plugin was just as exposed as an installation neglected for years. The usual routine of clicking "Update" in the WordPress dashboard does nothing here. The update has to be installed directly on the server, and that is exactly what many owners have no access to.

Who actually looks after your PHP?

Most websites of small and medium-sized companies sit on what is called shared hosting. There the hosting provider alone decides which PHP versions are available and when security updates are installed. A good host closed the hole on 21 October. Whether yours did, you may only find out by asking.

Older PHP versions are where it gets really complicated:

  • PHP 8.2 to 8.5: only these current versions have finished security updates.
  • PHP 7.4, 8.0 and 8.1: for these the PHP project published only the raw source code of the fix, no finished update packages.
  • PHP 5.4 to 7.3: these outdated versions are vulnerable too, but get no update at all.

A look at the current WordPress.org statistics shows how big the problem is: more than one WordPress site in three runs an outdated PHP version (around 30 % use PHP 7.4 to 8.1, another 5 % even older versions). All of these sites now depend on their host retrofitting the missing protection themselves, or they have to move to a new PHP version at short notice. Whether their theme and older plugins survive such a version jump without errors is another matter.

What to do now

  1. Check your PHP version: in the WordPress dashboard, go to Tools › Site Health › Info and look in the Server section to see which PHP version your site currently uses.
  2. Follow up with your host: ask your provider in writing whether the security updates from 21 October are installed. Worth knowing: do not rely blindly on the version number in the dashboard. Many Linux servers keep showing older version numbers although the host has long since applied the security fixes in the background (known as backporting).
  3. Plan the move to PHP 8.2+: if your site still runs a version without an update and your host does not fix it, there is no way around moving to at least PHP 8.2. Be sure to test this step on a copy of your site first to avoid nasty surprises in production.
  4. If in doubt, switch off for a while: if your site cannot be secured soon, taking it offline temporarily is a reasonable step. In this case both the UK's National Cyber Security Centre (NCSC) and the US NSA recommend exactly that.
  5. Look for signs of a break-in: since the first attacks ran before 21 October, an update alone may not be enough. Watch for suspicious changes over the past few days: are there unknown administrator accounts, new files in the web directory or odd redirects? If so, have the site checked thoroughly before you return to business as usual.

What the incident says about running a website

PHP2Shell is an exceptional case. But it shows how many layers a typical WordPress site actually consists of: core, theme, plugins, PHP and, beneath them, the web server. Each of these layers gets its updates from a different provider, and each needs someone who feels responsible for it. Day to day that is easily forgotten, because WordPress updates the visible upper layers conveniently with one click. PHP and the web server below are left to the host, often without owners knowing how reliably the work gets done there.

Then there is a basic question of how a site is built: on most websites the server computes in the background on every single page view, although the content barely changes for months. A typical company site with an overview of services, a team page and a contact form does not need to rebuild its home page a thousand times a day.

There is another way: if the site is generated in advance as static HTML, the server only delivers finished files to visitors. No PHP interpreter runs in the background for a crafted request to reach, and flaws like PHP2Shell simply come to nothing. (Incidentally, this site is built exactly that way; for the contact form, a small, separate service is enough. It runs apart from the pages and can be maintained on its own.)

Of course that is not the right path for every project. An online shop or an interactive customer portal needs code that works live on the server, whatever programming language it is written in. In the end only one thing matters: it has to be settled from the start who keeps an eye on which layer of your site and acts at once on the day of a critical security update.

Sources