On 21 October 2026, two critical security flaws in PHP were made public. PHP is the language behind most of the web, including WordPress, so the risk was wide. Every website we host was protected overnight, and we have seen no attacks or security incidents on any of them.
This post explains what happened, what we did, and what we recommend you check on your own website.
What happened
Researchers disclosed two vulnerabilities in PHP itself, nicknamed “php2shell” (CVE-2026-109618 and CVE-2026-109619). They affect web servers running PHP 5.4 or later. The UK’s National Cyber Security Centre (NCSC) issued an alert urging organisations to act immediately.
Both flaws are about how PHP tidies up memory when a request goes wrong. An attacker can send specially crafted web requests that push PHP into an error, then exploit the leftover memory. At worst, that lets them run their own code on the server, read sensitive data or knock a site offline, without needing to log in.
Because the problem is in PHP itself rather than in a website’s own code, updating WordPress or plugins doesn’t fix it. The PHP software on the server has to be updated. Speed mattered too: Cloudflare reported that details leaked before the official release, and it was already seeing attack traffic aimed at its customers.
How we responded
Some of the sites we host already route their traffic through Cloudflare, a security service that filters out malicious requests before they reach the server. Cloudflare had protection in place around nine hours before the vulnerabilities were made public, so those sites were never exposed.
Overnight, we added Cloudflare to every other site we host. That closed the gap while the servers themselves were being fixed. We patched PHP directly on our dedicated server, and Krystal Hosting, who host our other sites, patched PHP across their whole fleet.
One site was already due to be switched off, so we brought that forward rather than protect a site nobody needed. We also checked the tools we run that aren’t built on PHP, such as booking systems, and confirmed they weren’t affected. By the next morning, every PHP site we host was behind Cloudflare and running a patched version of PHP.
Auditing every site we host
With the immediate risk dealt with, we started auditing every website we host. For each one we’re confirming the server has the PHP update, plugins are current, downtime monitoring is running, and there’s no sign of attack. So far we haven’t found any.
We’re writing to each client with their results. Where the audit turns up anything else worth fixing, such as a cookie banner that was installed but never connected, we’re flagging that too.
What you can do
An incident like this is a good prompt to reduce what an attacker could reach on your site. These steps are worth doing whoever hosts your website:
- Delete personal data that falls outside your data retention policy.
- Remove admin users who no longer need access.
- Switch off plugins and features you aren’t using.
- Check your cookie banner is connected and scanning the site.
If your site isn’t hosted by us, ask your hosting provider to confirm PHP has been updated. The NCSC also recommends putting internet-facing sites first, and checking for signs of compromise on any system that couldn’t be patched straight away.
