Two WordPress Security Alerts You Can't Ignore: A Full Takeover Bug and 12 Core Fixes

If your WooCommerce store uses the WooCommerce Social Login plugin, stop and check the version right now. There's a critical hole in it that lets a total stranger log in as your administrator, and it's rated 9.8 out of 10. On top of that, WordPress itself just shipped a security release, 7.0.3, that fixes twelve more vulnerabilities. Two separate problems, both worth your attention this week.

This post walks through both, in plain terms, so you know what's actually at risk and what to do about it. No panic, just the facts and a clear checklist.

Key takeaways

• The WooCommerce Social Login plugin has a critical authentication bypass (CVE-2026-8457, rated 9.8/10) affecting all versions up to and including 2.8.7. Update to 2.8.8 or higher.
• The flaw lets unauthenticated attackers log straight in as any user, including an admin, with no account and no password needed.
• WordPress core 7.0.3 fixes twelve vulnerabilities. The most serious is a login-screen XSS rated 8.9/10 that could, in the wrong conditions, lead to remote code execution.
• The core XSS needs social engineering to work and isn't mass-exploitable, so the WooCommerce plugin bug is the more urgent one to act on.
• Auto-updates and a proper maintenance routine catch most of this quietly, before it becomes your problem.

The WooCommerce Social Login flaw: an unlocked front door

Let's start with the more dangerous of the two, because it's the one attackers can use without tricking anyone.

The WooCommerce Social Login plugin does a useful job. It gives your customers one-click login and faster checkout using accounts they already have with Facebook, Google, Amazon, PayPal and Apple. No new password to remember, less friction at the till, more completed orders. That's the appeal.

The trouble is in how it handles the Apple side of that. When someone signs in with Apple, Apple hands over an identity token that carries details about who's logging in. That token comes with a digital signature, and the whole point of the signature is that the plugin should check it against Apple's public keys to confirm the token is genuine. Think of it like checking that a signature on a cheque actually matches the account holder.

The plugin doesn't do that check properly. And that one missing step is the whole problem.

Why this one is so serious

Because the signature isn't verified, an attacker can hand the plugin a forged token that simply contains the email address of an existing user on your site. The plugin takes that email at face value, finds the matching WordPress account and logs the attacker straight in as that person.

Here's the part that should make you sit up. There's no role exclusion. In plain English, the plugin doesn't say "hang on, this is an administrator account, let's be careful." It treats an admin the same as any customer. So if an attacker supplies your admin email, they get an authenticated admin session, instantly.

Wordfence, the security firm that reported it, put it like this:

"This makes it possible for unauthenticated attackers to log in as any existing WordPress user, including administrators, by supplying a forged id_token whose payload contains the target user's email address, as that email is used without any role exclusion to resolve a WordPress account and immediately issue an authenticated session for it."

Once someone has admin access to a WooCommerce site, it's game over. They can install malware, redirect your checkout, harvest customer data, hold the site to ransom, or quietly skim card details. "Unauthenticated" is the word that matters most here: the attacker needs no account, no password and no permission of any kind. That's about as bad as a vulnerability gets, which is why it earned a 9.8 out of 10.

The facts you need

• Identifier: CVE-2026-8457
• Severity: 9.8 out of 10 (critical)
• Affected versions: all versions up to and including 2.8.7
• Fixed in: 2.8.8 or higher
• Publicly disclosed: 1 August 2026
• Reported by: Wordfence

What to do about it

Wordfence recommends anyone on version 2.8.7 or earlier updates to 2.8.8 or higher. That's the fix. If you run this plugin, treat updating it as today's job, not this month's.

A few practical points if you're doing it yourself:

1. Check your version first. Go to Plugins in your WordPress admin, find WooCommerce Social Login and read the version number next to it.
2. Back up before you update. Any update can occasionally clash with something on your specific site, so a fresh backup means you can roll back if the store behaves oddly afterwards.
3. Update the plugin to 2.8.8 or later through the Plugins screen.
4. Test the login and checkout flow after updating. Sign in with one of the social accounts and place a test order to confirm nothing broke.
5. If you can't update straight away, deactivate the plugin. A store with slightly clunkier login is far better than a store an attacker owns. You can re-enable it once you've updated.

One more thing worth saying plainly: if you installed this plugin ages ago and don't really use social login any more, just remove it. Every plugin you keep is another door you have to keep locked. Fewer doors, fewer problems.

WordPress core 7.0.3: twelve fixes in one go

Now the second issue, which affects far more sites because it's in WordPress itself, not an optional plugin.

WordPress released security update 7.0.3 to fix twelve vulnerabilities. Historically it's been fairly rare to find holes in WordPress core, but there's been an unusual cluster of discoveries lately, helped along by AI tools scanning the code. That's the backdrop here: security researchers, including AI-assisted ones, are poking at the core harder than ever, and they're finding things.

One frustration for ordinary site owners is that the official WordPress announcement gives only the bare minimum description of each fix and no severity ratings at all. That makes it genuinely hard for a business owner to judge how worried to be. So here's the full list, translated where possible.

The twelve vulnerabilities

• A Contributor+ stored cross-site scripting (XSS) issue in the Post Date block
• A Contributor+ stored XSS issue in the Post Content block
• An information disclosure issue in the Latest Comments block, exposing comments on password-protected posts
• A bypass of the email address confirmation flow
• An Author+ CSS injection issue via a bypass of the safe CSS attribute filter
• A Contributor+ stored XSS issue in posts via the emoji settings element
• A privilege escalation issue on multisite networks with user registration enabled, letting a user create a new site
• A server-side request forgery (SSRF) issue in URL validation, allowing requests to link-local ranges
• A pre-auth reflected XSS issue on the login screen with potential to lead to PHP code execution
• A disclosure of notes in comment feeds
• An enumeration of post slugs
• A Contributor+ stored XSS issue in Quick Edit on sites with a large number of users

Most of these carry a "Contributor+" or "Author+" tag, which means an attacker would already need a low-level account on your site to use them. If you run a tight ship and don't hand out author accounts to strangers, the risk from those is lower. Still worth patching, but not the ones to lose sleep over.

The three that matter most

Of the twelve, three stand out.

1. Pre-auth XSS on the login screen (rated 8.9/10, high). This is the headline. Cross-site scripting, or XSS, is when an attacker gets a malicious script to run inside a page a user trusts. OWASP, the widely respected web security body, describes it as an injection attack where "malicious scripts are injected into otherwise benign and trusted websites," and the victim's browser runs the script because it has no way to know it shouldn't be trusted. Once that script runs, it can reach cookies, session tokens and other sensitive data the browser holds for that site.

The "pre-auth" label means an attacker doesn't need a WordPress account to launch it. That sounds alarming, and it would be, except there's an important catch: it still requires user interaction. Someone with an account on the site has to be tricked into doing something, which is social engineering. The WordPress GitHub security repo spells out how bad it could get in the worst case:

"WordPress is vulnerable to a pre-auth reflected XSS vulnerability on the login screen. Via a specially crafted malicious third-party website hosted by an attacker, it is possible for this to be escalated to an RCE vulnerability with conditions outside of the attackers control. This requires successful social engineering of and explicit interaction by the target victim. This issue affects all versions of WordPress. Version 7.0.3 has been released, containing a fix for the vulnerability, and as a courtesy to users on older branches the fix has been backported to all branches back to 4.7."

RCE means remote code execution, which is an attacker running their own code on your server. That's the nightmare scenario. But note the wording: escalating this to RCE depends on conditions outside the attacker's control, plus successful trickery of a real person. It's serious, hence the 8.9 rating, but it's not a simple point-and-click attack.

Note too that the fix has been backported all the way to branch 4.7. If your site is stuck on an older major version for some reason, the patch still reaches you.

2. SSRF allowing requests to link-local ranges. SSRF stands for server-side request forgery. Link-local IP ranges are addresses reserved for internal communication within a server. Put together, the minimal description suggests this lets an attacker make the server fire off requests to those internal addresses, which can expose sensitive information sitting on the server. That said, there's genuinely no proper description published, so that's an informed reading of the scraps we've been given rather than a confirmed picture.

3. Privilege escalation on multisite networks with user registration enabled. This one lets a user create a new site on the network without authorisation. Most small businesses run a single WordPress site and won't be affected. But if you run a multisite install, or you're an institution like a university with lots of sub-sites and open registration, this is one to take seriously.

How worried should you actually be?

Here's the reassuring part. Oliver Sild of Patchstack, a WordPress security firm, gave a level-headed read on the login-screen XSS on X:

"The nastiest one is a login screen XSS, which via some social engineering could lead to Remote Code Execution. Luckily, WordPress is auto-updating fast and none of the vulnerabilities are mass-exploitable like WP2Shell was. As always, patchstack customers received mitigation rules right at the disclosure."

He also told Search Engine Journal directly that they're watching for real-world attacks, but he doesn't expect much: "We're tracking whether it's getting exploited, but looks like the social engineering bit on the XSS that could lead to RCE is most likely not going to get much attention from the hackers."

Translation: the barrier of having to socially engineer a real person makes this less appealing to attackers than a bug they can spray across thousands of sites automatically. Sild also noted the wider context, that after the WP2Shell disclosure, various AI security labs and pentest firms piled in to prove they could find bugs in WordPress core too. The twelve fixes here were reported by Anthropic, pwn.ai, Aikido Security and others. So expect more of this. AI is speeding up the discovery of these flaws, which is uncomfortable in the short term but genuinely good news over time, because more found and fixed means fewer left lurking.

What to do about core 7.0.3

This is the easy one. Update to WordPress 7.0.3. If you have automatic updates for minor and security releases switched on, this has very likely already happened without you lifting a finger, which is exactly why they're worth having on. Log into your admin, go to the Updates screen and confirm you're on 7.0.3. If you're not, run the update, and back up first as a matter of habit.

Reading between the lines: why these two land differently

It's worth pausing on why the WooCommerce Social Login flaw deserves faster action than the WordPress core release, even though the core release fixes twelve things and this is only one.

Severity numbers only tell you half the story. What really matters is how easy a bug is to exploit and how likely someone is to bother. The WooCommerce Social Login flaw scores badly on both counts. It's unauthenticated, so no account needed. It needs no social engineering, so no waiting for a victim to slip up. An attacker can automate it and hit every vulnerable store they can find. That combination, high severity plus easy and automatable, is what turns a vulnerability into a mass compromise.

The core login-screen XSS, by contrast, is high severity but awkward to pull off. Someone has to be tricked into interacting, and the leap to remote code execution depends on conditions the attacker can't control. Genuinely dangerous in a targeted attack against a specific high-value site, but a poor use of a bulk attacker's time. That's precisely why Patchstack expects it to stay quiet.

So if you can only do one thing today: update WooCommerce Social Login. Then update core, though there's a fair chance auto-updates already handled that for you.

The bigger lesson: plugins are your soft underbelly

Step back from these two specific bugs and you'll spot the pattern that catches most WordPress sites out. Core WordPress is generally solid and, as we've just seen, patched fast. The flaw that hands an attacker your entire store wasn't in WordPress. It was in a third-party plugin doing something as ordinary as social login.

That's not a knock on plugins. You can't run a real WooCommerce store without them, and a good social-login tool genuinely helps conversions. But every plugin is code someone else wrote, running with real access to your site, and its security is only as good as its developer's diligence. When one of them skips a step like verifying a signature, that's your site exposed, not theirs.

A few habits that quietly keep you out of trouble:

• Keep the plugin count lean. Fewer plugins means fewer places a flaw can hide. If you're not using it, delete it, don't just deactivate it. Deactivated plugins can still be exploited in some cases.
• Favour well-maintained plugins. Check when a plugin was last updated and whether the developer responds to security reports. A plugin that hasn't been touched in two years is a risk regardless of how well it works.
• Turn on automatic updates for security releases. As Patchstack noted, WordPress auto-updating fast is a big part of why the core bugs here won't spread widely.
• Back up regularly and test the restore. A backup you've never restored is a hope, not a plan.
• Watch a vulnerability feed, or have someone watch it for you. The gap between disclosure and exploitation can be hours. This particular WooCommerce bug was publicly disclosed on 1 August 2026, and public disclosure is also a starting gun for attackers.

This last point is where most small businesses fall down, and understandably so. You're running a shop, not a security operation. Nobody's checking a CVE feed at nine on a Tuesday night. That's the whole argument for a proper website maintenance plan: someone whose actual job is to catch these releases, apply the update, take a backup first, test that nothing broke and move on before it ever becomes your emergency. For a store, where a compromised checkout means stolen customer card data and a very awkward set of conversations, that cover pays for itself the first time it saves you.

If you run a shop specifically, it's worth reading our practical guide to keeping your WooCommerce store up to date, which covers the update routine in more depth. And if the worst has already happened and you think a site's been compromised, our WordPress malware removal guide walks through cleaning and locking it back down.

Your action checklist

To pull it all together, here's what to do, in order of urgency:

1. Check the WooCommerce Social Login plugin version. If it's 2.8.7 or earlier, update to 2.8.8 or higher today. Back up first, then test login and checkout after.
2. If you can't update it immediately, deactivate it until you can.
3. If you don't really use it, delete it.
4. Confirm WordPress core is on 7.0.3. If auto-updates are on, it probably already is. If not, update it.
5. Review your other plugins while you're in there. Anything abandoned or unused gets removed.
6. Check your backups are running and recent, so you've got a fallback if any update misbehaves.

Neither of these should ruin your week. The WooCommerce plugin fix is one update away, and the core release is likely already installed. The real risk is the site that never checks and never updates, because that's the one attackers find first.

If keeping on top of updates, patches and backups is falling to the bottom of your list, that's exactly the sort of thing we handle for clients. Take a look at how our website maintenance service keeps this off your plate, so a critical disclosure like this one becomes a quiet routine update rather than a crisis.