The Day Websites Went Dark
For one day in October, the safest thing to do with a website was turn it off.
Start with my own shop. That day, MSP Radio took every one of its websites offline. They stayed down until our infrastructure provider and web developers gave the all clear, and they came back with new resiliency built in.
The Verge laid out why that was the advice. Two flaws in PHP, the programming language underneath a huge share of the web, including WordPress, let an attacker run code on the server. They carry a severity score of 9.2 out of 10, and they reach every version back to PHP 5. PHP runs about 70 percent of websites whose server-side language is known. The fix couldn’t arrive through automatic updates. Someone had to install it by hand. So European Union and UK cybersecurity agencies told organizations that couldn’t patch right away to isolate their internet-facing applications or take them offline. Cloudflare changed its firewall rules as a stopgap.
The schedule didn’t hold, either. BleepingComputer reported that the PHP security team had set a release time for the patches, and the vulnerabilities leaked before that planned disclosure. Security firms warned of early exploitation and pushed out temporary blocks while sites waited.
And attackers were already ahead of the calendar. The Verge reports that Amazon’s threat intelligence team saw exploit attempts as early as October 17, days before any patch was released. Cloudflare’s CEO, Matthew Prince, said the company saw thousands of exploit attempts in the ten hours before the flaws were announced, tens of thousands within 45 minutes after, and millions since. Then the attempts started working. On October 24, a researcher’s honeypot recorded a confirmed remote code execution against a server running PHP 8.4.26, one release behind the fix.
In plain terms, for about a day the official advice for a big piece of the web was the same thing we did. Go dark, fix it, then come back.
That advice assumed someone knew which version was running, and where the fix would come from.
The Patch Was Never the Scarce Part
There was no workaround. The only defense was the fix itself, and a fix reaches a server only through a path somebody set up before the flaw existed.
Start with why nothing else worked. The flaws sit in PHP itself, underneath the website. Perforce, which sells long-term PHP support through its Zend business, points to Datadog’s researchers, who reproduced one of the flaws and found that the malicious request never reaches the application’s code. The site’s own login and security can’t stop it. Then VulnCheck built an exploit that gets past ASLR, the memory scrambling that had kept most published exploits from working on real servers. Spencer McIntyre, its director of exploit development, said organizations should patch rather than assume memory protections or configuration changes will stop an attack. Firewall rules buy time. They don’t close the hole.
So the question becomes who delivers the fix. For PHP, there are three answers:
- The PHP project patches the versions it still supports, 8.2 and newer.
- Linux distributions and support vendors, Perforce writes, are the only source of fixes for 8.1 and older. Zend and other vendors shipped those patches the same day.
- For most small businesses, it’s the host. Whoever runs the server applies the update, or doesn’t.
By Perforce’s own estimate, about 40 percent of PHP users run a version the project no longer supports. For them, a fix existed only if someone had already signed up for one of the other paths. Upgrading instead isn’t quick. Moving to a new runtime can mean updating frameworks, libraries and application code, then testing all of it.
In plain terms, the patch was never the scarce part. The arrangement to receive it was, and it had to be in place before October. It works like a vehicle recall. The manufacturer issues the fix, but the notice only reaches owners whose registration is current.
For an MSP, that arrangement usually sits somewhere the contract doesn’t reach.
The Website Outside the Contract
In practice, it shows up as a scope problem.
Most managed agreements are built around what the MSP put in place: the endpoints, Microsoft 365, the firewall, the backup. A client’s website often came from somewhere else. A web designer built it, a marketing agency runs it, or it sits on a hosting plan somebody bought years ago. Where that’s true, the most exposed system a client had on October 21 may have been the one nobody in your shop was watching.
Rupert Goodwins, in a column for The Register, explains why that matters beyond one bad week. The right way to handle a flaw like this, he argues, is to hand fixes privately to trusted organizations first and go public once core services are protected. PHP2Shell broke that, because someone inside the process leaked it. His answer is a trained, trusted patch liaison. He says the quality of that person decides where an organization sits in line for early fixes. A dental office isn’t going to hire that person. The closest thing it has is its MSP, but only for the systems the MSP knows it owns.
This is how it worked for us. We elected to go dark rather than risk an incident, and waited on the all clear from our infrastructure provider and our web development team. In parallel, we implemented a new static failover we can turn on and off on demand, to serve content the next time we decide to go offline. The choice took us down for a day and made us stronger for the future.
So here’s the choice. Inventory every internet-facing system each client depends on, including the website and whoever hosts it. For each one, either take it on, with a named path for its fixes, or exclude it in writing with the risk spelled out. Or keep scope where the contract draws it, and find out about the web developer’s old PHP server from the breach notice.
And whichever you pick, the client should be the one who sees it.
Because most clients learn what your agreement doesn’t cover on the day something outside it breaks. Have that conversation now, with one page: every internet-facing system they depend on, who delivers the fixes for each, and which ones you don’t touch. A client who has signed that page knows who to call before the next advisory lands.
What to Consider
- Name the fix path, not just the system. For each internet-facing system on the page, write down who delivers its fixes: the software project, a Linux distribution or support vendor, or the host. Where the answer is nobody, the software is out of support. The client then has to choose between paying for long-term support and funding the upgrade, and that choice belongs on the page too.
- Put the web developer and the host on the contact list. During PHP2Shell, the people who could declare a site safe were the infrastructure provider and the web team. Before the next one, get their names, find out how they announce fixes, and agree that they’ll tell you when the work is done. Then the client hears one all clear, from you.
- Settle the go-dark decision in advance. Taking a site offline costs the client a day of visibility, and an incident costs far more. Agree with each client on who can make that call. Give them a way to stay visible while dark, like the on-demand static failover MSP Radio built.
If this trend continues: If the next flaw like PHP2Shell arrives in 2027 the way this one did, clients without that signed page will spend its first day finding out who built their website. Clients with it will spend that day waiting on an all clear they already know is coming.