Yesterday was the most intense cybersecurity day I’ve ever been involved in at Hop Studios.
Two security bugs were announced in the PHP programming language: CVE-2026-109618 and CVE-2026-109619, collectively called PHP2Shell.
If you’re not a web developer, that may not sound so bad—bugs happen all the time, right? But when we heard about this at Hop Studios, we immediately understood that we had a crisis on our hands—and a long day ahead of us.
Why It Was Bad
PHP is a programming language that’s used to build more than half the sites on the internet. PHP is an open source project—it’s free and built by volunteers. And these were not just bugs introduced in the latest version—these bugs were present in versions of PHP going back to 5.4 released 14 years ago. So suddenly, a LOT of sites were revealed to be vulnerable.
And these particular PHP bugs were incredibly severe (9.2/10 on the CVSS scale). They allowed remote execution of arbitrary commands—basically, under the right conditions, an attacker could send a specially crafted request to a vulnerable PHP website and trick the server into executing commands on their behalf. A web server can usually do a lot of things—create and delete files, expose and change data, make connections to other servers…. not good!
These bugs were identified by AI models in mid August (“The underlying flaws had been present for decades, but demonstrating their exploitability required an exceptionally complex chain of steps, at the edge of what human researchers could practically achieve,”), and the PHP community was working on fixes for weeks, but the bugs were made public two days before the planned disclosure date and suddenly it was like someone kicked the anthill that all web developers had been building for years.
How We Reacted
At Hop Studios, we have clients on a broad range of web hosts and servers. Our duty to each client is to keep their sites safe and secure, especially at times of high risk, even without that client knowing to ask.
First: Inventory and Contact
Our first step was to inventory all the clients who could be affected, and where those sites were hosted. There wasn’t one button we could press to fix everything. We have a lot of clients at a lot of hosts running a lot of different CMSs:
- Nexcess.net / LiquidWeb
- Berkeley Unix hosting
- Green Geeks
- Forge / Digital Ocean
- Fullhost
- WP Engine
- Wordpress.com
- GoDaddy
- Wix
- Squarespace
- Pantheon
- Self-hosted by the client
Next, we identified the PHP version running each site, and whether the hosting was managed or unmanaged.
For managed hosting we checked that company’s current status or contacted their support directly if it was unclear. Of those who are on managed, some of the companies had patches in place within hours of the leak of the vulnerability. Others took most of the day, and two took until the next day.
At this point, we contacted clients by Basecamp, email or phone to fill them in and get their immediate input and permission.
For unmanaged hosting, we did the patching ourselves—always a little worrisome, but at least we had quick and direct control over the situation.
Next: Patch It or Pull It
When hosting providers couldn’t patch vulnerable servers within an hour or two, we disabled their sites for the interregnum, after making sure they were okay with that step. We did this for two reasons:
1) Because a few hours offline is far better than digging a site out of a security breach (and that’s not even considering the reputational, financial and legal costs)
2) Because until a site is patched, you don’t know for sure how long the patch will take, and you shouldn’t just hope for the best—prepare for the worst, and bring the site back up as soon as it’s safe to do so.
To take the site down, in most cases we disabled PHP using .htaccess, and then put an HTML page in the root of the site in place of the index.php file.
A few of our clients (despite our recommendations) were running an older version of their CMS that would not run with on more recent versions of PHP. That meant we couldn’t rely on upgrading them only in the official PHP patched version lines, 8.2, 8.3, 8.4 & 8.5. We also needed to secure PHP 8.1, and 7.2, and 7.4.
We initially thought we might have to make several emergency upgrades to EE, a risky and time-consuming task. However, several unofficial patches were released for older versions, developed by trusted open-source code maintainers. That meant there was less pressure to upgrade than we feared.
It also reinforced with us, and hopefully some clients, why it’s important to be running a recent version—of all your site software—at every level of the tech stack.
For Some: Mitigate and Wait
We also have many clients whose sites are set up behind Cloudflare, which was great in this crisis. For those, we left their sites up even if the patches were taking a while. That’s because Cloudflare could block some forms of the attack, and we adjusted PHP settings to reduce the exposure further (while losing a few bits of site functionality).
These were temporary mitigations, not ideal solutions, and we did try to convince clients to take their sites down.
Because if your site is small, simple and data-light enough for the bug not to be much of a worry to you (and remember, automated attacks make every site equally at risk), it’s probably also fine for that site to be down for half a day.
Whereas if your site is so large and busy that you can’t afford to be down for that long, then you’re probably also a valuable target, too, and you should batten down the hatches.
Throughout the day, we reached out to all clients that were affected to explain in clear terms what the situation was and what their options were. Often we’ll send a message about an internet concern to all our clients, but in this exceptional case, we chose not to contact those who were not affected—we wanted to focus all our attention on the clients who needed immediate help.
Today, all our active client’s sites are stable and secure, and we’ve been able to put back online all the ones that we took offline. Not bad for a day’s work.
EE Shows Their True Colors
Finally, one big shout-out to the ExpressionEngine team, who did an absolutely wonderful job in several ways:
- Posting about the vulnerability in Slack very early and saying they would be available all day to answer questions and help.
Meanwhile, Magento, Joomla, Contao, and Typo3 didn’t post anything; Wordpress had a short note about the issue, and Bitrix and Craft CMS posted about patching their hosting. Silverstripe CMS and PyroCMS are actually offline at the moment—perhaps unrelated but not good! (Drupal made an interesting and useful post about how to investigate if your site was hacked before the patch was applied.) - Informing the EE community about the situation and the steps to take in clear, detailed terms via their blog.
- Today, they offered a large discount ($100!) off the upgrade license fee for EE 7, knowing that a lot of clients would need to upgrade and wanting to make that less of a burden.
How the folks at EE handled it, to me it’s the behavior you want to see from a great community, where the default is helping each other in a time of need rather than looking for a windfall.
