Visit the InstaHost Status Page for our Latest Updates – The latest email sent to clients is at the bottom of this post.

At some point this morning the Finnish government switched off its public web services. Not a department. The lot. Edinburgh City Council’s website went dark around the same time, and so did the online homes of Doctor Who and The Traitors, which is the kind of detail that tells you a BBC engineer somewhere had a very short meeting.

They were all doing the same arithmetic. Two flaws in PHP, the language that quietly runs WordPress, Drupal, Joomla, Magento and an awful lot of software that never mentions PHP on the tin, had leaked on Monday afternoon before a fix existed. The fix was promised for 3pm UK time on Wednesday. Between the leak and the fix lay roughly twenty-two hours in which anyone holding the leaked details could, in principle, run their own code on any PHP web server they could reach.

The fix arrived at 2.34pm, twenty-six minutes early.

I am writing this at half past four on Wednesday because InstaHost runs 18,412 websites, 9,300 of them WordPress, and every single one of them runs on PHP. I would rather you heard what this means from me, in plain terms, than pieced it together from a forum thread at midnight.

If you need help with this – please contact support through your InstaHost Control Panel!

What actually happened, in the order it happened

Monday 20 October, mid-afternoon. A post appears on Hacker News claiming two remote code execution bugs in PHP core, with CVE numbers attached, due for disclosure on Thursday. The post is taken down. Too late. The security researcher Kevin Beaumont flags the leak at 16:39 UTC, and the firm watchTowr confirms the bugs are real and that it has reproduced one of them. At 19:33 UTC the PHP security team publishes an advance notice: two critical vulnerabilities, both rated 9.2 out of 10 on the CVSS v4.0 scale, fix due Wednesday at 14:00 UTC. An hour later CERT-EU, the emergency response team for the EU institutions, publishes Security Advisory 2026-018. Its advice is blunt. Prepare to patch the moment fixes appear, and where you cannot, ‘consider isolating internet-facing applications from public networks until a fix can be applied’.

Wednesday 21 October, 13:34 UTC. PHP publishes two advisories on GitHub and releases PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The flaws now have names and descriptions. CVE-2026-109618 is remote code execution through out-of-memory corruption. CVE-2026-109619 is remote code execution through stale global state. Every PHP release before those four fixed versions is listed as affected. The UK’s National Cyber Security Centre publishes an alert with an eight-point action list the same afternoon. Cloudflare’s chief technology officer, Dane Knecht, says they are seeing early attacks and are updating mitigations as new vectors appear. watchTowr says the same from its honeypots.

The bugs were found by researchers at Calif and Wiz, working with OpenAI, using frontier AI models to build working exploits across multiple applications in hours rather than weeks. Wiz describes them as among the most severe vulnerabilities ever found in PHP, and estimates that roughly 70% of the web is affected. The BBC said it could not verify that figure and neither can I. What I can verify is that Wiz traces the vulnerable code back to PHP 5.4, which means it sat there for well over a decade, and that the people who finally found it needed an AI to do it. Make of that what you will.

Why your security plugin cannot see this one

The flaws live in PHP’s own request handling, in the part of the engine that runs before WordPress, or Joomla, or your bespoke application, has loaded a single line of code. PHP’s own advisory for the first flaw says that on Apache with mod_php the exploit completes ‘entirely before any application-specific code begins execution’. Wordfence told its users the same thing in plainer words: WordPress automatic updates will not apply this fix, because the fix is not in WordPress.

A maintenance page does not help, because the maintenance page is served by PHP. A login screen does not help, for the same reason. A web application firewall at the edge may catch the known attack patterns, and Cloudflare has deployed rules across its network, but the PHP team is explicit that updating the runtime is the only reliable mitigation.

What a successful attacker gets is code execution as the web server account. The second advisory also lists memory disclosure, which is getting less attention than it deserves. Memory disclosure means that whatever another request happened to be holding in the same worker process, a session token, a database password, an API key, can potentially be read back out. On any platform where sites share infrastructure, that is a sentence worth reading twice.

One technical constraint works in everyone’s favour. For the second flaw, the request that plants the bad state and the request that consumes it have to land on the same PHP worker. More workers, and regular worker recycling, reduce the odds on any given attempt. They do not remove the condition.

PHP published interim settings for servers that cannot be patched immediately: disabling session upload progress, removing the per-request memory limit, and on 8.5 switching off fatal error backtraces. Every one of them has to be applied administratively, at the server level, with every worker restarted afterwards. Not in a .user.ini file. Not with ini_set() in your theme. Which means that on any managed platform, including ours, this is our job and not yours. You could not apply these yourself even if you wanted to.

The question I was asked at three o’clock: can we just move everyone to 8.5?

It is the obvious question, and I understand why it was asked. The answer is no, or at least not on its own, for three reasons worth setting out plainly.

First, 8.5 is a branch, not a patch level. PHP 8.5.11 came out on 24 September and is exactly as vulnerable as 7.4. The fix is 8.5.12 specifically. When you pick a PHP version in your control panel you are choosing which major version your site runs against, not which build. The build is ours to deploy. A version number in a dropdown is not a guarantee of a patch level.

Second, and this one genuinely surprised me this afternoon, 8.5 is the single branch with an extra confirmed trigger for the second flaw. PHP 8.5 introduced fatal error backtraces, and the advisory names that feature as the strongest demonstrated case and the basis of the confirmed exploit. Moving a site from 7.4 to an unpatched 8.5 does not reduce its exposure. In one specific configuration it widens it.

Third, moving 9,300 WordPress sites to 8.5 overnight would break some of them. WordPress core compatibility with 8.5 is still catching up, and a site that stops rendering at 3am produces a support ticket, not a security improvement.

What moving does achieve is this. The PHP project is not shipping releases for 8.1, 8.0 or 7.4. It has published minimal source backports for people who compile PHP themselves, which describes almost nobody reading this. So a site sitting on 7.4 will still be running vulnerable code after every patched build in the world has been rolled out, because there is no patched build for it to receive. Moving off the dead branches is what you do so that the fix can reach you at all. It is not itself the fix.

Where we are

Our platform runs PHP-FPM rather than Apache mod_php. For the first flaw, that closes off the simplest route, the one that needs no application code whatsoever, because FPM terminates a worker whose startup fails instead of letting it continue with corrupted state. For the second flaw it does not close anything. PHP validated the session route against FPM too. Narrower is not the same as closed.

Patched builds are being deployed across the platform [INSERT CURRENT STATUS AND TIMESTAMP BEFORE PUBLISHING]. Managed Cloud Servers and Managed WordPress are handled by us; you do not need to do anything for the runtime itself.

If you have an Unmanaged VPS with us, you hold root, and this one is yours. Install your distribution’s patched PHP package today, restart PHP-FPM or your web server, and confirm through the package changelog that CVE-2026-109618 appears in it. A patched package sitting on disk does nothing until the workers restart. If you are on PHP 8.1 or older, this is the week that ends.

What to do today

Three things, in order. The first takes about four minutes.

1. Find out which PHP version your site runs, from the PHP settings in your control panel. If it says 7.4, 8.0 or 8.1, move it to 8.3 or 8.4 now. Not 8.2, which stops receiving security fixes on 31 December. Not 8.5 unless you have tested your site on it first. Then click through your main pages, your contact form and your checkout if you have one. If something breaks, you have thirty days of timeline backups and a support team whose average time from ticket raised to problem fixed is twenty-four minutes. Use both.
2. Stop expecting WordPress to handle this. It cannot reach the layer where the problem lives. Keep plugins and themes updated anyway, because the people who come looking after a wave like this will also be checking the ordinary doors.
3. Assume your site may have been reachable between Monday evening and the moment the patched build landed, and check accordingly. The NCSC’s seventh action point says it directly: if a system was unpatched and online, look for evidence of compromise before you call it fixed. For a WordPress site that means administrator accounts you do not recognise, files modified in the last three days that you did not touch, changes to .htaccess or wp-config.php, and scheduled tasks that appeared from nowhere. Rotate any password or key that was stored on the server. If you would rather we looked, raise a ticket with the site name and we will compare it against its own backups. And if a site of yours is dormant or seasonal and you would simply prefer it parked behind a static page until you are satisfied, ask us and we will park it.

The twenty-two hours

The organisations that pulled their websites offline today were not panicking. The Finnish government, the Dutch parliament, the City of Edinburgh. They had an inventory. They knew where PHP was running and what it was exposed to, and they made a decision in minutes that most organisations could not have made in a week, because most organisations do not know where PHP is running. The NCSC’s first instruction, before patching and before mitigating, is simply to find it. Don Smith of Sophos told the BBC that the hard part was never installing the patch; it was finding every place PHP quietly sits.

Very few InstaHost customers needed to turn anything off today, and that is the job. But everyone who owns a website should be able to answer, inside a minute, which version of PHP it runs and whose job it is to update it. Twenty-two hours is not very long. The next one may be shorter.

---

Andy McGurk is CEO of AMVEN Ltd and has been hosting other people’s websites from Peterborough since 1996, on renewable energy since before anyone asked for it.

Published 4.30pm BST, Wednesday 21 October 2026. This post will be updated as deployment completes. Last updated: 22/10/2026 10:22

This is the latest email sent to InstaHost Clients:

Following our previous email about the recently disclosed PHP security vulnerabilities, we can confirm that the security patches have now been deployed across our hosting platform.

We have also backported these specific fixes to older PHP versions available on our platform, down to and including PHP 7.4.

Important: PHP 7.4 is the oldest version covered by this emergency fix. If your website is running a PHP version older than 7.4, it has not received these fixes from us and remains at risk from these vulnerabilities.

This emergency patch does not replace regular updates

Although we have patched these particular vulnerabilities in PHP 7.4 and later, this does not make older PHP versions fully supported or protect your website against every security risk.

It is imperative that you keep all of the following up to date:

• Your WordPress installation.
• Your WordPress plugins and themes.
• The PHP version used by your website.

Keeping one of these updated does not remove the need to maintain the others. You should also maintain a current backup of your website before making changes.

Which PHP versions are supported?

The following dates refer to support provided by the PHP project, separately from the emergency fixes we have backported:

PHP version	Current support status	Key support dates
PHP 8.5	Full support: bug fixes and security updates	Full support until 31 December 2027, then security-only support until 31 December 2029
PHP 8.4	Full support: bug fixes and security updates	Full support until 31 December 2026, then security-only support until 31 December 2028
PHP 8.3	Security fixes only; no regular bug fixes	Security support ends 31 December 2027
PHP 8.2	Security fixes only; no regular bug fixes	Security support ends 31 December 2026
PHP 8.1 and older	End-of-life	No longer receive updates from the PHP project

These are the PHP project’s published support periods.

Our emergency backports for PHP 7.4–8.1 address these specific vulnerabilities only. They do not restore ongoing support from the PHP project, and you should still plan to move to a supported PHP version.

What you need to do

1. Check which PHP version your website is using through your hosting Control Panel.
2. Ensure WordPress, plugins and themes are up to date.
3. Take a current backup before making updates or changing PHP versions.
4. Move to a supported PHP version compatible with your website. Do not assume that an older version is suitable for continued use simply because it received this emergency patch.

If you are running PHP older than 7.4, please raise a support ticket urgently so we can help you review your options.

If you are unsure which PHP version you use, what needs updating, or whether your website will work with a newer PHP version, please raise a support ticket before making changes. Our team can help you identify what needs reviewing.

Thank you for your cooperation in keeping your website secure.