On Tuesday, October 20, the PHP security team posted an unusual advance notice. A critical security release was coming the next day, addressing two vulnerabilities rated 9.2 out of 10. By Wednesday, the flaws had a nickname, php2shell, and headlines were raising concerns about their potential impact on websites around the world.
Here's what happened, why it matters, and how we responded across the websites we look after. The short version: our hosting infrastructure moved quickly to address the vulnerabilities, additional security protections were in place, and our monitoring found no signs of related exploitation. We're continuing to track the rollout and verification of security updates across our hosting environment. If your website is hosted with us, there's nothing you need to do. We're handling it.
What is php2shell?
PHP is the programming language that powers WordPress. It runs on the server, behind the scenes, so keeping it current is part of managing the hosting environment rather than something you can do from your WordPress dashboard. These vulnerabilities affect PHP itself, not WordPress Core, a plugin, or a theme. Updating WordPress alone won't install the fixes.
The two vulnerabilities, tracked as CVE-2026-109618 and CVE-2026-109619, involve how PHP handles certain errors and internal memory during requests. Under the right conditions, an attacker could potentially exploit them to execute code on a server without logging in. In its official security advisory, PHP confirmed that versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35 contain the fixes and urged users to update immediately. The advisory also emphasized that additional security measures cannot fully replace patching.
The vulnerabilities affect multiple supported PHP versions and potentially a very large number of websites. That's where some of the dramatic headlines came from. But there's an important difference between running a vulnerable PHP version and having a server configuration that an attacker can successfully exploit. Actual exposure depends on several factors, including how PHP is configured and what protections are in place.
How bad was it, really?
Serious enough to require immediate attention, but not every website faced the same level of exposure. A few things from the security community's response are worth knowing:
- Network-level protections helped. Security providers, including Cloudflare, responded with firewall protections designed to identify and block known php2shell attack patterns. These offered an important additional layer of defense while hosting environments prepared and deployed PHP security updates.
- Server configurations made a difference. Security researchers demonstrated that the vulnerabilities could be exploited under certain conditions, while observing differences in behavior across PHP environments. A vulnerability that's difficult to exploit in one configuration may still be dangerous in another.
- Patching remained essential. The PHP security team made clear that firewall rules and configuration changes can reduce exposure to particular attack methods, but updating PHP or installing a confirmed vendor-maintained security patch is the appropriate long-term solution.
So: real vulnerabilities, important security fixes, and a situation where layered security protections helped reduce risk while updates were being deployed.
What happened on our sites
We were aware of Tuesday's advance notice, so the situation was already on our radar when the updates were released Wednesday. Our response focused on the same things we prioritize every day: maintaining protective systems, tracking security updates, and monitoring the websites entrusted to us.
- Firewall protections were already in place. Every website we manage sits behind a web application firewall, with nearly all benefiting from Cloudflare's network. These protections provide an additional defense against known malicious request patterns, including those associated with php2shell, while server-level security updates are being deployed.
- Security updates began rolling out. Our hosting infrastructure began deploying PHP security updates and additional protections on October 21. We monitored that work, reviewed the PHP versions and build information reported by our websites, and continued tracking the deployment of the necessary fixes. We're also following hosting-level confirmations to distinguish between updated PHP releases and vendor-maintained builds that may include backported security fixes.
- Monitoring continued throughout. We monitored our managed websites during the response and found no indications of php2shell exploitation in the information available to our monitoring systems. That doesn't guarantee that every possible threat would be detected, but it's an important part of maintaining visibility across the websites we manage. And that monitoring doesn't stop when the news cycle does.
- We kept clients informed. We shared a plain-English update through our client portals so website owners would know we were aware of the issue and actively managing the response. If your IT department or another vendor raises questions, you'll have something to point them to.
Why does my site still say PHP 8.4.26?
This is a reasonable question, particularly for IT departments reviewing website security, so here's the distinction.
PHP 8.4.27 is the official release containing the fixes for both vulnerabilities. However, some hosting environments use vendor-maintained PHP packages that can receive security updates without immediately changing the version number displayed by WordPress. This is known as backporting, and it's a common practice among operating system and long-term-support vendors.
That doesn't mean every installation reporting PHP 8.4.26 is automatically protected. Neither a version number nor a recent build date, by itself, proves that a particular security fix is present. What matters is whether the PHP service actually handling a website's requests includes the fixes for both vulnerabilities, either through an updated PHP release or a confirmed vendor-maintained patch.
Our hosting infrastructure has been actively responding to these vulnerabilities, and we're continuing to track security updates and patch status across the websites we manage. We're using the information available from our hosting environment, including provider security announcements and patch confirmations, rather than treating a build date alone as proof that a vulnerability has been resolved.
In the meantime, the additional firewall and security protections already in place remain an important part of our defense. They help reduce exposure, but we don't consider them a replacement for applying the appropriate PHP security fixes.
If your IT department needs confirmation for a specific website, the relevant question is whether the PHP service handling that site's requests includes the fixes for CVE-2026-109618 and CVE-2026-109619, and whether the updated service has been restarted where required. Send us that request and we'll review the site's current status and available hosting-level confirmation directly.
What this week says about hosting
Nothing new, which is the point. As we wrote in our security basics piece, most small business websites aren't targeted personally. They're discovered by automated tools scanning for whatever vulnerability happens to be making headlines. This week, the flaws were in PHP itself, and the response was the same as always: layers. A firewall at the edge, timely security updates, and somebody actually paying attention.
That's the quiet part of managed hosting. Most weeks, you never hear about it. This week you did, because we'd rather explain what's happening than have you learn about php2shell from a vendor's scary email.
Glitch had a busy week. He got nowhere.
