October has been a hard month to own a WordPress site. Three security stories broke in three weeks, in three different layers: WordPress itself, the PHP underneath it, and a backup company your site may trust without your knowing it. Only one of the three was fixed by clicking Update. Here is what each one means in plain terms, what to check this week, and the pattern that connects them.
One: wp2shell, a hole in WordPress itself
wp2shell is a flaw in WordPress core, not in a plugin (CVE-2026-63030 and CVE-2026-60137). It lets an attacker take over a site with no login. It affects versions 6.9.0 to 6.9.4 and 7.0.0 to 7.0.1, and WordPress fixed it in 6.9.5 and 7.0.2 on July 17. This is the one that clicking Update fixed, and WordPress pushed the fix out automatically.
So why is it October news? Because on October 12 researchers described a criminal group running an AI coding agent against WordPress sites at scale: in one automated run it scanned 4,708 sites, got into 429 admin panels and planted 32 web shells within 61 seconds (The Hacker News, SOCRadar). Its favourite way in is wp2shell, three months after the fix shipped. A site still on 6.9.4 or 7.0.1 has automatic updates switched off and nobody watching it, which is exactly what these tools look for.
The check: Dashboard, then Updates. Anything below 6.9.5, or on 7.0.0 or 7.0.1, needs updating today. Then look under Users for an administrator you don't recognise, especially one named wp2_ followed by eight characters, and under Plugins for a folder whose name starts with wp2shell_.
Two: PHP2Shell, the flaw your host has to fix
We covered PHP2Shell in its own post. The short version: two critical flaws in PHP, the language WordPress runs on (CVE-2026-109618 and CVE-2026-109619, rated 9.2 out of 10). Either one can let an attacker with no login run code on the web server. PHP shipped fixes on October 21 in versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Updating WordPress, your theme or your plugins does nothing here; your host has to update PHP, and no setting works around it. Attempts to exploit it have been reported; as this is written, no confirmed break-in has. PHP 8.1 and older no longer get regular security updates, which makes that conversation with your host a bigger one.
The check: Tools, Site Health, Info, then the Server section shows your PHP version. Then send your host two questions: which PHP version is our site on, and when will it be updated to a release that fixes PHP2Shell?
Three: UpdraftPlus, where the attackers didn't need a flaw at all
UpdraftPlus is one of the most-used backup plugins in WordPress, on more than four million sites. Over the weekend of October 17 and 18, attackers got into the website of the company that makes it. The company believes its customer database was accessed: names, email and billing addresses, order history, passwords in hashed form, and the connection keys for its remote services, including UpdraftCentral, its remote-management dashboard (the company's notice).
Those keys are the story. UpdraftCentral sends signed instructions to each connected site, and the site obeys because the signature is genuine. Strictly speaking there was no UpdraftPlus vulnerability at all: the plugin did what it was built to do. With stolen keys the attackers needed neither a password nor a bug, only commands the sites were built to trust. Starting on the afternoon of October 18 and running for about 18 hours, they used the keys to have connected sites install a backdoor plugin through WordPress's own installer (Patchstack). Researchers counted 99 plugin names; the one that kept recurring was "Site Health Cache".
The backdoor creates a user with the Editor role, then quietly gives it the power to install plugins and change settings, so the account looks harmless in the Users list. It logs the attacker in through a cookie rather than the login form, so two-factor authentication and login lockouts never run. And the account outlives the plugin: delete the plugin and the user is still there, with a password the attacker knows.
The company published UpdraftPlus 1.26.13 (free) and 2.26.13 (Premium) on October 19, and WordPress.org pushed them to every site. The update revokes the old keys and disconnects UpdraftCentral, which closes the door. It does not remove a backdoor or account already inside. That is why this one wasn't fixed by clicking Update. One wrinkle: connecting a site to a TeamUpdraft account created a key by default, so a backups-only site may have had one without its owner knowing. As of October 21 the company says there is currently no evidence the attacker still has access, and its investigation is ongoing.
The check: if your site runs UpdraftPlus, confirm it is on 1.26.13 or 2.26.13 or later. Then go to Settings, UpdraftPlus, Advanced Tools, UpdraftCentral and delete any connection key still listed. Look under Plugins, including the Must-Use tab, for anything you didn't install, and under Users for an Editor or administrator you don't recognise. Change every administrator password, and your TeamUpdraft password if you have an account. If you find any of it, restore from a backup taken before October 17 and have the site cleaned by someone who knows what they're looking at.
The risk isn't only your site's code. It's every company your site trusts.
The pattern
Put the three side by side. One was in WordPress and an update fixed it. One is underneath WordPress and only your host can fix it. One wasn't a flaw at all: a company your site trusted got breached, and the trust did the rest. A careful owner who installs every update the day it ships was covered against the first, waiting on someone else for the second, and exposed to the third with nothing wrong on their own site.
That is what a WordPress site is in 2026: a core, a runtime, a theme, a stack of plugins, and behind each plugin a company with its own security. Every one is a door, and you hold the key to maybe half of them. We keep a dated, sourced list of this year’s major incidents in our WordPress security log, and October’s three are far from the only entries. The honest advice for a WordPress owner this month isn't a longer checklist. It's fewer moving parts. Every plugin you can remove is a company you no longer have to trust. Every remote connection you can delete is a key nobody can steal. It's the point we made about apps your team builds with AI: what matters is who can reach it and what they can do once they're in.
Where we stand
THINQ Site, the platform we build and host our clients' websites on, has no PHP, no database and no plugins running on the server. None of October's three problems has anything to hit on it, and there is no backup vendor holding a key to it. That isn't a claim that a THINQ Site can't be attacked. It's a narrower one: the layers where this month's problems lived don't exist on it, and what's left is ours to watch.
If you run WordPress and you're staying on it, do the three checks above this week. If you're thinking about leaving, start by deciding what not to bring with you; a move that carries the plugin stack along carries the problem along. And if you'd like a quick, free read on how your site looks from the outside right now, run the twenty-second scan.
