Critical PHP security flaw: every client website patched.

In October, two critical vulnerabilities were found in PHP. The story ran well beyond the technology press, and mainstream news carried headlines about websites going offline worldwide. If you saw one of those, the reasonable question is what it meant for your own site.

PHP is the software the majority of the web runs on, including most WordPress websites. You never interact with it directly, but almost everything above it depends on it working correctly.

The flaws allowed code to be run on a server without anyone needing to log in. That is why PHP issued emergency patches rather than waiting for its scheduled release.

Before the patches arrived.

There was a window between the problem becoming public and a fix being available, and that window is the part that matters. During it, protective settings blocking the known methods of attack were in place across every website we look after, ahead of the official fix. We confirmed they were active everywhere rather than assuming it.

Then the patches themselves.

We applied them across every website we look after as soon as they were available, rather than waiting for reports or client requests. That is our standard response when something of this scale is announced.

The outcome.

No site we host was broken into.

We reviewed every one of them afterwards as well, to confirm nothing got in during the window before the patches existed.

For the businesses we work with, from Penrith, Western Sydney and the Blue Mountains to national brands that depend on their websites being online every day, disruption was minimal and nothing was required at their end.

Why we run the stack we do.

Websites can be hosted cheaply. We do not host them cheaply, and weeks like this one are the reason.

The websites we look after run on specialist managed hosting, kept current and hardened by people whose job it is, with layers of protection in front that filter traffic before it reaches a website. Nothing relies on one person noticing something.

That setup earned its keep this week. The protective measures were in place before the official fix existed, and the overwhelming majority of the attack traffic was refused outright.

None of this is visible on an ordinary day, which is exactly what paying for it buys.

Why we are publishing this.

Work of this kind is not visible to clients. A website that continues to function looks much the same whether or not anyone is actively maintaining it, and the difference only becomes apparent when something goes wrong.

We think it is reasonable for clients to understand what is being done on their behalf, particularly when the answer is that a widely reported problem was handled before it affected them.

A question worth asking.

If your website is managed by someone else, it is reasonable to ask what they did in response, and how they confirmed your site was unaffected.

A clear answer, in terms you can understand, should be straightforward to obtain.

For the technically inclined: published as PHP2Shell, CVE-2026-109618 and CVE-2026-109619, and fixed in PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12.