Yesterday the PHP team shipped emergency fixes for two critical security holes, and within a few hours a loud slice of the WordPress community decided that managed WordPress hosting is a scam. Sites hadn’t been hacked, and nobody had lost data. The crime was that nobody got an email fast enough.
I watched it unfold on X all afternoon. One post summed up the mood: someone with sites across WP Engine, Automattic, GoDaddy, Liquid Web and others said they hadn’t heard a word from any of them, and their verdict was that “managed WordPress” is BS. If you want to see the rest for yourself, go to your host’s profile on X, click over to the Replies tab, and scroll. You’ll see the chaos.
I understand the frustration. But I think we owe our hosts a break, and I want to explain why.
First, Let’s Be Honest About How Serious This Was
I’m not going to pretend this was a minor patch. The PHP project released 8.5.12, 8.4.27, 8.3.36, and 8.2.35 to fix two vulnerabilities that, under the right conditions, let an unauthenticated attacker run code on a server. Both bugs live in memory management and error handling, the parts of PHP that nearly every request touches. If you run PHP, you update. Full stop.
So yes, the urgency was real, and nobody should have shrugged it off. But urgency is exactly why the outrage was aimed at the wrong target. When the stakes are that high, the people you want working the problem are engineers, not social media managers.
The Timeline Changed Under Everyone’s Feet
Here’s the part most of the angry posts skipped. The PHP Foundation published the full story of how this release came together, and it was not a clean, calm rollout.
The plan was a coordinated release on Thursday, October 22. Then on Tuesday afternoon, the CVE IDs leaked onto forums and social media with the wrong release time and an inflated severity score of 10.0, when the real score was 9.2. So PHP pulled the release forward by a full day, to Wednesday morning, while distributors were still packaging the fix.
Think about what that means for a managed WordPress hosting team. You had a schedule and a test plan. Overnight, you lost a day of it while the internet filled up with bad numbers and worse rumors.
And then it got messier. Early Wednesday, more than six hours before the coordinated release, Chainguard broke the embargo and published patched images. The Foundation pointed out that this let anyone study the fix while every other PHP user was still waiting.
That’s what speaking before everyone is ready looks like. It doesn’t make anybody safer. It hands the other side a head start.
What Managed WordPress Hosting Owes You in a Crisis
WP Engine did reply to the thread. Their answer was that their security teams were actively monitoring the situation and putting mitigations in place, and that customers should watch the status page for updates.
That’s a perfectly reasonable answer. And it changed nothing, because the thread wasn’t really asking for information. It was asking for reassurance, and no amount of tweeting was going to deliver it. All it did was pull attention away from the problem everyone was supposed to be fixing.
Think about what a host is actually doing on a day like yesterday. They’re rebuilding PHP across thousands of servers, testing that the new builds don’t break the long tail of plugins their customers run, applying stopgap configuration changes where a patch isn’t ready, and watching logs for anyone trying the exploit. Every person pulled into drafting a reply on X is a person not doing that work.
Managed WordPress hosting owes you a patched server. It does not owe you a play-by-play.
The One Complaint That Was Fair
I’ll give the critics one point, because it’s a real one. Plenty of managed WordPress hosting companies now put an AI chat assistant on the front line of support, and several people said theirs had no idea anything was happening. Some got outdated advice, some got flatly wrong advice, and a few of them spiraled from there.
That’s a genuine failure, and it’s the kind of thing I’ve been writing about for months. If an AI assistant answers your customers, it has to know what your status page knows. An AI that confidently answers questions during an active incident without any incident context is worse than no AI at all, because it sounds sure of itself while being wrong.
So hosts, here’s the fix. Wire your support bots to your incident feed, or have them hand off to a human the moment someone mentions a CVE. That’s not a hard problem. It’s a priority problem.
We’ve Done This Before, and Recently
What surprised me most wasn’t the newcomers. It was seasoned WordPress veterans acting like this was the first security event they’d ever lived through, refreshing for reassurance every few minutes.
It wasn’t even the first one this year. In July, wp2shell chained two WordPress core vulnerabilities into unauthenticated remote code execution. We got through it. We patched, we verified, we checked logs, and we moved on.
The playbook hasn’t changed since then. Patch what you control. Verify what you don’t. Communicate when you actually know something. None of those steps involve demanding a press release from your host before lunch.
Silence Is Not the Same as Negligence
Then came the update that should have ended the argument. WordPress.com confirmed that PHP on its platform is patched at the infrastructure level and that its sites were already protected, with nothing for users to do. The same went for every site Automattic hosts.
Go back and read that again. While people were posting that silence proved their host didn’t care, at least one of those hosts had already handled it.
And “radio silence” wasn’t even accurate for some of the hosts in that original post. GoDaddy published guidance on its blog the day before the release, then updated it Wednesday afternoon to say every PHP version on its managed WordPress hosting was patched. The information existed. It just wasn’t in anybody’s mentions.
That’s my whole point. Silence is not negligence. Sometimes it is discipline.
And think about the environment these companies operate in. We live in a world where one badly worded post can turn into a week-long pile-on. During an incident where the release date moved, the leaked numbers were wrong, and an embargo had just been broken, a host that announces “you’re safe” and turns out to be wrong has done real damage. A host that waits until it’s certain has done its job. Can you really blame a company for staying quiet until it’s ready to say something true?
What I Did Yesterday Instead of Refreshing X
I’ll tell you where I landed yesterday, because I posted it while the pile-on was happening.
https://x.com/russellenvy/status/2113019748070183063
That faith wasn’t blind. It came from doing my own part first. I checked whether the patched builds were available on the servers I look after. I went through PHP error logs to see if anything was already throwing errors we’d need to watch once versions changed. I scanned client codebases for anything 8.3.36 might break, and we prepped servers so the switch would be a non-event.
Then came the part that surprised me. A couple of my clients have been sitting on PHP 8.0 for a while, putting off the upgrade because nothing was on fire. PHP only shipped fixed releases for 8.2 through 8.5, so anyone on 8.0 is relying on their host to backport a fix to a version that’s already past end of life. That made the conversation easy. Yesterday did more to explain why they needed to upgrade than any reminder email I’ve ever sent, and it turned into real, billable work.
That’s the difference between reacting to a security event and being ready for one. It’s the same lesson I wrote about in staying steady when everything feels urgent. Panic doesn’t patch anything. Preparation does.
If You Want Better Managed WordPress Hosting, Look Upstream
Here’s the constructive part. If you’re genuinely worried about the next one of these, your energy is better spent upstream than in a host’s mentions.
The PHP Foundation was refreshingly honest in its post. It admitted that an earlier version of this bug stalled for months because a small team couldn’t settle on a fix, and it called that a structural failure. Since then it has added security staff and outside audits, but it says the work still rests on a small group of funded developers. And it asked hosting providers, along with the companies that build on PHP, to sponsor that work.
That’s the real lever. Better PHP security means fewer fire drills for your host, which means fewer fire drills for you.
Your Clients Should Hear It From You, Not From X
Here’s the part that people who run support businesses need to hear. If your clients found out about PHP2Shell from a thread on X before they heard from you, that’s not your host’s fault.
Your host’s job is the server. Your job is the relationship. You’re the one with context on every site, the one who knows which client panics and which one just wants a one-line “you’re covered.” That layer of calm between the infrastructure and the person paying the bill is exactly what clients are paying for.
So give your host a break. They lost a day and kept working anyway. And if you were busy too, doing the work instead of demanding updates about it, your clients probably never knew there was anything to worry about.
Managed WordPress hosting handles the patch. You handle the people. That’s the deal, and it worked yesterday.
Leave a Reply