It was PHP this time

If you look after a website, there's a fair chance someone asked you in the last few weeks whether you were affected by "that PHP thing". Within days of it hitting the news, one of our larger clients had sent us a security questionnaire about it, which is exactly what a well-run organisation should do.

The PHP thing has a name, PHP2Shell, and two CVE numbers to go with it. They are a pair of critical flaws in PHP itself, the programming language behind a very large share of the web, including most WordPress sites. They let an attacker run their own code on a server without logging in first. CISA told everyone to patch immediately, and it later confirmed the flaws were being actively exploited.

Most of our clients' sites run on Umbraco, which is built on Microsoft's .NET rather than PHP, so they weren't affected. We've told the ones who asked exactly that. But it isn't a moment for anyone in the .NET world to be smug, and the reasons why are worth a few minutes of anyone's time, whatever their site runs on.

Attacks started before the fix existed

The detail that stuck with us is the timing. According to Rapid7's write-up, exploitation attempts were seen from 17 October, and the PHP project released its patched versions on 21 October. For four days, the attack was out there and there was nothing to install.

There's not much anyone can do in those four days. What matters is what happens on day five. A site that is on a supported version, with someone whose job it is to apply updates, is patched within hours or days of the fix appearing. A site nobody has looked at since launch might still be unpatched now. Same vulnerability, same fix, very different outcome, and the difference was decided long before October.

End of life means the fix might never come

The patches went out for PHP 8.2, 8.3, 8.4 and 8.5. Rapid7 notes that PHP 8.1 and older no longer receive routine updates. For this incident the PHP team did publish limited backports for 7.4, 8.0 and 8.1, which was generous of them. Anything older than that got nothing.

That is what "end of life" actually means, and it's the bit that tends to get lost. It sounds like an admin label, the sort of thing that matters to developers and nobody else. In practice it means that when the next serious flaw turns up, and there is always a next one, the people who maintain the software are under no obligation to fix your version. Sometimes they help out anyway. You don't want your security to depend on sometimes.

We keep seeing the same pattern with organisations of every size: the site works, nobody wants to spend money on a site that works, and the version underneath quietly drifts out of support. It's completely understandable. It also tends to be the reason that a routine security alert turns into an expensive week.

It could be .NET next time

It would be easy for agencies like ours to treat a PHP incident as a reason to promote why we choose .NET. However, it isn't true that .NET is somehow immune.

A year ago, Microsoft gave an ASP.NET Core flaw, CVE-2025-55315, a severity score of 9.9 out of 10. Microsoft's own .NET security lead called it their highest ever. It was patched, and sites that were on supported versions and got the update promptly were fine. Sound familiar?

No platform is safe because of what it's written in. Sites are safe because they're on a supported version and someone applies the patches. The language changes from one headline to the next. That part doesn't.

It's also worth knowing that .NET has its own end-of-life dates. Microsoft's support for .NET 8 has an end date of 10 November 2026, and Umbraco 13, which runs on it, reaches end of life on 14 December 2026. If your site is on Umbraco 13, now is a much better time to plan the move to Umbraco 17 than mid-December. If you're not sure how Umbraco's support windows work, we've written up the difference between LTS and STS releases and how to know when to update.

Let the platform do the boring bit

The best security patch is the one nobody has to remember to apply. This is one of the main reasons we recommend Umbraco Cloud hosting to most of our clients.

On Umbraco Cloud, patch upgrades are switched on by default. Security fixes for Umbraco are applied automatically in a weekly upgrade window that you choose, and Umbraco can apply critical fixes outside that window if it needs to. When the next big Umbraco security fix lands, a site on Cloud generally has it before most people have finished reading the advisory. The hosting underneath is Umbraco's problem to keep patched, not yours. We've written more about why we think Umbraco Cloud is the best way to host an Umbraco site.

Automatic patching handles the small, frequent updates. Major upgrades, the jump from one version to the next, still need a person to plan and test them, because they can change how things work.

Someone needs to be watching

A managed service is the route many of our clients have chosen as their way to handle this. Ours covers monitoring, security patching and planning for supported versions, and major upgrades are included. In practice it means that when something like PHP2Shell is in the news, you get a clear answer from us about whether it affects you, rather than having to go looking for one, and your site is never the one quietly drifting out of support.

If you're not on it and you're not sure where your site stands, what version it's on, whether it's still supported, or what moving would involve, get in touch. We'll tell you plainly, and if the answer is "you're fine", we'll say that too.

It was PHP this time. It'll be something else next time. The sites that come through it well will be the ones that were kept up to date when nothing was on fire.