What this week’s internet-wide PHP scramble actually tests
On Tuesday, the people who look after the software plumbing most of the web runs on had a bad day. Two critical flaws were found in PHP, the language that quietly powers something like seven or eight in every ten websites, including a huge chunk of the UK’s SME web estate, council portals and bolted-on customer systems that nobody quite remembers commissioning. Either flaw lets an attacker take over a server without logging in first (Help Net Security has the detail; researchers have nicknamed the pair “PHP2Shell”).
PHP’s own team moved fast. Fixed versions were out within hours of disclosure. Good news, and exactly what you’d expect from a mature open-source project with a lot of eyes on it.
Here’s the bit that should actually interest a board, though, and it has nothing to do with code.
According to Amazon’s threat intelligence team, someone was already probing for this exact vulnerability on 17 October — four days before the fix existed, while the details were still meant to be under embargo. Nobody yet knows how. What we do know is that whoever it was had a head start the rest of the internet didn’t.
And the official advice for anyone who can’t patch immediately, from the NCSC among others, is blunt: take the system offline until you can.
The patch was never the hard part
I’ve sat in enough incident rooms to know that “apply the fix” is rarely where organisations get stuck. Most competent IT teams, in-house or outsourced, can patch a server inside a day once they know what to patch. Where they get stuck is the step before that: deciding whether to pull a live, revenue-generating, customer-facing system offline right now, out of hours, on someone’s say-so.
Ask yourself honestly: if your website or customer portal needed to come down at 11pm on a Saturday to stop an active attack, who in your organisation could actually authorise that, on the spot, without ringing round for sign-off? Is that a named person, reachable, with the authority already agreed — or is it a gap your incident plan has never really tested, because the scenario always said “IT will handle it”?
That’s the lesson PHP2Shell is handing out for free this week, and it’s one a general tech write-up won’t make, because it isn’t a technology problem. It’s a governance one. The organisations that will come through this cleanly aren’t necessarily the ones with the newest kit — they’re the ones where somebody, in advance, worked out exactly who gets to make that call, and tested that the answer still works at 11pm on a Saturday and not just at 11am on a Tuesday.
The second problem: your supplier’s SLA doesn’t cover this
Most businesses don’t run their own servers any more. You’ve outsourced hosting, or your website sits with a developer or agency, and somewhere in that contract is a patching SLA — 72 hours, five working days, next release cycle, whatever you negotiated. Those SLAs are built around the normal rhythm of disclosed vulnerabilities: a flaw is found, responsibly reported, a patch is prepared, everyone updates in good time.
PHP2Shell didn’t follow that rhythm. The exploitation attempt landed before the patch did. If your supplier’s contractual clock only starts ticking on public disclosure, you were exposed for days with no contractual lever to pull faster.
If you don’t already know the answer, it’s worth finding out this week, not during the next one of these: does your hosting or development contract say anything about emergency, pre-disclosure patching — and if it doesn’t, who decides to act anyway?
Three questions worth asking this week
- Do we know, specifically, who has the authority to take a customer-facing system offline out of hours — a named person, not a department?
- Has that authority actually been tested, or does it just exist on paper in a plan nobody has rehearsed since it was written?
- Does our hosting/development contract say anything about emergency patching outside the normal disclosure cycle — and if not, what’s our fallback?
None of this is about PHP specifically. The next one won’t be a PHP flaw. It’ll be something else, on a Friday, and the technical fix will probably arrive quickly. The question, as always, is whether your organisation knows what to do in the hours before it does.
