PHP2shell: what happened and

If you caught the news this week, you might have seen some fairly alarming headlines. Government websites, university learning platforms and even web hosts taking themselves offline, all because of a flaw in something called PHP. Plenty of our clients saw it too, and fair enough, the first question was “is my website OK?”

Short answer: yes. Here is the longer one, including what actually happened, what we did at our end while the rest of the internet scrambled, and why this week is a really good illustration of what you are paying a host for.

First up, what is PHP?

PHP is the programming language that runs on the server behind your website. When someone visits a page, PHP is what pulls the content out of the database, builds the page and hands it to their browser. The easiest way to think about it: if your website is a car, PHP is the engine under the bonnet. You never see it, but nothing moves without it.

It is also everywhere. PHP powers an estimated seven in ten websites, including every WordPress site on the planet (which means every site we build) and Wikipedia. So when something goes wrong with PHP itself, it is not one website with a problem. It is a big slice of the internet at once.

So what went wrong?

On Wednesday the PHP team issued a security alert about two critical vulnerabilities, now nicknamed “PHP2shell” (officially CVE-2026-109618 and CVE-2026-109619). In very plain terms: by making PHP run out of memory at exactly the wrong moment, an attacker could leave behind scraps of half-finished data that the next visitor’s request would trust. Under the right conditions, that lets the attacker run their own code on the server without ever logging in.

That is about as serious as a website flaw gets. Running code on a server means someone could pull customer data out of the database, plant malware, or quietly use the site to attack other people. And because it lives in PHP itself, keeping WordPress and your plugins up to date would not have saved you on its own. The fix had to happen at the server level.

A couple of details make this one a bit different from your usual security story. The bug appears to have been sitting in PHP since around 2012. It was confirmed by a US security firm using AI models to test an attack researchers had only theorised about, which is exactly the trend we wrote about in AI-assisted cyber attacks are moving faster. And Amazon Web Services says it saw someone trying to exploit it as early as 17 October, days before it was made public. The bad guys were not waiting for the announcement.

Why some big names went dark

The response from the security world was swift. Australia’s cyber security agency, the Australian Signals Directorate, put out a rare critical alert aimed at everyone from government to families. The UK’s National Cyber Security Centre told organisations to patch immediately, and if they could not patch or apply the temporary workaround quickly enough, to consider taking their systems offline until they could.

Plenty did exactly that. The ABC reported that GovCMS, which hosts many Australian government websites, blocked direct access to its servers. Moodle, the platform behind a huge number of school and university learning portals, took its site offline as a precaution. At least one Australian hosting provider restricted file uploads on customer sites, warning that forms with attachments might fail.

To be clear, pulling the plug is a perfectly sensible call when you cannot patch fast enough. But it is also what it looks like when the fix is not ready and you have no other way to protect the people using your site.

What we did at our end

We were onto it straight away. At midday on Wednesday, before an official fix was available from PHP, a protective measure went on across our whole hosting network to close off the weak spot. That meant every site we host was shielded during the most dangerous window, the gap between the world finding out about a flaw and the patch actually existing.

Then at 10pm that night, Perth time, the PHP team released the official fix. It was rolled out across every one of our servers within minutes. No waiting for business hours, no queue of tickets, no site-by-site manual upgrades over the following week.

This is exactly why we run one maintenance process across our whole fleet, with no exceptions. Security fixes go out the day they land, on every site, whether it is a two-page brochure site or a busy online shop. When something like this hits, there is no list of “special” sites stuck on an old setup that someone has to remember to come back to.

What we told our clients

By Thursday morning the headlines were everywhere, so we emailed every one of our hosting clients. We would much rather you hear it from us than lie awake after the evening news wondering about your own website. Here is the gist of what went out:

That last point matters. We checked that every site was up and running afterwards, but you know your own website better than anyone. A server-level upgrade of this size is exactly the moment to try your contact form or put a test booking through, and if anything does not behave, we jump on it.

Why the host behind your website matters

Most business owners never think about PHP, and honestly, they should not have to. But this week shows that your website’s safety does not just depend on your website. It depends on whoever runs the server underneath it, and on how fast they move when something like this lands.

We have written before about cheap hosting vs premium hosting, and the point we keep coming back to is that the difference is invisible right up until the day you need it. This was one of those days. Here is what a good host actually did this week:

Point three deserves a bit more attention. The NCSC specifically urged anyone on an older version of PHP to move to a supported one, because unsupported versions do not get security fixes at all. Budget hosting is full of websites still running versions of PHP that stopped receiving updates years ago, often because nobody wants to deal with whatever breaks when they upgrade. For those sites, there may be no patch coming. The only way out is an upgrade under pressure, in the middle of a live security incident, which is about the worst time to be doing it.

The other quiet difference is people. A cheap host might eventually patch its servers, but it will not email you, check your site came back up, or ask you to test your booking form. That is not hosting, strictly speaking. It is someone looking after you.

What should you do now?

Weeks like this are a good reminder that a website is not a set-and-forget thing. There is a whole engine room underneath it, and you want someone in there who is paying attention. If you are not sure who is looking after yours, or you did not hear a peep from your host this week, get in touch. We are always happy to take a look.