The PHP flaw that skipped WordPress entirely: what happened, and what to check on your site

On October 21, the PHP project shipped emergency fixes for two critical security flaws, CVE-2026-109618 and CVE-2026-109619. Security researchers have started calling the pair “php2shell.” Both are rated 9.2 out of 10. Both let an attacker run their own code on a web server without logging in to anything.

If your website runs on WordPress, it runs on PHP. That makes this your problem, even if you have never thought about PHP in your life.

What actually happened

PHP is the language underneath WordPress, WooCommerce and most small-business websites. The two flaws sit in how PHP handles a web request before your site’s own code even starts. An attacker sends a specially built request, and PHP itself can be tricked into running their commands.

Three things made this one worse than usual:

• It happens before WordPress loads. Security plugins, login limits and firewalls inside WordPress never get a chance to look at the request. They are not in the room yet.
• The details leaked a day early. The flaws were supposed to be announced on a fixed date with patches ready. They leaked, so PHP rushed the release, and attackers had a head start on many site owners.
• Older PHP versions get no fix at all. PHP 8.2 and newer received patched releases (8.2.35, 8.3.36, 8.4.27 and 8.5.12). PHP 8.1 and older are past end of life, so there is no official update coming. A surprising number of sites still run them.

“My host handles updates.” Maybe.

Most site owners assume their hosting company patches PHP automatically. Sometimes that’s true. Often it’s slower than you would hope.

PHP fixes don’t come straight from the PHP project. Your server gets them from whoever packages PHP for it: your operating system, your control panel or your hosting company. Each of those has its own testing and release schedule, and an announcement that a fix exists is not the same as the fix being on your server.

That’s why we don’t take an announcement’s word for it. When we reviewed the sites we look after this week, we checked each server directly against PHP’s own release list, and that turned up two things worth knowing:

• A widely used hosting control panel published a temporary safety setting for this flaw. Publishing a setting doesn’t switch it on, so we turned it on ourselves the same afternoon and confirmed it was active on every server.
• The same comparison showed that this control panel’s update channel had skipped two earlier PHP security releases from this year. A server that only follows that channel can look “up to date” while missing fixes. Our checks compare against PHP’s own releases, so a gap like that shows up the day it happens.

None of this is unusual. It’s how the software supply chain works. But it means “my host handles it” is a hope, not a check.

What to do this week

If you manage your own site, or want to know what to ask whoever does:

1. Find out which PHP version your site runs. The quickest way is our free PHP version checker: enter your site address and it tells you whether your PHP has this fix. You can also look in WordPress under Tools → Site Health → Info → Server, or in your host’s control panel.
2. Make sure it is a patched release: 8.2.35, 8.3.36, 8.4.27, 8.5.12 or newer in the same line.
3. If it says 8.1, 8.0, 7.4 or older, move up. Those versions will not get this fix. Moving to PHP 8.3 is usually painless for an up-to-date WordPress site. Test first, because very old plugins and themes are the usual reason a site breaks.
4. Ask your host a direct question: “Has the php2shell fix been installed on my server, and which exact PHP version am I running now?” A good host answers with a version number, not a reassurance.
5. Check your backups exist, and that they live somewhere other than the same server. If the worst happens, a backup on the hacked server is not a backup.

Signs your site may already be compromised

Attacks like this are about getting a foothold, so the signs are usually quiet:

• New files in your site folders you don’t recognize, especially .php files inside uploads.
• New administrator accounts in WordPress that nobody on your team created.
• Visitors on phones being redirected to other sites, while the site looks normal on your laptop.
• Google Search Console warnings, or strange pages showing up in search results under your domain.
• Your host suspending the site, or warning about outgoing spam or high CPU.

If you see any of these, don’t just delete the strange file and move on. Infections usually leave more than one way back in.

How Fivenson Studios helps

We build, host and look after WordPress sites for businesses across Michigan, and this week is a good example of what that looks like in practice.

On the day of the release, every server we manage had the temporary protection switched on and confirmed, server by server, and every site was checked to make sure it still loaded normally. Over the next two days we:

• Verified the patched PHP versions on each server once they arrived, by checking the version actually running.
• Moved every site still on end-of-life PHP to PHP 8.3, one site at a time, testing each page and the login before moving on.

What runs on our managed servers every day:

• Automatic alerts when PHP falls behind a security release, checked against php.net itself, so we don’t depend on noticing a vendor’s email.
• Monitoring for the first signs of a break-in below the level WordPress security plugins can see, with an alert the moment something looks wrong.
• Nightly malware scanning that looks at what changed on each site and checks WordPress core and plugin files against their official versions.
• Encrypted backups stored off the server, checked after every run.

If your site has been hacked, or you’re not sure whether it has, we clean up WordPress malware. That means:

• finding how they got in, not just the file they left;
• removing it;
• closing the hole;
• hardening the site so it doesn’t happen again.

We’ll also tell you plainly whether your current setup can be fixed in place or should be moved.

Not sure where your site stands? Run your site through our free PHP version checker. It tells you which PHP version your site shows and whether it has this fix, and our team will follow up on the result. Or talk to Fivenson Studios →

Sources: PHP release announcements for 8.2.35, 8.3.36, 8.4.27 and 8.5.12 (php.net, October 21, 2026); CVE-2026-109618 and CVE-2026-109619 advisories.