Nearly every website in the world sits on top of a handful of programs you never see. PHP is one of them. If your site runs WordPress, WooCommerce, Shopify’s older setups, Magento, Laravel, or almost any site with a contact form and a database behind it, PHP is doing the work between the visitor’s click and the page that comes back.
On 21 October 2026 that program was patched for two serious faults. This is what that means for you, in the order it matters.
What actually happened
Two separate bugs were found in PHP itself - not in WordPress, not in a plugin, not in anything your developer wrote. They were published together and nicknamed php2shell. Both carry a severity score of 9.2 out of 10, which is about as high as these ratings go.
The part that makes them serious is the phrase without logging in. Most website break-ins need something first: a weak password, an account, a form to abuse. These do not. A request sent to a vulnerable server can end with the attacker running their own commands on it, as the website itself.
Both the United States’ cyber security agency and the UK’s National Cyber Security Centre told organisations to update immediately. Attacks using it were seen within hours of publication, including from bots that simply sweep the whole internet looking for servers that have not been updated yet.
Why this is not something you did wrong
If you are on shared hosting - and most small business websites are - you do not choose which build of PHP your server runs. Your host does. You could have a perfectly maintained website, every plugin current, a long password on everything, and still be exposed, because the hole is underneath all of that.
That cuts both ways. It is not your fault, and it is also not something you can fix on your own. What you can do is find out where you stand and ask the right person to act.
How to check your own site in two minutes
There are three ways, and you only need one of them to work.
- Your hosting control panel. Nearly every host has a PHP settings page - it may be called PHP Configuration, PHP Selector, or MultiPHP Manager. The version in use is shown there, usually as a dropdown you can change.
- Our free website audit. Put your address into the free check and it reads the version your server announces, compares it against the fixed releases above, and tells you in plain words whether you are behind. It takes about twenty seconds and asks nothing of your hosting login.
- Ask your host outright. One message: "which version of PHP is my account running, and is it patched against php2shell?" A good host answers that in a sentence.
phpinfo() and open it in your browser. It works, but it publishes a detailed map of your server to anyone who finds the file - and people scan for exactly that. If you ever do it, delete the file the minute you have your answer. The two methods above tell you the same thing without leaving anything behind.What to do if you are behind
If your control panel offers a newer version, switching is usually one dropdown and a save. Stay on the same line where you can - if you are on 8.3.35, move to 8.3.36 rather than jumping to 8.4, because a bigger jump can break older code and you want this change to be boring.
If the patched version is not offered yet, your host has not built it. Send them this:
Naming the two reference numbers matters. It moves your message from the pile marked "customer is worried about something" to the pile marked "customer is asking about the thing we are already working on", and you will get a straight answer faster.
The step almost everyone forgets
Updating the files is not the end of it. The program that is already running does not change when the files on disk do - it keeps running the old code until it is restarted. On a shared host that restart is the host’s job, and it usually happens as part of the update, but it is worth one line in your message: "please confirm the PHP workers were restarted after the update."
A site that shows a patched version number but was never restarted is still running the vulnerable code. It is the single most common way an update gets reported as done when it is not.
What does not help, however often it is suggested
When something like this is in the news, the usual advice gets repeated whether it applies or not. For this particular problem, none of the following changes anything:
- Updating WordPress, your theme and your plugins. Worth doing on any ordinary week. It does nothing here - the fault is below your website, in the program that runs it.
- Changing your passwords. Nothing was guessed. No login was involved.
- A security plugin or a firewall in front of the site. These filter requests to your website. This problem is in the engine that handles the request in the first place.
- Taking the site offline for a few days. It buys nothing except lost enquiries, unless your host has told you specifically that you have been compromised.
The only thing that closes it is a newer PHP. Everything else is motion.
If your site was exposed for a while
Most sites will be fine. The published attack code works reliably only against particular combinations of server and version, and the window between publication and most hosts patching was short. But the flaw can also leak fragments of the server’s memory, and anything that was in memory at the time can be in those fragments - session tokens, keys for whatever your site connects to, the password your contact form uses to send email.
So if your host confirms your server was unpatched and reachable for any length of time, treat those as spent and change them. Not because something certainly happened, but because they are cheap to replace and expensive to be wrong about.
And if any of this is more than you want to deal with, that is reasonable - it is what a care plan is for. Somebody watches the version numbers so the first you hear of it is that it has already been handled.