On October 21, the people who maintain PHP shipped an emergency update. It fixed two critical flaws, which some people are calling “php2shell.” Either one lets an attacker run their own code on a web server, without a password, just by sending it specially crafted requests. In the worst case, the attack lands before WordPress, or whatever your site runs on, even starts.
This isn’t theoretical. Cloudflare saw attack traffic the same day. On October 26, the US Cybersecurity and Infrastructure Security Agency added both flaws to its list of vulnerabilities known to be exploited.
If you have a website, there’s a good chance this touches you. PHP is the language under WordPress, Joomla, Drupal and a great many small-business sites. Krebs on Security put PHP’s share of websites at about 70 percent.
The good news first
The big hosting companies moved fast. Several patched their shared and managed plans within a day. If you pay a host to run WordPress for you, it may well be done already. Check anyway.
So this isn’t a reason to panic. It’s a reason to spend ten minutes making sure, because “my host handles it” is true right up until it isn’t.
When “my host patched it” isn’t the whole answer
You run your own server. If you have a VPS or a cloud server, the host usually patches the machine you rent, not the PHP you installed on it. GoDaddy and Hostinger both said so plainly. On a VPS, updating PHP is your job, or your web person’s.
Your site runs an old version of PHP. PHP 8.1 and older no longer get regular fixes from the PHP project. Many hosting panels still let you pick an old version, and a site set to one years ago may still be on it. The patched releases are for 8.2 through 8.5.
The version number looks old. This one confuses people. Some hosts fixed older versions in place without changing the number. So a site showing 8.3.35, one step below the fixed release, can still be patched. Hosts that did this suggest checking the build date instead, which should be October 21, 2026 or later. A recent build date is a good sign, not proof. Ask your host to confirm the fix is in.
You checked the wrong PHP. A server can have more than one PHP installed. The version you see when you type a command into a server can differ from the one actually running your website. Check the website itself.
What about my cache?
It’s tempting to think a caching plugin helps. Page caches, like LiteSpeed Cache or similar tools, serve saved copies of pages without running PHP at all. Fewer requests reach PHP, so you’d expect less risk.
For this flaw, that isn’t much comfort. The attack arrives as a form submission, the kind of request a cache never serves. It goes straight past the cache to PHP. A cache makes your site faster. It doesn’t patch anything. The fix is the update.
How to check, in about ten minutes
On a WordPress site, log in as an administrator and go to Tools > Site Health > Info, then open Server. You’ll see the PHP version your site is actually using.
If it says 8.2, 8.3, 8.4 or 8.5, check that it’s at or above the patched release (8.2.35, 8.3.36, 8.4.27 or 8.5.12). If the number is lower, ask your host whether they patched it in place, and what the build date is.
If it says 8.1 or anything older, ask your host whether they patched it anyway. Many big hosts did. Either way, that version no longer gets regular fixes from PHP, so it’s time to plan a move up.
One catch: there’s a third, related flaw, and even the newest release doesn’t fix it yet. PHP says it’s unlikely to affect most sites. The stopgap is a setting, and it’s in the questions below.
What to ask your host or web person
You don’t need to understand the details to ask good questions. Send these:
- Which PHP version does my site run, and is it patched for the October 21, 2026 PHP security release?
- If the version number didn’t change, what’s the build date?
- Am I on shared hosting that you patch, or on a server I’m responsible for?
- There’s a third, related flaw that isn’t fixed yet. PHP says it’s unlikely to affect most sites, but suggests turning off a setting called
session.upload_progress.enableduntil the next release. Have you done that, or should we? - PHP 8.2 stops getting security fixes on December 31, 2026. What’s the plan to move to a newer version?
That last one matters more than it looks. Updates between PHP versions can break old plugins and themes. Planning it in November is calm. Doing it on January 2 in a hurry is not.
The bigger lesson
Every few months there’s a flaw like this, in something you didn’t know you depended on. The businesses that come through it fine aren’t the ones with the most security tools. They’re the ones who know who looks after their website, and can get a straight answer by the end of the day.
If you don’t know who that is for your site, find out this week. That’s the real fix.
