I've spent 15 years cleaning up hacked WordPress sites — north of 400 of them — and the ones that hurt most are almost always the same story: a trusted plugin that quietly turned into an open door, on a site whose owner had no idea the news had broken. An authentication plugin is the worst possible place for this kind of bug, because its entire job is to decide who gets in. So let's make sure your site isn't the one that finds out the hard way.

The 30-Second Version

• What it is: A critical authentication-bypass flaw (CVE-2026-57807, CVSS 9.8) in miniOrange's OAuth Single Sign-On – SSO (OAuth Client) plugin for WordPress. It abuses the plugin's password-recovery flow as an alternate login path, letting an unauthenticated attacker gain full administrator access.
• Are you affected? Yes, if you run the miniOrange OAuth SSO plugin at version 38.5.8 or earlier (every release up to and including 38.5.8).
• The fix: There is no official patch yet. Disclosed by Patchstack on July 9, 2026. The one unambiguous instruction from researchers: deactivate and delete the plugin immediately on any internet-facing site. A WAF virtual patch (Patchstack/Wordfence) buys time but isn't a cure.
• Already breached? Check for administrator accounts you didn't create. Scan your site free to look for signs of compromise, and if it's infected, the cleanup steps are further down.

What CVE-2026-57807 Actually Does

Most plugin vulnerabilities need a specific set of conditions — a logged-in subscriber, a particular setting enabled, a second bug to chain with. This one doesn't. It's a broken-authentication flaw (CWE-288: Authentication Bypass Using an Alternate Path or Channel), and the "alternate path" is the plugin's own password-recovery mechanism.

Here's the plain-English version: single-sign-on plugins exist to manage who is allowed in. This one has a side door in its account-recovery flow that never properly enforces the login checks. An attacker can walk through that side door without authenticating at all, and come out the other side holding the keys — a full administrator session. From there it's game over: they can install a malicious plugin, create hidden admin users, inject spam or card-skimming code, exfiltrate customer data from a WooCommerce store, or use your site as a launchpad for the next one.

The reason this is a big deal isn't just the severity — it's the reach. The miniOrange OAuth SSO plugin is used on over a million WordPress sites, many of them exactly the kind of business site that relies on "Login with Google/Microsoft" for staff or customers. That's a large, uniform attack surface, and the flaw is trivially exploitable from anywhere on the internet.

It was discovered by security researcher Kim Dvash and published in the Patchstack database on July 9, 2026.

Am I Affected? (Check in 60 Seconds)

You're at risk if both of these are true:

• You have the miniOrange OAuth Single Sign-On – SSO (OAuth Client) plugin installed and active (it's the one that adds "Login with…" buttons via OAuth/OpenID Connect).
• Its version is 38.5.8 or earlier.

To check: log into wp-admin, go to Plugins → Installed Plugins, find the miniOrange OAuth/SSO plugin, and read the version number under its name. If it says 38.5.8 or anything lower, treat the site as vulnerable right now.

Not sure whether it's even installed? It often appears on the login screen as a "Sign in with Google/Microsoft/etc." button. If you inherited the site or a developer set it up, don't assume — check the plugin list directly.

What to Do Right Now — The Fix

This is the part that's different from a normal advisory. There is no "update to version X" here (at least not as of publication), so patching isn't an option. Your job is to remove the exposure.

1. Deactivate and delete the plugin. On any public-facing site, this is the only guaranteed fix. Go to Plugins → Installed Plugins, deactivate the miniOrange OAuth SSO plugin, then delete it. Yes, that breaks your SSO login buttons temporarily — that's a far smaller problem than an attacker owning the site. Make sure at least one normal WordPress administrator account still has a known password before you do this, so you don't lock yourself out.

2. If you genuinely can't remove it yet, put a WAF in front of it. Patchstack has shipped a virtual patch (WAF rule) that blocks exploitation attempts, and Wordfence-style firewalls can help too. Treat this as a stopgap, not a cure — it reduces risk while you arrange a proper fix, but the safe move is still removal.

3. Check for a patched release before reinstalling. miniOrange will eventually ship a fixed version. Before you turn SSO back on, confirm on the plugin's WordPress.org page that you're installing a release newer than 38.5.8 that explicitly addresses CVE-2026-57807. Don't reactivate the old version.

4. Consider an alternative in the meantime. If SSO is business-critical, a reputable alternative OAuth/OIDC plugin — or a temporary switch to standard WordPress logins with two-factor authentication — keeps you running without the exposure.

Removing the plugin closes the door. It does not evict anyone who already walked through it before you acted — which is the next thing to check.

Am I Already Hacked? How to Tell

Because this is an authentication bypass on a widely deployed plugin with no patch, assume attackers are actively hunting for it. If your site ran a vulnerable version while exposed, look for:

• Administrator accounts you don't recognize in Users → All Users — sort by role and by registration date. A brand-new admin you didn't create is the classic fingerprint of this kind of takeover.
• Plugins or themes you never installed, especially recently added ones with generic names.
• Unexpected files in wp-content/ or the web root — .php files with random names or recent modification times.
• Unfamiliar logins in your security-plugin or server access logs, particularly around the SSO/OAuth endpoints.
• Spam pages, redirects, or a "This site may be hacked" warning in Google's results, or your host flagging outbound spam.

If any of that shows up — or you just want certainty — the fastest outside-in check is to run our free hacked-site scanner. It checks your site against malware and phishing blocklists, inspects TLS and security headers, and flags the tell-tale signs of a compromise, with no login or plugin install required.

If You're Compromised: Clean It Properly

Here's the mistake I see over and over. Someone spots one bad admin account, deletes it, removes the plugin, and calls it done. Two weeks later the site reinfects — because a real attacker who got admin access almost never leaves just one way back in. With an admin-level takeover like this, they've had the run of the place.

A proper cleanup means:

• Back up first (files and database) so you have a forensic copy.
• Audit every administrator and user account, delete the rogue ones, and reset passwords for the rest.
• Rotate all secrets — regenerate your WordPress security keys to force-log-out every session (including the attacker's), and change the database password.
• Hunt for backdoors — a modified wp-config.php, a rogue must-use plugin in /wp-content/mu-plugins/, injected admin users, poisoned .htaccess, or scheduled cron jobs.
• Check the database for injected content and unknown options.
• Then remove the vulnerable plugin and harden so it can't recur.

If your site handles customer data or payments, you may also have breach-notification obligations. And if you'd rather not do all of that at 2 AM yourself, that's exactly what I do — fixed-price malware removal and cleanup starting at $249, including a full backdoor sweep and hardening so you're not back here next month. If you want to understand what a breach actually costs, I've written before about the true cost of a hacked WordPress site — it's rarely the cleanup fee that hurts.

This is also a good moment to mention it's not the only WordPress emergency this month: the WP2Shell WordPress-core RCE (CVE-2026-63030) is being actively exploited too, so if you've been behind on updates, check both.

Common Mistakes to Avoid

• Assuming a WAF rule is a fix. Virtual patching buys time; it doesn't remove the vulnerable code. Delete the plugin.
• Just deactivating, not deleting. A deactivated-but-present plugin can still be reactivated by a compromised admin, and its files may remain reachable. Remove it.
• Reinstalling the same version once the panic passes. If you put SSO back before a genuine fix ships, you've reopened the exact same door.
• Forgetting the lockout risk. Confirm you have a working standard admin login before you pull an SSO plugin, or you'll lock yourself out.

Frequently Asked Questions

Is there a patched version I can just update to? Not as of this writing. miniOrange had not released an official fix when the flaw was disclosed on July 9, 2026. Until a release newer than 38.5.8 that names CVE-2026-57807 appears, removal (plus a WAF as a stopgap) is the safe path. Re-check the plugin page before reinstalling.

I use miniOrange, but a different plugin — am I affected? This CVE is specific to the OAuth Single Sign-On – SSO (OAuth Client) plugin at version 38.5.8 or earlier. miniOrange publishes several plugins; confirm the exact plugin and version in your Plugins list rather than guessing.

If I remove the plugin, does that undo a breach that already happened? No. Removing it closes the entry point but doesn't remove backdoors or rogue accounts an attacker planted while it was vulnerable. If you were exposed, check for compromise and clean the site.

My host uses a firewall — am I covered? Maybe partially. A managed WAF (like Patchstack's virtual patch or a good host firewall) can block known exploitation patterns, but it's not a guarantee and doesn't fix the underlying flaw. Don't rely on it as your only protection.

Key Takeaways

• Check Plugins → Installed Plugins for the miniOrange OAuth SSO plugin at version 38.5.8 or earlier.
• If found, deactivate and delete it on any public site — there's no patch yet (CVE-2026-57807, CVSS 9.8).
• Confirm a standard admin login works first so you don't lock yourself out.
• Use a WAF virtual patch only as a temporary stopgap, not a fix.
• Check for rogue admin accounts and backdoors — an auth bypass means assume attempted takeover.
• Only reinstall once a release newer than 38.5.8 explicitly fixes the CVE.

If the scanner turns up something, or you just want a professional set of eyes before your customers do, get in touch — I clean these for a living, and with an unpatched auth bypass in the wild, moving fast is the whole game.

Originally published on xuro.net.

I've cleaned north of 400 hacked WordPress sites over 15 years, and the pattern with a bug like this is always the same: the sites that get hit aren't the ones with weak passwords or pirated themes. They're ordinary, well-maintained sites whose owners hadn't heard the news yet and were three days behind on an update. So let's make sure that's not you.

The 30-Second Version

• What it is: Two chained WordPress core vulnerabilities — CVE-2026-63030 (CVSS 9.8, a route-confusion bug in the REST API's /wp-json/batch/v1 endpoint) and CVE-2026-60137 (CVSS 9.1, a SQL injection in WP_Query). Chained together they give an unauthenticated attacker full remote code execution.
• Are you affected? Yes, if you're running WordPress 6.9.0–6.9.4 or 7.0.0–7.0.1.
• The fix: Update to WordPress 6.9.5 or 7.0.2 immediately (released July 17, 2026). WordPress.org pushed forced auto-updates for affected sites — but you must confirm yours actually applied.
• Already breached? Attackers are planting hidden admin accounts and webshells. Scan your site free to check — the cleanup steps are further down.

What WP2Shell Actually Does

Most WordPress attacks need a foothold — a vulnerable plugin, a leaked password, a poisoned theme. WP2Shell needs none of that. It abuses two flaws that ship in WordPress core:

The first, CVE-2026-63030, is a route-confusion bug in the REST API's batch-processing endpoint (/wp-json/batch/v1), which is enabled by default. It lets an attacker smuggle input past the normal permission checks. That smuggled input feeds the second flaw, CVE-2026-60137, a SQL injection in WordPress's core WP_Query (via the author__not_in parameter).

Chained, the two turn into a full unauthenticated compromise: the attacker forges a database record, writes to WordPress's oEmbed cache, and from there escalates into a rogue administrator account and a webshell plugin. Once that webshell lands, they own the server — they can serve spam, inject malware into every page, steal customer data from a WooCommerce store, or pivot to other sites on the same hosting account.

The scale is what makes this ugly. Security firm Wiz found that roughly 60% of organizations running WordPress had at least one vulnerable instance when the flaws were disclosed, and about a quarter were exposing a vulnerable server directly to the internet. Public proof-of-concept exploit code is already circulating, which is why scanning and exploitation attempts spiked within a day of disclosure.

Am I Affected? (Check in 60 Seconds)

You're vulnerable if your site runs any of these versions:

• WordPress 6.9.0, 6.9.1, 6.9.2, 6.9.3, or 6.9.4
• WordPress 7.0.0 or 7.0.1

To find your version, log into wp-admin and look at the bottom-right of the dashboard, or check Dashboard → Updates. If you can't log in, you can often see it in your page source (though many sites hide it) or ask your host.

If you're on 6.9.5, 7.0.2, or newer, you're patched. If you're on anything older than 6.9.0, you're not affected by this specific chain — but you're dangerously behind on other security fixes and should update anyway.

How to Fix It — Right Now

1. Update WordPress core. Go to Dashboard → Updates and install the latest version (6.9.5 on the 6.9 branch, or 7.0.2 on the 7.0 branch). If you manage the server, you can also update via WP-CLI:

wp core update
wp core version

Confirm the second command reports 6.9.5 / 7.0.2 or higher.

2. Verify the auto-update actually applied. WordPress.org enabled forced automatic updates for affected sites because of how severe this is — but forced updates can silently fail on sites with file-permission locks, disabled cron, or DISALLOW_FILE_MODS set. Don't assume. Log in and check the version number yourself.

3. If you genuinely can't update immediately, ask your host or a WAF (Cloudflare, Wordfence, Sucuri) to block requests to /wp-json/batch/v1 as a stopgap. This is a band-aid, not a fix — patch as soon as you can.

Patching stops future exploitation. It does not remove an attacker who already got in before you updated. That's the part most people miss.

Am I Already Hacked? How to Tell

Because this bug was exploited in the wild for days before many sites updated, a clean version number today doesn't guarantee you weren't hit yesterday. Warning signs to look for:

• Administrator accounts you don't recognize (Users → All Users — sort by role and date).
• Plugins you never installed, especially ones with generic names, that are active but not in the plugin directory.
• Unexpected files in wp-content/, wp-includes/, or the web root — particularly .php files with random names or recent modification dates.
• Requests to /wp-json/batch/v1 in your access logs around or after July 17.
• Spam pages, redirects, or "This site may be hacked" warnings in Google search results.
• Your host suspending the account or flagging outbound spam.

If any of that rings true — or you simply want peace of mind — the fastest first check is to run our free hacked-site scanner. It checks your site against malware and phishing blocklists, inspects TLS and security headers, and flags the tell-tale signs of a compromise from the outside, no login or plugin install required.

For a deeper look, WordPress's security team and several vendors have released an official wp2shell compromise-scanner plugin and browser extension that check specifically for this attack's fingerprints.

If You're Compromised: Don't Just Delete and Move On

Here's the mistake I see constantly. Someone finds one bad file, deletes it, updates WordPress, and calls it done. Two weeks later the site reinfects, because the attacker left a second backdoor — a hidden admin, a modified wp-config.php, a cron job, a poisoned .htaccess — that never got touched. With WP2Shell specifically, the whole point of the attack is to plant persistence, so a partial cleanup almost always fails.

So here's what a proper cleanup actually looks like. Before you touch anything, take a full backup of both the files and the database — you want a forensic copy in case you need to trace what happened or something goes wrong mid-clean.

1. Clean the file system (FTP/SSH). The SQL injection let attackers write PHP straight to disk (via MySQL's INTO OUTFILE), so hunt for:

• Suspicious PHP files in /wp-content/cache/ with random alphanumeric names (reported examples look like e042u9xy9ra1.php).
• A fake backdoor disguised as a "security patch" in /wp-content/mu-plugins/ — must-use plugins load automatically and don't appear in the normal Plugins list, which makes it a favourite hiding spot. Delete anything you didn't put there.
• Any unknown plugin added under /wp-content/plugins/.

Then update core to 6.9.5 / 7.0.2 to seal the hole, and lock down file editing in wp-config.php:

define( 'DISALLOW_FILE_EDIT', true );
define( 'DISALLOW_FILE_MODS', true );

2. Reset every credential and kill every session. Assume the attacker already has your password hashes.

• Reset passwords for all users (administrators first), and change the MySQL database password — then update it in wp-config.php.
• Regenerate your WordPress secret keys and paste them over the old salts in wp-config.php. This instantly invalidates every logged-in session, including the attacker's.
• Check Users → All Users for any administrator you didn't create, and delete it.

3. Clean the database. The attack seeds spoofed records, often stamped with a fixed date of 2020-01-01 00:00:00 and a payload pointing to example.invalid. Back up first, change the wp_ prefix if yours differs, then:

DELETE FROM wp_posts    WHERE post_type = 'customize_changeset' AND post_date = '2020-01-01 00:00:00';
DELETE FROM wp_posts    WHERE post_type = 'nav_menu_item'        AND post_date = '2020-01-01 00:00:00';
DELETE FROM wp_postmeta WHERE meta_value LIKE '%example.invalid%';

4. Harden so it can't recur. WordPress never needs MySQL's FILE privilege — and that privilege is exactly what let the SQL injection write a webshell to disk in the first place. Revoke it, logged in as the database root user:

REVOKE FILE ON *.* FROM 'your_wp_db_user'@'localhost';
FLUSH PRIVILEGES;

One honest caveat: a determined attacker can also bury a shell inside a legitimate-looking theme or plugin file, so if any of the above turns up a real infection, treat the whole install as suspect and diff every core, theme, and plugin file against a known-good copy. And if your site handles customer data or payments, you may have breach-notification obligations too.

A word on those free "wp2shell checkers." Most of them only tell you whether you're patched — they ping the Batch API route and report back. They do not tell you whether you were breached before you patched. Since this was exploited in the wild for days before many sites updated, "patched but already compromised" is the dangerous middle ground, and it's exactly what our free scanner and a manual review are built to catch.

If you'd rather not do that at 2 AM yourself, that's exactly what I do. I offer fixed-price malware removal and cleanup starting at $249 — emergency cleanup, full recovery, and hardening so you're not back here next month. And if you want to understand the real stakes, I've written before about the true cost of a hacked WordPress site — it's rarely the cleanup fee that hurts.

Common Mistakes to Avoid

• Assuming the forced auto-update applied. WordPress.org pushed automatic updates, but they fail silently on locked-down sites. Check the version number yourself — don't take it on faith.
• Patching and calling it done. Updating closes the hole for future attacks; it does nothing about an attacker who already got in before you updated. Always check for compromise too.
• Deleting one bad file and stopping. WP2Shell's whole purpose is persistence — a rogue admin, a webshell, a poisoned wp-config.php. Find every backdoor, not just the obvious one, or the site reinfects.
• Treating a WAF rule as the fix. Blocking /wp-json/batch/v1 at the edge is a stopgap while you can't patch — it's not a substitute for updating core.
• Skipping the FILE-privilege revoke. If you clean up but leave the database user's FILE privilege in place, the next SQL-injection bug can write a shell to disk all over again.

Frequently Asked Questions

Do I need a vulnerable plugin for WP2Shell to work? No. That's what makes it dangerous. It exploits WordPress core, so a completely stock install with zero third-party plugins is still vulnerable on the affected versions.

I have Wordfence / a security plugin. Am I safe? A WAF can help block the exploit traffic, but it's not a substitute for patching, and it won't clean a site that was already breached. Update core first, then verify you're not compromised.

WordPress said it auto-updated me. Am I done? Check the version number yourself — forced auto-updates can fail silently on locked-down sites. If it reads 6.9.5 / 7.0.2 or higher, you're patched against the exploit. You still need to confirm you weren't hit beforehand.

My site is on managed WordPress hosting. Do I still need to worry? Most reputable managed hosts patched at the platform level within hours, but confirm with your host and still check for compromise if you were on an affected version between July 17 and whenever they patched.

Key Takeaways

• Confirm your WordPress version now — you're exposed on 6.9.0–6.9.4 or 7.0.0–7.0.1.
• Update to 6.9.5 or 7.0.2 immediately (CVE-2026-63030 + CVE-2026-60137, unauthenticated RCE, actively exploited since July 18).
• Verify the forced auto-update actually applied — check the version number yourself; it can fail silently on locked-down sites.
• Remember patching doesn't evict an attacker who got in first — check whether you were already breached.
• Look for rogue admin accounts, unknown plugins, and hits on /wp-json/batch/v1 in your logs from around July 17 on.
• If you find an infection, clean it properly — backups, salt-key rotation, a full backdoor sweep, and REVOKE FILE; a partial cleanup just reinfects.

If the scanner turns up something, or you just want a professional set of eyes before your customers notice, get in touch — I clean these for a living, and moving fast is the whole game.

Originally published on xuro.net.