The important bit
If we host your WordPress site, it runs on a specialist managed platform behind Cloudflare’s protective network layer. You don’t need to do anything about the PHP vulnerability that has been all over the tech news this week. We have already rolled out interim protections and are moving to the patched PHP versions now that those have been released and checked. Cloudflare has had firewall rules in place since early on Wednesday morning, before the patch was even out. We’re watching both to make sure our websites are safe and secure..
That’s the bit most people want to know, and you can stop reading here if you like.
If you’d rather understand what actually happened and why we’re comfortable saying all that, carry on!
What’s actually happened
On Tuesday 20 October the PHP security team announced an emergency release for the following day, fixing two critical bugs in PHP itself. Not in WordPress, a plugin or theme, but in the language that WordPress (and Drupal, Magento, Joomla, Laravel and a large slice of the web!) runs on. Some of the technical detail leaked online before the official announcement, which is never what anyone wants, and the pair of flaws picked up the nickname PHP2Shell. The patched versions landed on Wednesday 21 October, a little ahead of schedule.
The two bugs are tracked as CVE-2026-109618 and CVE-2026-109619. Both are rated Critical (9.2 out of 10 on the CVSS v4 scale), and in the worst case they let someone run their own code on a web server without logging in to anything. Every version of PHP from 5.4 onwards is affected, so that is more or less every website built in the last decade that hasn’t yet been updated. Researchers reported attackers probing for it before the fix was published.
The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and anything older is end of life and won’t be getting an official fix. All of our websites are on at least PHP 8.2 so will be secure.
We’re not going to tell you this is routine. It isn’t, and it’s one of the more serious things to hit PHP in years. We can though reassure you that the engineers responsible for keeping our sites secure and live were working on it before most of the world had heard of it.
What we’re doing
Your site lives on a specialist managed WordPress platform, and PHP is maintained at platform level rather than something we fiddle with site by site. As things stand we’re aware of the vulnerability, are actively monitoring it, and no action is needed from customers. We’ve already rolled out interim mitigations across the platform and are deploying the patched PHP versions as soon as those are available and validated.
“Interim mitigations” means we weren’t sat waiting for the official fix; there are configuration changes that make these particular bugs much harder to trigger, and those went on while we were waiting on fixes being available.
“Validated” means testing the new PHP builds against our stack before pushing them to live sites, rather than firing an untested release at everyone and hoping. That’s slower by a few hours, but is the right approach to keep sites working safely and securely.
What Cloudflare adds
Cloudflare sits in front of the hosting platform. Every request to your site passes through Cloudflare’s network before it gets anywhere near our servers, and part of what happens on the way through is the web application firewall (WAF) looking at each request and blocking the ones that match known attack patterns.
Early on Wednesday morning, before the PHP patch was out, Cloudflare’s CTO confirmed they were already seeing attempts to exploit these bugs and that WAF rules covering the known attack vectors were live for every customer, including those on the free plan. So from roughly breakfast time on the 21st, a request shaped like one of the published exploits was being turned away, whether or not the server behind it had been patched yet.
Cloudflare themselves describe this as a stopgap, and they’re right to. A firewall rule matches the attacks people know about today; the PHP update closes the hole for good. The point of having both is that one covers the gap while the other is being rolled out. That’s the reason we put Cloudflare in front of every site we host, and this is a week where it earns its place.
What you need to do
On your side, nothing.
You don’t need to log in to WordPress, you don’t need to install a security plugin, and you definitely don’t need to take the site offline. PHP on a managed platform isn’t something you can change from the WordPress dashboard, so there’s no button you’re missing.
On our side, we’re monitoring security updates and Cloudflare’s security notices through the day. If anything on your site needs attention after the update (very occasionally a PHP point release surfaces a plugin that was doing something it shouldn’t), we’ll deal with it and let you know.
The one exception is if you have a website that isn’t hosted and supported by us.
If your website is a legacy site on a shared host, a microsite someone set up years ago, a staging copy on a server nobody thinks about, or you’ve just chosen to run your website elsewhere, those are the ones worth a phone call today. Ask whoever looks after it which PHP version it’s running and when it’s being updated. If nobody can give you a straight answer, that in itself tells you something, and we’re happy to help you look.
Keeping you posted
We’ll update this post when we the patched PHP versions are rolled out completely and we’ll contact anyone whose site needed a follow-up.
If you’ve got a question in the meantime, or you’ve had an email from someone else telling you your site is at risk and you’re not sure whether to believe it, get in touch with us before acting on it.
Scares like this bring out a fair amount of opportunistic spam, phishing and dodgy behaviour so make sure any messages and advice you get are legitimate.
Last updated: 21 October 2026 6.51pm