PHP's Emergency: When Someone Else's Code Becomes Your Invoice

A patch nobody put in the diary

At 14:00 UTC this afternoon, the PHP security team shipped an emergency release. Two vulnerabilities, both rated CVSS v4.0 9.2, which is about as bad as a score gets before the word "catastrophic" starts appearing in trade press.

The PHP team gave roughly a day's notice. Their advisory, posted yesterday, was unusually blunt: all PHP users were encouraged to prepare now so they could update the moment the fix was available.

Then it got worse. The two CVE identifiers, 2026-109618 and 2026-109619, leaked publicly before the patch existed. Security researchers confirmed the flaws were real. Proof-of-concept exploit code began circulating. And Cloudflare's CTO, Dane Knecht, confirmed his network was already seeing early attacks and was updating mitigations as new attack vectors appeared.

So: a critical flaw in the language that powers WordPress, Drupal, Magento, and the overwhelming majority of shared hosting, attacked in the wild, before most site owners had finished their lunch.

Why this one lands harder than most

About 1.5 million internet-facing hosts openly report a PHP version. Roughly 59 per cent of them are running PHP 8.1 or older, branches that no longer receive official security fixes at all.

Read that again. For most of the affected web, there is no patch to apply. There is only a migration project, quoted at short notice, on a Wednesday afternoon.

CERT-EU has told organisations to patch immediately or isolate internet-facing PHP applications where they cannot. Cloudflare pushed protective firewall rules to all customers, including free accounts, which buys time but is not a fix. Attackers routinely find ways around early filters.

The part your accountant notices

Here is how this plays out for a small business on a typical WordPress site.

Someone, hopefully your host and not a customer, notices. You call your developer, who is already dealing with eleven other clients in exactly the same position. You go on a list. Out-of-hours rates may apply. If your site is on an older PHP branch, the "quick patch" becomes a compatibility audit, a plugin review, and a staging environment nobody budgeted for.

And this was not your fault. You did not write PHP. You did not choose the vulnerability. You simply own a website, and today ownership came with a bill you could not have forecast, for work you cannot evaluate, at a price you have no way to benchmark.

That unpredictability is the real cost. Not the invoice itself, but never knowing when the next one arrives.

Where Aliora clients were this afternoon

Working. Ignoring it, mostly.

Sites we build run on Sanity, a headless content platform. Your content lives in a managed cloud, served through an API. The site visitors see is built from that content and delivered as static files over a global CDN. There is no PHP runtime sitting on a server waiting for a crafted request. There is no plugin estate, no theme layer, no shared hosting panel, and no admin login exposed at a predictable address.

A critical PHP remote code execution flaw is, for our clients, somebody else's news story.

We should be honest: no stack is immune to everything. Modern platforms have their own dependencies and their own advisories. The difference is twofold. First, the attack surface is dramatically smaller, because the thing serving your pages is a file, not a program interpreting requests. Second, when something does need attention, it is our job, included, already paid for.

Managed means managed

Aliora Digital Managed Services starts at £150 a month. That covers hosting, security, monitoring, updates, and a pot of hours for the changes you actually want to make.

What it does not include is a phone call on a Wednesday afternoon explaining that something you have never heard of has put your website at risk, followed by a quote.

You get one predictable number, every month. We absorb the days like today, because absorbing days like today is the service.

If you are not with us, do this now

1. Find out which PHP version your site runs. Your host can tell you, or your developer can.
2. If it is 8.1 or older, you are on an unsupported branch. Treat that as urgent, not as a future project.
3. Apply the official PHP release as soon as your host makes it available. Hours, not days.
4. If your site sits behind Cloudflare, the initial protective rules are already live. Use the breathing room, do not mistake it for safety.
5. Check for PHP files created or modified in the last few days, particularly in upload and cache directories.

Then, when the dust settles, ask a different question. Not "how do we patch this faster next time," but "why is my business exposed to this category of problem at all?"

We would be glad to answer it.