Critical PHP Flaws: Our Response

TL;DR: On Wednesday 21 October 2026 the PHP Foundation confirmed a set of critical security flaws in PHP, the programming language that runs behind most of the world's websites, including WordPress, Wikipedia and a large share of online shops. The flaws, now known as PHP2Shell, let an attacker run their own code on a vulnerable web server without logging in. Governments took sites offline as a precaution and attackers began scanning for targets within hours.

The sites we host were already in the middle of a hosting security programme when the news broke. Every server is being locked so that only Cloudflare can reach it, every site now runs in its own isolated PHP process with a capped share of the server, and PHP on every server, including the older PHP 5.6 sites, has been updated to the patched releases 23 October. No client action is needed. We are emailing every hosting client directly with the detail for their site.

• What happened: critical flaws in PHP itself, present for at least a decade, found with the help of AI and disclosed on 21 October after details leaked a day early.
• Scale: the researchers who found it estimate PHP runs around 70% of websites; Prof Alan Woodward of the Surrey Centre for Cyber Security put the number of affected sites at some 30 million.
• Your sites: no successful attack has been reported against any site we host. [CONFIRM] Our sites stayed online throughout.
• Our stance: the fix is not one patch. It is patching plus a Cloudflare edge in front of every server, plus isolation between sites, so a problem on one site cannot reach another. That work is included in your hosting.

For details on our infrastructure and support options, see our Website Hosting and Domain Services.

PHP is the code that runs on a web server and builds the page you see. When you open a WordPress site, a Contao site or most online shops, PHP is collecting the content from a database and turning it into a page. It has done that job since the 1990s and it still runs a very large share of the web.

PHP2Shell is the name given to a group of flaws in PHP itself, not in WordPress, not in a plugin and not in how a site was set up. The US National Security Agency made that point directly: the flaws "are flaws in PHP itself, not in the hosted application or its configuration". Under the right conditions they let someone who has never logged in send a request that makes the server run their code. From there, as Prof Alan Woodward told the BBC, an attacker can "steal data, they can go to other parts of your network" or plant a backdoor for later.

Two things make this one unusual.

The flaws are old. The BBC reports they went undetected for at least a decade and affect many past versions of PHP. Researchers at Wiz and Calif found them in part using OpenAI's tools, following up a line of enquiry the PHP Foundation had theorised in 2024. Ryan Austin, who has researched PHP security for 20 years, called it "the most serious vulnerability I've ever found".

The response time has collapsed. Cloudflare's chief executive Matthew Prince said his network saw thousands of exploitation attempts in the ten hours before the public announcement, tens of thousands in the 45 minutes after it, and millions by the end of the day. Amazon's security chief said the use of AI means "more actors can act within hours or even minutes once technical details of a vulnerability are disclosed". A few years ago a flaw like this would have given a hosting company weeks. This one gave us hours.

All dates from the BBC's reporting of 22 October 2026. The PHP Foundation had planned a coordinated release later in the month; the leak forced it forward.

The honest answer is almost everyone who runs a website, whether they know it or not. Wiz, which helped uncover the flaws, puts PHP behind roughly 70% of websites. The BBC could not independently verify that figure, but even a conservative reading covers most small business sites in the UK, because most of them run WordPress.

The advice from the UK's National Cyber Security Centre, and its counterparts in the EU, US and Australia, was blunt: apply the fixes, and "where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated". That is why so many public sites disappeared on Wednesday. They were not hacked. Their owners could not patch fast enough to be sure, so they pulled the plug while they worked.

It is worth separating three groups:

• Sites that were patched quickly. The exposure window was hours. Cloudflare, Amazon and the large hosts fall into this group.
• Sites taken offline as a precaution. Government services, councils, Wikipedia in part. Inconvenient, but the safe call.
• Sites nobody is looking after. Old WordPress installs, a brochure site built years ago, anything on a server with no one responsible for updates. These are the ones that will be found by the scanners now sweeping the internet, and Matt Hull of NCC Group warned that patching globally is not happening as fast as it should.

If you have a website with us, you are in the first group, and the rest of this post explains why. If you have a site elsewhere that nobody has touched in a while, now is the week to find out who is responsible for it.

We host client websites on a small number of our own servers at AWS in London, plus a newer platform on Vercel for sites built on Payload CMS. Here is where each stands.

Sites on our AWS servers. These do run PHP, so this is where the work happened. On [date] we updated PHP on every server to the patched releases published by the PHP Foundation, and confirmed each site returned the same response afterwards as before. [CONFIRM: No site was taken offline to do it.]

Older sites on end-of-life PHP. A handful of sites still run PHP versions that stopped receiving routine security fixes years ago, because the software they are built on cannot run on anything newer. Normally that would leave them exposed. This time the PHP Foundation released a fix for those older branches as well, including PHP 5.6, and we have applied it to every one of those sites. Patching alone is not enough for them, though, because the next flaw in an old branch may not get the same treatment. So those sites also live together on one server that accepts web traffic only from Cloudflare, and each runs in its own isolated process so it cannot affect the others. We will be talking to the owners of those sites about rebuilding or retiring them.

Cloudflare in front of everything. Since 22 October it has been a condition of hosting with us that every site is protected at Cloudflare's edge. Cloudflare's managed firewall rules for PHP2Shell were blocking exploit attempts on our zones from 22 October. Four of our five servers now refuse any web connection that does not come from Cloudflare, and the fifth is being completed.

One unprotected site on a shared server exposes every other site on it, which is why we are no longer willing to host a site outside that protection.

What we saw. Our own monitoring and Cloudflare's logs show scanning attempts against our sites from 22 October, all blocked at the edge or refused by the server. We have found no evidence that any site we host was compromised.

Security maintenance included in your hosting: what changed this week

Most of this work was already under way before the PHP news broke, because it is the right way to run shared hosting whether or not there is a headline. PHP2Shell moved it up the list. If you host with us, all of it is included in what you already pay.

Cloudflare-only servers. Each server's firewall now accepts web traffic solely from Cloudflare's published address ranges, and the web server checks that each connection really came from Cloudflare before it answers. Scanners that find our servers' addresses directly get nothing back.

One PHP process per site. Until this week, sites on the same server shared one pool of PHP workers. Now every site has its own. A traffic spike, a slow plugin or a problem on one site stays with that site, and a weakness in one site's code cannot be used to read another site's files.

A capped share of the server for each site. Every site has been given a package, Small, Medium, Large or Max, that sets the most PHP workers it can use at once. Busy sites get more; a site we have agreed to wind down gets less. The point is that no single site can take the whole server down.

Monitoring that records the facts. Our own monitoring system checks every site every minute, alerts us by Zoom and SMS when something is wrong, and records each site's PHP version, worker limit and server settings daily. When a question like PHP2Shell arrives, we know in seconds which sites run which version, rather than finding out by logging in to each server.

What is still to do. The last server is being closed to Cloudflare-only traffic, and the legacy sites need a longer conversation with their owners. We will be in touch with each of them separately.

Nothing. If your site is hosted with us, the patching, the Cloudflare protection and the isolation work have been done for you as part of your hosting.

What to expect from us:

• An email about your site. Every hosting client will receive a short email in the next few days confirming what was done for their site specifically, including the PHP version it runs and whether it is one of the legacy sites that needs a longer conversation.
• No visible change. Your site should look and behave exactly as before. If you see anything different, a page that will not load, a form that stops working, a login that fails, tell us and we will look at it straight away.
• Search rankings. Our sites did not go offline, so there is nothing to recover. Short outages of the kind other sites had this week do not harm Google or Bing rankings; crawlers slow down and come back later.

If you have a website that is not hosted with us, the question to ask whoever looks after it is simple: has PHP been updated since 21 October 2026, and is the site behind a firewall such as Cloudflare? If the answer to either is no or "I'm not sure", that needs fixing this week, and we can help.

• PHP2Shell is a set of critical flaws in PHP itself, disclosed on 21 October 2026, that let an attacker run code on an unpatched server without logging in.
• The flaws are at least a decade old, were found with the help of AI, and were being exploited within hours of disclosure. Patching windows that used to be weeks are now hours.
• Governments took sites offline as a precaution. That was caution, not evidence of a breach, and the NCSC has reported no successful attack in the UK.
• Every site we host has been patched, including those on older PHP, sits behind Cloudflare, and now runs in isolated PHP processes with a capped share of each server. No client action is needed.
• The handful of legacy sites on old PHP were patched this time, but they are also contained behind Cloudflare on one server, and we will talk to their owners about what comes next.
• If you have a site hosted elsewhere, find out this week who is responsible for keeping its PHP up to date.

• BBC News: UK working to identify exposure after global cyber-security warning, 22 October 2026. Government response, Amazon's honeypot findings, Prof Woodward and Ryan Austin interviews.
• BBC News: Race to update services' computer systems after cyber-security flaw found, 22 October 2026. UK services offline, NCSC statement, Cloudflare and NCC Group comments, what PHP is.
• NCSC: guidance on the PHP vulnerabilities.
• PHP Foundation: security release and patched versions.
• Cloudflare: Matthew Prince on exploitation attempts across the Cloudflare network.
• Doublespark: Cloudflare outage, 18 November 2025, our previous hosting incident post.

If your website is hosted elsewhere and you do not know whether it has been patched, we will check it for you and tell you plainly what we find. For details of what our hosting includes, see our Website Hosting and Domain Services.

Check My Site's PHP Exposure