Calm, on purpose
We first heard at 1pm on a Wednesday: PHP would release fixes for two critical security flaws at 3am the next morning, our time. By evening, rumours of leaked exploits and do-it-yourself fixes were everywhere.
It would have been easy to panic or get sucked into the rumours. Instead, the team assessed the risk that afternoon, contacted partners that evening, and made a plan for the morning. By 10pm we had an incident channel, named with characteristic restraint: #incident-php-big-sad. A few people were up at 3am, when the details landed, to size up how big the job would be. Our partners were understanding and patient throughout, even though we had few details to share at first.
What happened
The PHP security team gave advance notice of two critical vulnerabilities, each scored 9.2 out of 10 for severity, but shared little else. PHP runs around 70% of websites whose server-side language is known, including many of the systems and content management systems our partners rely on. The details, including which versions were affected, only arrived with the fixes at 3am on Thursday, New Zealand time.
What made this one different was how the flaws were found. OpenAI reports that security firm Calif found one of them using an AI model, and Wiz found both independently. The PHP team also published minimal patches for older versions that no longer receive security updates. That was unusual, and it was generous.
How we responded
We started with our register of every site we look after: its PHP version, how PHP is installed, and how it's hosted. That last detail matters more than people expect. A site on a current version with standard packages is a quick update. A site on an older version or a bundled server image is a different job entirely.
Then we ranked the sites by risk. Exposure was only part of it. We also asked what an attacker could reach if they got in, especially personal information, and which compromise would hurt a partner most. That told us who to call first.
Before the fixes were even out, every partner heard from us about their own site. The options depended on their situation:
- take the site offline behind a holding page until the fix was in
- keep it running and review once the details were published
- apply the fix as soon as it was available
- plan an upgrade to a supported version
We were clear about what each option did and didn't protect, then left the decision with the people who own the site. Some took their sites offline overnight as a precaution. A couple of old sites that were no longer needed were switched off for good.
By late that night, it came down to three questions. Were we doing anything now? Were we doing anything at 3am? And what were we going to do with sites on older versions? For sites behind Cloudflare, its emergency protections bought us time, though Cloudflare was clear they were only a stopgap. That let us hold our nerve on the workarounds circulating that night, which turned out to be well off the mark, and wait for the official fix.
The next morning, there was coffee, pastries and chocolate in the office to fuel the push ahead. We gathered at the whiteboard for an incident stand-up, divvied up the work, and used the whiteboard as our dashboard for the rest of the day. Everyone had each other's back. By the end of that day, most of the sites we look after were patched, and the rest had options and costs in front of their owners. We've since seen attempts to exploit these flaws in the wild.
Why this will keep happening
AI is getting good at finding security flaws. OpenAI expects findings like this to "increase sharply in the coming months", and Anthropic has said what it has found so far is "a lower bound" on what's coming. In this case, the people who found the flaws were on the defenders' side. That gave the PHP team time to prepare fixes before anyone else knew.
The catch is that the same tools help attackers too. Once a fix is published, it can show what the original weakness was, and AI makes it faster to turn that into a working attack. The window between "a fix is out" and "people are exploiting it" is getting shorter. That leaves less time to decide what to do about a site that can't simply be updated.
The cost you don't see
Upgrades sometimes get deferred for budget or priority reasons. That's a legitimate trade-off, and we've helped partners make it more than once. But it's one to make knowingly, because the cost of waiting stays invisible until a moment like this.
This time, the PHP team softened the blow by offering a backport for older versions. Even then, applying a patch like that to an older server is skilled, careful work, and it only fixes these two flaws. There's no guarantee of the same help next time, so it's not something to plan around.
The real cost of falling behind isn't the upgrade you put off. It's having fewer good options, and less time to choose, on the day something like this lands.
Why we do this
We're really proud of how the team handled this: calmly, carefully, and looking out for each other and our partners. That calm came from groundwork done long before the news broke.
Since then, partners have told us how much they appreciated hearing from us quickly, with clear options for their own site. That's how we want to show up for the people we work with, and hearing it echoed back means a lot.
Events like this will happen more often. When they do, the sites that fare best will be the ones that are known, kept current, and looked after by people who care what happens to them. That's what managed services is for, and it's why we'll keep being there for our partners when the next one lands.
If you're not sure which versions of the languages, frameworks and other software your site relies on, or whether they're still supported, now's a good time to find out. If you'd like a hand working that out, get in touch.
