If you’ve gotten a WordPress email saying your password was changed, and you never touched it, you’re not losing your mind, and you’re not alone. But that email only shows up if the site is actually set up to send mail reliably. A lot of WordPress installs never had SMTP configured in the first place, which means the built-in mail function is either getting blocked by the host, landing in a spam folder nobody checks, or not going out at all. If that’s your setup, there’s no email to tip you off. The first sign is simpler and worse: you go to log in one day, and your usual password just doesn’t work anymore.
So the pattern shows up in three flavours, not one. Sometimes there’s a brand new “Administrator” user sitting in the dashboard with a name nobody on the team recognises. Sometimes it’s a notification email you never asked for. And sometimes there’s no warning at all, just a password that stopped working for no reason you can explain. We’ve fielded calls about all three in the last couple of weeks.
Here’s the part that tends to worry people once they hear it. This isn’t some obscure plugin nobody’s heard of. This time the problem lives inside WordPress core itself.
What’s Actually Going On
In mid-July, security researchers went public with a pair of vulnerabilities in WordPress core that, chained together, let an attacker create an administrator account and run code on a site without ever logging in. No stolen password, no phishing, no plugin required. A default WordPress install sitting on the internet was enough on its own.
The two bugs are being talked about together under the nickname “wp2shell.” Between them, they touch the REST API’s batch request handler and the database query layer WordPress uses almost everywhere. The short version is that one bug lets a request slip past an authentication check it should have hit, and the second bug takes advantage of that gap to manipulate a database query directly. Chain the two together and someone with zero credentials ends up with full administrator access.
This is also why the symptom isn’t always a shiny new account. The exact technical path can vary: credentials pulled from the database and cracked offline, or the same authorisation bypass pointed at an account that already exists instead of a brand new one, but the outcome lands in the same place either way: an attacker ends up holding valid access to an account, sometimes one they invented, sometimes one that was already sitting in your user list. For the attacker, touching an existing account is arguably the cleaner move. A changed password on a username you already recognise draws far less suspicion than a stranger showing up, right up until the change-notification email lands, or until you just try to log in one day and find out the hard way.
WordPress pushed out fixes fast. Versions 6.9.5 and 7.0.2 closed it, and there was a backport patch for anyone still on the 6.8 branch. WordPress even flipped on forced automatic updates for sites running an affected version. That sounds like it should be the end of the story. It isn’t, for two reasons. Proof-of-concept code for the exploit went public within days, so anyone who hadn’t updated yet became an easy target almost immediately. And more than a few site owners have told us their dashboard reported “up to date” while the actual version number on the server told a different story. The forced update didn’t always take cleanly.
If any of your sites weren’t running a current version sometime after mid-July, this is the most likely explanation for what you’re seeing now.
It’s Almost Certainly This, But Update Everything Anyway
If this happened to you recently, wp2shell is the most likely explanation, full stop. It hit WordPress core directly, needed nothing more than a default install sitting online, and moved fast enough to sweep the internet within days of going public.
It’s not the only story this year, though, and that’s worth one sentence, not three paragraphs. Plugins have had their own versions of the exact same failure: a support-access feature abused in a mapping plugin, a role field trusted too easily in a membership plugin, a logic gap in an automation plugin’s connection check. None of them made the news the way wp2shell did. None of them needed to.
The lesson is identical either way. Unauthenticated account takeovers are having a moment across WordPress generally, not just in core, and the one move that covers every version of this is keeping core and every single plugin updated, all the time. Not eventually. Not “when there’s time.” That part isn’t optional; it’s the baseline.
Why Fixing the Account Isn’t Really the End of It
This is the part most people get wrong, understandably. You delete the fake admin, or reset the password back to something only you know; the site looks normal again, and it feels solved.
Usually the account activity is just the visible leftover of whatever actually happened. If the attacker got in through a code execution bug rather than a stolen login, touching that account, new or existing, was a side effect, not the goal. The real goal tends to be persistence, something planted that lets them get back in even after the obvious account is fixed. That might live in a theme file, a scheduled task, an uploads folder, or somewhere else that never shows up in the WordPress dashboard, because the dashboard was never how they got in to begin with.
Fixing a symptom doesn’t remove a cause. It just removes the thing that told you the cause was there.
What’s Actually Worth Checking
We’re not going to turn this into a full technical manual here. Partly because the specifics change from site to site depending on the host and the plugin stack, and partly because a generic checklist tends to give people false confidence more often than it gives them a clean site. That said, at a minimum, before calling a site clean again, someone should be looking at:
- The real installed core version, not just what the dashboard claims
- Whether every active plugin is genuinely current
- Whether anything’s been added to the file structure that nobody on the team put there
- What the server access logs show around when this actually happened, whether that’s an email timestamp or roughly when your password stopped working
That last one matters more than people expect. It’s usually the fastest way to confirm what actually happened instead of guessing at it.
This is more or less the job description for our hacked WordPress recovery service. If one of your sites has already had an account touched, whether that’s a new admin or your own password changed for you, that’s exactly what it’s built for.
Making Sure This Doesn’t Become a Regular Thing
The harder truth is that most of the sites we’ve looked at this year weren’t hit because of some clever, targeted attack. They were hit because a patch sat unapplied for a few weeks, or an update got skipped, or nobody was watching for the gap between what the dashboard said and what was actually running on the server. wp2shell moved fast enough that even a two- or three-week patching lag was enough of a window. Whether the entry point ends up being core or a plugin, the fix starts in the same place: everything current, all the time, not just after something already broke.
If you’re managing more than one or two WordPress sites, that’s really the argument for ongoing monitoring rather than reacting every time something like this makes the rounds. It’s the difference between finding out about the next one because you’re suddenly locked out of your own site, versus finding out about it before it ever gets that far. That’s the idea behind our WordPress security and maintenance service: patching, monitoring, and account audits running quietly in the background so this stops being something you find out about after the fact.
If you’re not sure whether any of your sites were touched by this, it’s worth checking sooner rather than later. These things tend to sit quietly for a while before they turn into something far more expensive to fix.
