On Tuesday, the PHP project did something it rarely does: it warned the whole internet a day ahead that a critical fix was coming. On Wednesday at 14:00 UTC, it shipped PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, closing two flaws, now nicknamed PHP2Shell, that can let a stranger run code on a web server without logging in. Both are rated 9.2 out of 10.
We covered the news in two short summaries, one before the patch and one after it. This post is about what the patch does not solve, and why the real work this week is an inventory, not an update.
Why this one is different
PHP is not one more plugin. It is the engine underneath most of the web, including every WordPress, Joomla and Drupal site. Estimates cited by The Record put it on more than 70% of websites.
PHP’s own advisory adds a detail that should get the attention of anyone who relies on a security plugin. For servers running PHP as an Apache module, there is a demonstrated attack where a single unauthenticated request does its damage before any application code runs. In plain terms, WordPress has not even started yet. Neither has Wordfence, or any other security plugin that lives inside WordPress. They never get a chance to see it.
The reaction matched the risk. Government cyber agencies in the EU, Germany, Japan, Australia, the UK and the Netherlands issued alerts, and some organizations, Nintendo among them, took services offline rather than wait. Cloudflare’s CTO said the company was already seeing attacks.
Updating WordPress does not update PHP
This is the misunderstanding I expect to cause the most trouble. When you click “Update” in your WordPress dashboard, you are updating WordPress. PHP sits one layer below, and it comes from your server: your hosting company, your control panel, or your own package updates if you run a VPS.
I run sites both ways, on shared hosting and on my own VPS, and the two need different handling. On shared hosting, the fix arrives when your host installs it. On a VPS, nobody installs it but you. A site can show every plugin green and up to date while the PHP under it is still the vulnerable version.
The servers nobody is watching
Here is the uncomfortable number. A Detectify researcher told The Record that roughly half of all PHP websites run versions older than 8.2. The PHP project only fixes 8.2 and newer. Everything from 8.1 back is officially end-of-life.
To its credit, the PHP team went beyond its usual policy this time and published bare-bones fixes for 7.4, 8.0 and 8.1 as source code. That helps people who compile PHP themselves. It does very little for the owner of an old site on a cheap hosting plan who has not logged in since 2019.
Those old sites are the real exposure. A forgotten marketing page from a past project. A test copy of a site someone set up and never deleted. A hosting control panel. A router or storage box with PHP built in. If nobody is updating them, it usually means nobody is watching them either, and nobody will notice when they are taken over.
The head start is gone
Defenders used to count on a gap of days or weeks between a fix and a working attack. That gap has nearly closed. Once a patch is public, attackers compare the old code with the new to see exactly what changed, and researchers quoted by The Record say AI tools can now turn that into a working exploit in under an hour. watchTowr reported attackers already trying AI-built attack tools within hours of the disclosure.
That changes what “patch soon” means. For a flaw like this, soon means today, not at the next maintenance weekend.
Beware the one-line fix
Before the patch came out, a single configuration change spread fast across social media as the workaround: turning off a PHP feature called session upload progress. The Hacker News reported that the security firm that first suggested it later walked it back, saying it was not a complete fix.
PHP’s own advisory now lists that setting and several others as ways to reduce exposure, and is blunt that none of them make a server safe. It is a familiar pattern. A simple fix that feels like protection travels faster than the slower truth, and it gives people a reason to put off the real work. If you changed the setting, there is no need to undo it. Just don’t count it as being patched.
What to do this week
- Make a list of everything you have that runs PHP. Every site, every hosting account, every add-on domain, every test or staging copy, and any old site you meant to shut down. This is the step most people will skip, and it matters most.
- Check the PHP version on each one. In WordPress, Tools > Site Health > Info > Server shows it. In cPanel, look for MultiPHP Manager or Select PHP Version. You want 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or newer.
- On shared or managed hosting, ask your host directly whether the fixed PHP build is installed on your server. Don’t assume.
- On a VPS, update the PHP packages yourself, then restart PHP (PHP-FPM or the web server), so the running workers actually load the new version.
- If a site runs PHP 8.1 or older, move it up or take it down. Some Linux vendors and hosts have backported fixes, so ask, but an old, unwatched site is not worth the risk of keeping online.
- Look back as well as forward. After updating, check for admin users, plugins or files you don’t recognize, especially anything added since October 20. A patch closes the door. It does not remove anyone already inside.
- Put a date on your calendar. PHP 8.2 reaches end-of-life on December 31, 2026. If you are on 8.2 today, you have about ten weeks to plan the move to a newer version.
If you know where all your PHP is running, this is an afternoon of updates. If you don’t, the risk is not in the sites you look at every day. It is in the ones you forgot you had.
Send this to yourself, or to someone who should see it
Enter your email and we will send you a link to this article.
