PHP2Shell: why we briefly took one of our own systems offline

Last week, two critical vulnerabilities in PHP, nicknamed PHP2Shell (CVE-2026-109618 and CVE-2026-109619), were announced. PHP runs a large share of the web, from business websites to the tools used to manage hosting servers, so issues like these matter to almost anyone with a website.

Here's what we did, step by step. It's a real example of how we look after the systems we host for our customers, and of the kind of judgement calls good IT support involves.

Before the announcement

We knew an announcement was coming before the details were made public. Rather than wait passively, our team kept a close eye on official channels and on the wider security community, including social media and specialist forums, for any early information.

We used that time well. We checked exactly which customer services hosted on our systems could be affected, so that when the details landed we would already know where to act first.

When the details were released

As soon as the information was published, we:

Applied the recommended mitigations across the affected systems straight away
Added extra layers of fallback protection, in case any mitigation didn't hold
Put the affected services under live monitoring

A real example: one of our own systems

One of our own web servers went through exactly the same process, and it shows how we weigh up the risks. (Our website wasn't affected: this was one of the systems behind our services.)

We applied all of the mitigations, added our fallback protections and monitored the server live.
At close of business, we made a judgement call. Rather than rely on mitigations alone overnight, we took the server offline while we waited for the official patch from our hosting control panel vendor.
The patch arrived the same day. We applied it, then brought services back up for visitors in the UK only, so we could watch them closely overnight, with our own fallback protections still in place in case anything went wrong with the patch.
The following morning, with everything stable, we brought the server back for visitors worldwide.

Taking one of our own systems offline wasn't a decision we took lightly. But a few hours of downtime on our own system is a small price to pay for keeping risk to a minimum, and it's the same careful thinking we apply to the services we look after for our customers.

What our customers saw

When customers contacted us the next day to ask about PHP2Shell, most were reassured to hear that the patch had already been applied, and that their systems had been actively monitored from the moment the details were released.

The best response to a security issue is the one that's already happened by the time you ask.

Proactive when we can, reactive when we must

There's no such thing as a business that will never face a security issue. What matters is how prepared you are when one arrives. A few principles guided us last week:

Watch for early warnings. Knowing something is coming buys valuable time.
Know what you have. Checking which systems were affected before the details landed meant we could act immediately.
Layer your protection. Mitigations plus fallbacks, so one failure doesn't leave you exposed.
Make the cautious call when it's right. Sometimes the safest option is to take a service offline briefly.
Keep people informed. Clear answers turn a worrying headline into reassurance.

Is your website or server up to date?

If you're not sure whether your website, hosting or servers are protected against recent vulnerabilities, talk to us. We host websites, servers and recovery environments on our own platform, and we're happy to take a look at what you have today.