PHP2Shell: What We Did in the Six Hours Between the Fix and Our Patch

On October 21, PHP released fixes for two critical bugs, nicknamed PHP2Shell, that can let an attacker run their own code on a server. The fix was out at 14:00 UTC. Our servers couldn’t install it until almost six hours later, because our hosting panel had to build its own PHP packages first. Here’s what we did in that gap, one mistake we made, and the check we added to PressBot so your WordPress site tells you when its PHP is behind.

What PHP2Shell is

Both bugs are in PHP itself, not in WordPress or any plugin. According to the PHP Foundation, one is triggered when a request runs out of memory at exactly the wrong moment, and the other when a fatal error leaves old data behind for the next request. On servers that run PHP inside Apache (mod_php), a single request from anyone could trigger it. On the more common PHP-FPM setups it needs help from the site’s own code, which is harder but not something to bet on.

The fixed versions are 8.2.35, 8.3.36, 8.4.27 and 8.5.12. PHP 8.1 and older no longer get security fixes from the PHP project. There is no official workaround: the only advice is to update.

Six hours with no patch

Details leaked the day before the release, a demo video circulated, and security companies reported exploit attempts against unpatched servers on release day. Our sites run on small cloud servers managed through a hosting control panel, and that panel ships its own PHP builds. Until it publishes them, there is nothing to install.

So we made a simple call: if a server can’t be patched, it shouldn’t be answering requests. Our sites get modest traffic, so a few hours offline cost little, while a compromised server would cost a lot. We powered the servers off and waited.

One practical lesson: a server that’s switched off can’t download its updates either. Next time we’ll keep it running with a cloud firewall that only allows our own administrative access, so updates can arrive while visitors can’t reach PHP.

The mistake we made

The day before the release, a widely shared post claimed the bug lived in a specific PHP feature, and that turning that feature off would block it. It was cheap and harmless, so we turned it off on all our sites. When the PHP Foundation published the details, the bug turned out to be somewhere else entirely. That setting protected nothing.

No harm done, but it’s the lesson of the day: a setting is not a patch. Leaked details are often wrong, and “precautions” can make you feel safe enough to skip the real step. The only things that actually protected us were patching and, until then, not being reachable.

What we checked after patching

• The PHP version the site actually runs. The command-line php -v can differ from what the website uses, and running PHP workers keep the old code until they restart. We checked the version each site served, not just what was installed.
• Signs of a break-in before the patch. We looked for new PHP files, especially in wp-content/uploads, unexpected changes to PHP files, WordPress core files that don’t match WordPress.org, new administrator accounts, and odd POST requests in the access logs. All clean.
• Backups. Fresh database and file backups of every site, stored off the server, before touching anything.

What we added to PressBot

Checking PHP versions by hand across several servers showed us how easy it is to miss one. A site can sit on a PHP version that no longer gets security fixes, or on a server that quietly stopped installing PHP updates, while every dashboard looks fine. Nothing in WordPress tells you. So PressBot 1.20.13 adds a check to Site Check, free for every site:

• It compares your PHP version with php.net’s list of supported releases, once a day.
• It warns you if your PHP version no longer gets security fixes, and if your server is more than a week behind on a security release for its version.
• It tells you which version to ask your host for.
• Servers that get PHP from their Linux distribution, which may be patched without changing the version number, get a gentler “ask your host” note instead of a false alarm.
• In Pro, the weekly Site Check alert on Telegram includes it, once per version.

Is the patch complete?

On release day a widely shared post called the patch incomplete. Researchers who tested the claim found the attack it relied on was an older, separate issue, not a way around the fix, and PHP’s advisory says both bugs are fixed in the new versions. We’ll update this post if that changes.

A checklist for your WordPress site

1. Find the PHP version your site actually runs. In WordPress: Tools → Site Health → Info → Server. With PressBot: Site Check.
2. If it’s below 8.2.35, 8.3.36, 8.4.27 or 8.5.12 (or it’s 8.1 or older), ask your host to update or switch you to a supported version now.
3. After updating, make sure PHP was restarted and check the version again.
4. If your site was reachable on an unpatched version, look for new PHP files in wp-content/uploads and new administrator accounts. If anything looks wrong, restore from a clean backup and change your database password, API keys and WordPress security keys.
5. Keep a recent backup somewhere other than the server.

If you run PressBot, update to 1.20.13 and open Site Check. If you don’t, the free plugin is on WordPress.org as GreenScript PressBot.