PHP2Shell: 48 hours of 'fun'

My turn to jump on the PHP exploit post train. Choo choo.

Wednesday 21 October was a wild day for us. Two critical holes in PHP itself went public, every PHP site on the internet was suddenly a target. We got all our clients protected the same day and fully patched as soon as the packages existed.

This is a quick write-up of how it went, which of our hosting partners made life easy, and which made us wait. Partly for our clients, partly because it might be useful to anyone else who had the same week.

What actually happened

The bugs have been named PHP2Shell (CVE-2026-109618 and CVE-2026-109619). They are two remote code execution flaws in PHP versions 5.4 to 8.5.

The disclosure was meant to be tidy and planned for Thursday 22 October. It didn't go that way. Details leaked on the Tuesday evening, PHP brought the release forward a day, and attackers were already poking at it before the fixes were out.

Fortunately, a day or so later it became clear the public exploits need specific conditions on the server and don't work against a default PHP install. Servers running Apache with mod_php are the most exposed. So it was serious, but not quite the end of the world it looked like on Wednesday morning. You still have to patch.

How our hosting partners got on

We don't host everything in one place, so this was a good (if stressful) side by side comparison of how different platforms handle a fire like this.

Cloudflare and Upsun: ahead of the game. Both had protection and clear information out early. Cloudflare were already seeing and blocking attack traffic before PHP's release went out. That made our job a lot easier on the sites sitting behind them.

Pantheon: got there in the end. We have a couple of sites on Pantheon. They kept us guessing a little by not sharing much information during the day, which is uncomfortable when you're trying to tell a client whether they're safe. But they sorted it.

AWS: not such a great experience. The WAF mitigation rules were shared on the Wednesday evening, which helped. But updated PHP packages for Amazon Linux weren't available until 5:30am on Thursday. That's a long gap between "here's the fix" and "you can actually install the fix", and it meant leaning on our own mitigations overnight.

What we did

Our priority was simple: get some protection on every site straight away, then patch properly as soon as each platform let us.

We had mitigations in place across all the sites we look after on the Wednesday.

Those mitigations did cause a little inconvenience for some clients. some upload forms were no longer available for example. We'd make the same call again. A bit of short-term friction is a much better outcome than a compromised server.

Once the patched PHP packages landed on each platform, we rolled them out and then relaxed the mitigations.

What we took away from it

A few things stood out.

• A WAF in front of your site buys you time. Sites behind Cloudflare had a layer of protection before anyone could patch anything.
• Communication is part of security. The platforms that told us what they were doing let us tell our clients what was going on.
• Have a plan before you need it. Being able to put mitigations across every site quickly is only possible if you know what you're running, where, and how to change it.

Back to normal (ish)

So, wild day, wild ride, but we got there. All our clients' sites are patched and we're very much enjoying a slightly less manic end to the week.

If you run a PHP site (that includes Drupal and WordPress) and you're not sure whether it's been patched, it's worth checking now. And as always, if you're not sure who to ask, we're happy to help :)

And it you are interested in a totally different approach - check out what we have done with our own site