This story is still moving. We’re updating this article while it does; the date at the top shows when we last did.

The short version

  • On 21 October the PHP project fixed two critical flaws in PHP itself. Not in WordPress, not in a plugin, but in the language that WordPress, Joomla, Drupal, Magento, Nextcloud and most other website systems are written in.
  • An attacker doesn’t need a login. Attempts began on the morning of 21 October, hours before the fix came out.
  • Only a PHP update closes the hole: 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Updating your website software changes nothing. WordPress.org has said so plainly: no WordPress update is required or planned.
  • Who installs the update depends on your hosting. On most plans, it’s your host. Ask them today, in writing.

What happened

20 October. In the afternoon, the flaws’ identifiers leak online. That evening the PHP project announces a security release for the next day at 3pm UK time, a day earlier than planned, with two flaws rated 9.2 out of 10.

21 October, morning. From about 8:30am UK time, hosts report the first attacks on PHP websites to the security firm Patchstack, and Cloudflare reports early attempts too. Amazon later said its honeypots had caught a first attempt on 17 October. Working attack code circulates publicly, and by around 1pm automated scanning of large numbers of websites has begun. The fix isn’t out yet. By late morning the UK’s National Cyber Security Centre (NCSC) has published an alert: where a fix can’t be applied straight away, organisations should consider taking the system offline.

21 October, shortly before 3pm UK time. The updates appear, a little ahead of schedule.

21 and 22 October. Hosts install the updates. Some take sites offline as a precaution while they do. On 22 October the government told the House of Lords that 32 government services were unavailable and four partially, as a precaution; Downing Street stressed that this did not mean they had been hacked. The NCSC called the scale unprecedented. Cloudflare’s chief executive now speaks of millions of attempts. As of the evening of 22 October, no one has confirmed successful attacks on a large scale: the security firm Rapid7 hasn’t seen one in the wild, and Sansec now thinks mass exploitation less likely than it did on the day. That can change, and the advice doesn’t depend on it.

What the flaws are, without the jargon

There are two, CVE-2026-109618 and CVE-2026-109619. In the first, PHP gets confused when it runs out of memory in the middle of a request, and tidies up half-finished data as if it were finished. In the second, data from one request survives into the memory of the next. Both can be triggered from outside with specially crafted requests, without a login, and at the end the server runs someone else’s code. Hence the name “PHP2Shell”, after Log4Shell in 2021.

The flaws were found by the security firm Calif, by OpenAI independently and by Wiz, which found further ways in, with the help of AI tools. They go back more than a decade, to PHP 5.4 at least; the NCSC puts it simply: “Organisations using any version of PHP are affected.” The riskiest set-up is “mod_php” on the Apache web server, where an attack can fire before a single line of WordPress runs.

Who is affected

Everything that runs on PHP. According to W3Techs, that’s 69% of all websites whose server-side language can be identified, so roughly seven in ten. In detail:

  • WordPress, by far the most used system. WordPress.org: no WordPress update needed or planned; the fix is the PHP update.
  • Joomla and Drupal. The same. Drupal says it explicitly: updating PHP is the only complete fix. Joomla had published nothing by 22 October; it doesn’t need to, the answer is the same. (TYPO3, common in Germany, has said the same as WordPress.)
  • WooCommerce, Magento, PrestaShop, OpenCart: online shops, with customer data on the server.
  • Nextcloud, Matomo, phpMyAdmin, Roundcube and other tools that often run on the same hosting on the side.
  • Network devices and NAS boxes with PHP inside, such as the firewalls pfSense and OPNsense, which Germany’s federal security office names. Check your device maker’s security page.
  • The installations you’ve forgotten. The test copy from the last redesign, the old WordPress in a subfolder, the site of the project that ended. Each is an open window, even if nobody has looked at it for years.

Not affected: websites with no PHP running on their domain. That means sites delivered as finished pages, and website builders such as Wix, Squarespace or Shopify, where the provider runs everything itself.

Why updating WordPress, Joomla or Drupal doesn’t help

Think of your website as a stack. At the bottom the server, on it PHP, on that WordPress (or Joomla, or Drupal), and on top your theme and your plugins. Every layer needs its own updates, and any of them can be the way in.

This time the hole is in the second layer from the bottom. Nothing you update above it makes any difference. Nor does a security plugin: it runs in PHP itself, so above the hole. Patchstack warns explicitly against “fix plugins” and copied code snippets doing the rounds. There is one fix, and it’s the PHP update.

What to do now

1. Ask your host, in writing. For example: “Has the PHP security fix of 21 October 2026 (CVE-2026-109618 and CVE-2026-109619) been installed on my plan, for the PHP version my website actually uses?” In writing, because you may need the answer later, and because the version number alone doesn’t tell you: many hosts and Linux distributions build the fix into the version you already have without changing the number. A patched site can still show “8.5.11”.

2. Find your PHP version. In WordPress under Tools → Site Health → Info → Server. In Joomla under System → System Information. In Drupal under Reports → Status report. How to find it in your host’s control panel, too, is in our guide Which PHP version is my website on? The fixed versions:

Your version Safe from
PHP 8.5 8.5.12
PHP 8.4 8.4.27
PHP 8.3 8.3.36
PHP 8.2 8.2.35
PHP 8.1 and older no update from the PHP project, see step 3

3. On PHP 8.1 or older? The PHP project no longer releases updates for these versions, only source-code patches (for 7.4, 8.0 and 8.1) that hosts and Linux distributions can build in. Some hosts have done that; ask yours. If your host hasn’t patched your old version, the only way out is moving to 8.2 or newer: take a backup first, then check every page and every form. If the site breaks, switch back and get help. But don’t leave it on an unpatched 8.1.

4. Your own server? If you run a dedicated server or a VPS, install your distribution’s updated PHP packages (the distributions got the patches in advance) and restart PHP and the web server. Don’t forget Docker containers and staging sites. If you can’t do that straight away, the PHP project lists temporary settings that reduce the risk (turning off upload progress, adjusting the memory limit and the maximum upload size), but says plainly: “There are no complete mitigations, updating is the only safe choice.” If you can’t apply even those, the NCSC and WordPress.org advise taking the site offline until you can.

5. Afterwards. Open your website, test the contact form, look at the list of users. New admin accounts, plugins you don’t know, files that don’t belong there? Then someone may have got there first; the NCSC advises looking for backdoors on any system that wasn’t patched straight away. What to do then is in WordPress site hacked? What to do in the first 24 hours. And if there’s customer data on the server: under UK GDPR, a breach that’s likely to put people at risk must be reported to the ICO within 72 hours of you becoming aware of it.

Where the hosts are

A snapshot from the evening of 22 October, UK time, from the hosts’ own status pages and announcements. Don’t rely on it. Ask.

  • IONOS: the official update is on every platform IONOS runs itself (status page, 22 October, 11:32am). Nothing said about PHP 8.1 and older. On a VPS or dedicated server, you patch it yourself.
  • 123 Reg and GoDaddy (one company, and TSO Host now leads to 123 Reg): all PHP versions patched, on managed WordPress on the evening of 21 October, on web hosting by 2:30pm on 22 October.
  • Krystal: finished on 22 October across web, reseller and business hosting, for every version from 5.2 to 8.5. The fix is built in, so the version numbers stay as they were.
  • 20i: every PHP version on every platform patched by 9pm on 21 October, the old versions included.
  • Fasthosts: rolled out the official updates on the platforms it runs itself; closed the incident on 22 October at 3:46pm without saying which versions.
  • Heart Internet: cPanel, managed WordPress and managed VPS done on 22 October; on eXtend shared hosting PHP 7.2 and newer were done, PHP 5 was still in progress.
  • Guru: finished at 2:57am on 22 October, with the fix built into the existing versions.
  • SiteGround: fixed “across all supported PHP versions” (22 October, 1pm), without listing them.
  • Hostinger: finished at 7:44am on 22 October on every server except VPS, for every version from 5.2 to 8.5.
  • Bluehost: not finished; its last update, on the morning of 22 October US time, reported progress.
  • Kinsta and WP Engine (managed WordPress): done by the morning of 22 October, for every version they offer.
  • cPanel and Plesk, the control panels many hosts use, have shipped the fix for PHP 7.4 to 8.5 on Linux, built into 7.4, 8.0 and 8.1 without new version numbers. Your host still has to install it.

Why this keeps happening

This is the third alarm of its kind in five months.

  • June: a flaw in JCE, an editor for Joomla (CVE-2026-48907, rated 10 out of 10), is exploited; the US agency CISA gives federal agencies three days to fix it. The layer: a plugin.
  • July: “wp2shell”, two flaws in WordPress itself (CVE-2026-63030 and CVE-2026-60137). Attackers install backdoors before the emergency releases 7.0.2, 6.9.5 and 6.8.6 have reached every site. The layer: the system.
  • October: PHP2Shell. The layer: the language under everything.

Every layer has its own update rhythm, and you’re at the end of the chain: the door is only shut again once your host, the plugin’s maker and you have all reacted. This time hosts had hours, not days. And the next date is already set: PHP 8.2 gets no security fixes after 31 December 2026. For 8.1 that has been the case since 31 December 2025.

And on Johnny?

To be honest: the update comes first. The patch takes an hour; a move takes longer. So steps 1 to 5 above first.

Then the question of whether it has to be like this next time. Johnny moves your WordPress site, same look and same addresses, to a site that is delivered as finished pages. No PHP runs on your domain, and there are no plugins, no admin login and no database. What every attack of this kind needs isn’t there. We don’t say “unhackable”: your site is still on the internet, a small function on our side handles your contact form, and Johnny itself is software. We keep those up to date; that’s our job and it’s in the monthly fee. On your side, nothing is left that you’d ever have to patch again.

How the move works and what it costs: Patch PHP today. Then never again.

Sources