You may have seen PHP2Shell in the news this week. It’s one of the most serious web security issues in years, and it didn’t affect a single plugin or website platform. It affected an entire programming language, one that sits underneath most of the websites on the internet.
We wanted to explain what happened in plain English, how we protected our clients’ sites, and why it’s a good reminder of the value of ongoing maintenance.
First, what is PHP?
PHP is a programming language that runs on web servers. When someone visits your website, PHP is the engine that builds the page: it fetches your content, runs your contact forms, processes your shop’s orders, and sends the finished page to the visitor’s browser.
Think of your website as a house:
- Your content is the furniture and decoration
- WordPress, your theme and plugins are the rooms and fittings
- PHP is the foundations everything sits on
- The server is the plot of land it’s built on
And PHP is everywhere. According to W3Techs, it’s used by around 69% of all websites where the server-side language can be identified. WordPress alone, which is built on PHP, powers more than 40% of all websites.
It’s also behind some very big names. Wikipedia and Etsy run on PHP. Facebook and Slack were both built on PHP originally, before moving to Hack, a language Facebook developed from PHP to cope with its enormous scale.
What was PHP2Shell?
PHP2Shell is the nickname for two security flaws found in PHP itself (officially CVE-2026-109618 and CVE-2026-109619). Both were rated 9.2 out of 10 for severity, which puts them firmly in the “critical” category.
In simple terms, the flaws could let a stranger send a specially crafted request to a website and run their own code on the server, without needing a password. That’s the digital equivalent of finding a way under the foundations of the house, rather than picking the lock on the front door.
A few things made it unusual:
- It was in the base coding language, not the website. This wasn’t a WordPress bug or a dodgy plugin. It sat underneath all of that, so updating WordPress couldn’t fix it. The fix had to happen on the server.
- It had been there for a very long time. The researchers at Wiz who found it say the underlying flaws had existed for decades, across many versions of PHP going back to the PHP 5 era.
- The details leaked early. Information about the flaws appeared online on 20 October, a day before the official fix was ready. The PHP team brought its release forward and published the fixes on 21 October.
Words you might hear
- Vulnerability: a weakness in software that could be misused
- CVE: a reference number given to publicly known security flaws, so everyone’s talking about the same thing
- Patch: a fix for a vulnerability
- Remote code execution: when an attacker can run their own commands on someone else’s server from anywhere in the world
How we protected our clients’ sites
Good security isn’t one lock on the door. It’s several layers, so that if one is tested, the others are still there. That’s exactly how we protected our clients’ sites.
1. Cloudflare: protection before the fix existed
Many of our clients’ sites sit behind Cloudflare, a service that filters traffic before it ever reaches the server. Cloudflare switched on protection against PHP2Shell in the early hours of 21 October, before PHP had even released its fix, and reported blocking attack attempts that same morning. For sites behind Cloudflare, malicious requests were being stopped at the gate.
2. Imunify360: security on the server itself
Our Apache servers run Imunify360, a security system that watches for and blocks attacks at server level, including a web application firewall that was updated with rules for PHP2Shell.
3. Patches for every version of PHP, not just the latest
This is the important one. The official PHP fixes only covered the newest versions (8.2 and above). Older versions are officially “end of life”, which normally means no more fixes.
Imunify released back-ported patches for all previous versions of PHP, and these have been applied to all of our clients’ servers. That means every version of PHP back as far as PHP 5.2 has been updated. Whatever version a client’s site runs on, the hole has been closed.
4. Hosting partners who were ready
Our hosting partners had the patches ready and rolled them out quickly, so there was no waiting around while the fix made its way through the system.
5. Patchstack: an extra layer for Managed Service clients
Clients on our Managed Service and above also benefit from Patchstack, a WordPress security service that monitors plugins, themes and WordPress itself for known vulnerabilities and can block attacks on them automatically, often before an official fix exists.
PHP2Shell was one of the rare cases that sat below WordPress, so Patchstack was clear from the start that the real fix had to come from updating PHP on the server, which is exactly what our hosts and Imunify delivered. Patchstack’s role here was early warning: it raised the alarm on the morning of 21 October and confirmed live attacks hours before the PHP fix was released, helping hosts and agencies like us act fast.
Day to day, though, Patchstack covers the place where most WordPress security issues actually happen: plugins and themes. Big incidents like this one tend to be followed by a wave of opportunistic attacks, so having that layer in place matters even more in the weeks afterwards.
Put simply: the filter at the front, the security on the server and the patch underneath all did their jobs.
Why WordPress is one of the safest places to be
When people hear about a big security issue, it’s natural to wonder whether being on a popular platform makes you a bigger target. In practice, popularity is one of WordPress’s greatest strengths.
Think of it like Windows
WordPress is to websites what Microsoft Windows is to computers. It’s the biggest platform out there, and that makes it a big target: if you’re looking for weaknesses, you go where most of the users are.
But being the biggest also means being the best supported. Just as Windows has Microsoft, antivirus companies and IT teams around the world finding and fixing problems every day, WordPress has a huge network of developers, security specialists and hosts doing the same. When something goes wrong, more people are on it, faster, than on almost any other platform.
Because WordPress and PHP power such a huge share of the web, problems get found, shared and fixed fast. PHP2Shell is a perfect example. Within hours of the details leaking:
- The PHP team brought its release forward
- Cloudflare had protection live for its customers, including free accounts
- Security companies like Imunify had firewall rules and patches out
- Major hosts were publishing updates and rolling out fixes the same day
That speed comes from an enormous support network: the core WordPress security team, thousands of developers, hosting companies, security firms and agencies like us, all watching for issues and acting quickly when one appears. WordPress itself also installs its own security releases automatically, so many fixes reach sites without anyone lifting a finger.
A less popular or custom-built platform might have the same kind of flaw sitting unnoticed for years, with far fewer people ready to respond. With WordPress, you’re never facing these things alone.
Why maintenance matters, especially on older PHP
PHP2Shell shows why websites aren’t “build it and forget it”. The flaw sat in software that most website owners never see and never think about. You can’t spot it from your WordPress dashboard, and a WordPress update couldn’t fix it.
It also highlights the risk of older versions. Every version of PHP has a support window. Once it ends, the PHP team stops releasing security fixes for it. For PHP2Shell, official fixes were only released for PHP 8.2 and newer.
That matters because a lot of the web is still running older versions. According to W3Techs, around 27% of PHP websites are still on PHP 7 and nearly 8% on PHP 5, versions that received no official release for this flaw. Without someone actively looking after the server, those sites can be left exposed.
Regular maintenance means:
- Someone is watching. When something like PHP2Shell happens, it’s dealt with on day one, not when you happen to read about it.
- Your software stays current. WordPress, plugins, themes and PHP are kept up to date, so you benefit from the latest fixes.
- Older sites aren’t left behind. If a site can’t move to a newer PHP version straight away, it can still be protected while we plan the upgrade.
- Problems are caught early. Backups, monitoring and security scans mean that if something does go wrong, it’s spotted and put right quickly.
The cost of maintenance is small compared with the cost of a hacked website: lost sales, damaged trust, cleaning up spam, and the time it takes to get back to normal.
Why Cloudflare matters
Cloudflare sits between your website and the rest of the internet. Every visitor passes through it first, and it filters out suspicious traffic before it reaches your server, a bit like a security guard on the front gate.
PHP2Shell showed exactly why that’s valuable:
- It worked before the fix existed. Cloudflare’s protection was live hours before PHP released its patch, at a time when no server in the world could yet be fully updated.
- It stopped attacks a WordPress plugin couldn’t. This attack happened inside PHP, before WordPress even started running, so security plugins inside WordPress would never have seen it. A filter in front of the server could.
- It buys time. Even when a patch is ready, it takes time to test and roll out. Cloudflare covers that gap.
On top of security, Cloudflare also makes sites faster by serving content from locations close to your visitors. We’ve written more about the benefits in our guide to enterprise website security and speed performance with Cloudflare.
If your site isn’t behind Cloudflare yet, it’s worth a conversation.
The short version
- PHP2Shell was a critical flaw in PHP, the language behind most of the web, including WordPress
- It couldn’t be fixed by updating WordPress; it needed fixing on the server
- For DeType clients, Cloudflare, Imunify360 and back-ported patches for every PHP version back to 5.2 meant it was covered
- Managed Service clients also have Patchstack watching the WordPress layer: plugins, themes and core
- There’s nothing you need to do
- It’s a good reminder of why ongoing maintenance and a firewall in front of your site are worth having
