Listen to the full episode now:
Key Takeaways
- A critical flaw in PHP put most of the web on alert at once. Two remote code execution vulnerabilities let attackers take over vulnerable sites.
- Expect more days like this. AI is helping researchers, and attackers, find old flaws in decades-old software faster than ever.
- Prepared teams mitigate first and patch fast. Firewall rules and server hardening bought time until the patch shipped, then the patching took hours, not weeks.
- Know exactly who patches your site. Ask your host or web partner, in writing, what they handle and what they don’t.
The morning of October 21
A little before 9 a.m. Central on October 21, Workhorse’s CTO, Thomas Bacon, was refreshing a web page. The PHP project had promised a security release at 9. It showed up a few minutes early. Thomas was ready for it.
Plenty of organizations decided not to wait. France took its Interior Ministry websites offline. Finland pulled its public-facing government services. The Netherlands shut down its national government portal, and the Wikimedia Foundation took down many of its services. The US NSA advised organizations to go offline if they couldn’t update right away.
When governments unplug their own websites on purpose, it’s a bad week for the internet. On this episode of Crafting World-Class Websites, Morgan sat down with Thomas to talk through what happened, how Workhorse responded, and what every site owner should take from it.
What happened, in plain English
PHP is the programming language behind 69.2% of websites whose server-side language is known, per W3Techs. WordPress runs on it. So do Drupal, a favorite of governments and nonprofits, and Laravel, which powers a long list of custom web applications.
Researchers found two flaws in PHP itself, now known together as PHP2Shell. Both allow remote code execution, which means exactly what it sounds like: an attacker can run their own code on your server. PHP’s security team rated both 9.2 out of 10. Some researchers scored one of them higher.
The flaws affect PHP versions going back to 5.4, released over a decade ago. The PHP Foundation worked with the researchers on a coordinated release, and patches shipped for supported versions on October 21. Older, end-of-life versions got no official fix at all.
Attackers didn’t wait for the patch either. Amazon’s threat intelligence team spotted an exploitation attempt on October 17, four days early, and CISA added both flaws to its list of known exploited vulnerabilities on October 26.
Why this will happen again
The researchers who found PHP2Shell used AI models in their work, which is worth thinking about.
PHP is open source. Anyone has been able to read its code since 1994, back when the name stood for “Personal Home Page” and the whole project existed so one developer could run his own homepage. Thousands of very smart people have looked at that code since. One of these flaws was even flagged in a 2024 audit and never fixed. It took a new kind of processing power to find the full attack.
The vulnerability had been sitting there for years, and AI helped find it. And attackers have access to the same tools. As Thomas put it, it’s a cat-and-mouse game: attackers find something, defenders harden it, and both sides are now moving faster.
It’s also easy to blame PHP, and a certain segment of developers has been doing that for years. The truth is less satisfying. Similar flaws turn up in other languages, and supply chain attacks, which slip malicious code into the tools teams use to build and manage sites, hit every stack. Most of the internet was built before anyone designed for security first. Email is the classic example, and it’s still a leading way businesses get compromised.
Thomas expects things to settle eventually, the way they always have. In the short to medium term, though, expect more mornings like October 21.
What the day looked like at Workhorse
Workhorse hosts and manages hundreds of websites, so this was a huge deal for our team, Thomas included. As soon as we were notified of the PHP incident, our journey looked like this:
- Mitigate before the patch
We have playbooks for days like this. Before the release, the team confirmed every property we manage had a layer of protection in place, either a Cloudflare firewall rule or a custom rule on the server. Cloudflare had shipped temporary rules to all its customers, but those only cover traffic that actually runs through Cloudflare, so we didn’t stop there. - Patch, then wait on everyone else
Then the patch landed, and so did the rest of the internet. Servers bogged down under the rush to update. And a PHP patch alone doesn’t fix everything, since other systems that bundle PHP have to release their own updates first. - Patch everyone we host
Every site we host got patched, including small sites that haven’t been on a maintenance plan in a long time. Nobody had to ask. - Warn the people we don’t host
For clients who host elsewhere or work with us hourly, we reached out as a courtesy to tell them to raise it with their provider immediately. - Communicate
Triage first, communication second. Postmortems are still going out to clients this week. If you’re a client and haven’t heard from us yet, it’s likely because we already handled it.
AI helped on our side of the fight, too. Workhorse is part of Anthropic’s Cyber Verification Program, which gives vetted security teams access to models built for defensive work. That let us inventory every affected property and assess the impact far faster than we could have by hand.
What separates a prepared team from a scrambling one
Most of the work that made October 21 manageable happened long before October 21. Thomas boils it down to three habits.
- Know your stack cold
Deeply understand the software you build with and how you build with it, so you can tell within minutes what’s affected and what isn’t. - Watch the bulletins
Subscribe to the security alerts for your stack, read every one, and decide quickly whether it calls for action. - Stay in your lane
Workhorse works in a focused set of languages and platforms on purpose. If we managed a single .NET project and a major .NET flaw dropped, we’d be the ones scrambling. So we don’t.
Hands at ten and two, firmly in our lane. It’s less glamorous than saying yes to everything, and it’s the reason we could move fast when it all hits the fan.
“I pay someone for that.” Do you?
If you run marketing for an organization, you shouldn’t have to think about PHP patches. You should know for a fact that someone you pay is handling them. This week is a good one to check: Do you actually have that assurance?
The most common assumption is: “Our host handles security.” Sometimes that’s true. Often it’s partly true. And sometimes it’s flat wrong.
- Raw cloud servers
Put your site on a server at AWS or another cloud provider to save money, and the provider is not patching PHP for you. - Managed hosts
Well-managed WordPress hosts were on top of this one, with server mitigations in place before the patch shipped. Even so, a host usually won’t update your plugins, enforce strong passwords or require two-factor authentication for your site’s users. - Agencies and freelancers
Whoever built your site may or may not be responsible for keeping it patched. It depends entirely on your agreement, and plenty of agreements never say.
Questions to ask your host or web partner this week
- Are you responsible for patching the server and PHP itself?
- What did you do about PHP2Shell, and when did you do it?
- Do you update our CMS core and plugins, and how often?
- Who enforces password and two-factor policies for our site’s users?
- What don’t you handle, so we can plan for it?
For everything on that last list, make a plan and name an owner. If you can’t get straight answers, that’s an answer too.
Know who your good guys are
After the dust settled, Allie from our team told her youngest son about her Wednesday. His verdict: “So you were the good guys fighting the hackers?”
Pretty much. For one week, we got to be superheroes instead of nerds. Thomas’s family, for the record, found the whole thing boring.
The bigger point stands. When the next critical flaw drops, good guys and bad guys will race to the same servers, and they’ll both be using AI to get there. You want to know who’s on your side before that race starts.
Whether Workhorse hosts your site or not, if you have questions about where you stand on PHP2Shell, reach out to us or your project manager. We’ll check whether you’re patched, or tell you exactly what to do next.