If you run a website, there is a good chance it is built on PHP, whether you know it or not. WordPress runs on PHP. So do most of the shopping carts, booking systems and membership sites that sit behind a business’s homepage. This week, two flaws were found in PHP itself, serious enough that CISA issued an alert and security teams everywhere spent their Wednesday patching servers instead of doing whatever they had planned.
Here is what actually happened, and what you need to check.
What was found
Researchers found two flaws in the core PHP software, not in WordPress, not in a plugin, not in any particular website. They are being called PHP2Shell, and they are rated 9.2 out of 10 for severity, which is about as bad as these ratings get.
Both let an attacker run their own code on a server without logging in first. No password to guess, no account to compromise. One is a fault in how PHP handles memory when it runs out of room. The other is in the part of PHP that tracks file upload progress, and it can let a later visitor’s request reuse memory that still holds data from someone else’s, including passwords, API keys and session tokens that have nothing to do with them.
This is not a theoretical risk sitting in a research paper. Within hours of the fix going public on 21 October, security firms including Cloudflare and watchTowr reported live exploitation attempts. Amazon says it caught an attempt against one of its own honeypots four days before the public disclosure, which suggests someone had this before the rest of us did.
Why “my site is up to date” might not be enough
This is the bit that catches people out. The flaw sits in the PHP engine that runs underneath your site, not in WordPress, Shopify’s PHP-based tools, or whatever plugins you have installed. Keeping WordPress and its plugins updated is still worth doing, but it will not touch this particular problem. The fix has to happen at server level, in PHP itself, and then the server needs restarting so the fix actually takes effect.
That is also why this touches so many different setups: PHP-FPM, Apache with mod_php, php-cgi, LiteSpeed, FrankenPHP. If your host runs PHP to serve your pages, in whatever configuration, you are in scope. Sites running the older mod_php style of setup are worst affected, since a single unauthenticated request there can trigger the problem before your own code even runs. The flaws reach all the way back to PHP 5.4, so age is no protection either.
What to do about it
- Find out which PHP version your site is running, and whether your host has already applied the fix. Your host or developer should be able to tell you this in a sentence.
- The patched versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. If you are on an older branch that PHP no longer officially supports (8.1 or earlier), ask your host what they are doing about it. Some limited backports exist, but you should not assume one has reached you without checking.
- After the update is applied, the server needs restarting. An update that is installed but not restarted is not actually protecting you yet.
- If you manage your own server and cannot patch immediately, there are interim steps your developer can take, such as disabling session upload progress tracking and tightening request size limits at the proxy. These reduce the risk without removing it, so treat them as a stopgap, not a fix.
Signs something already went wrong
Patching closes the door, but it is worth a quick look for signs it was already open. None of these prove anything on their own, but together they are worth flagging to whoever manages your hosting:
- A run of HTTP 500 errors around the same time, with no obvious cause on your end.
- Unusually large or malformed multipart form submissions in your server logs.
- Session cookies (PHPSESSID) that are much longer than usual.
- Worker processes or your PHP service restarting without you having touched anything.
If you see more than one of these together in the days around 21 October, it is worth asking your host or developer to take a closer look rather than assuming it was a blip.
Frequently asked questions
Does this affect my WordPress site specifically?
Not WordPress as such, no. The flaw is in the PHP engine that WordPress (and almost everything else on the web) runs on top of. A WordPress site is affected because it runs on PHP, not because of anything WordPress itself has done wrong.
How do I find out what PHP version my site is on?
Your host or developer can tell you in a sentence, and most hosting control panels show it on the main dashboard. If you manage WordPress yourself, it is also listed under Tools, then Site Health, then Info.
Is patching PHP the same as updating my plugins?
No, and this is the mix-up that matters most here. Plugin and WordPress core updates happen inside the application. This fix has to happen one level down, in the PHP software the server runs underneath the application, and the server then needs restarting.
What if my host has not patched yet?
Ask them directly and ask for a date. A reputable host should already be aware of PHP2Shell, since it has been covered by CISA and every major security outlet this week. If you get a vague answer, that is itself worth acting on.
Could this already have affected my site without me knowing?
It is possible, though not likely for most small business sites, since the exploitation activity seen so far has mostly targeted high-value, high-traffic targets. The signs to check for are above. If in doubt, ask whoever manages your hosting to look at the logs rather than guessing.
If you are on our Maintenance & Support plan, this is precisely the kind of issue it exists to catch, server-level updates included, not just the visible parts of your site.
If you are not sure whether your hosting is covered, or you look after your own server and want a second opinion on whether the fix has actually landed, get in touch and we will check it for you.
