WP2Shell is a live, actively exploited attack chain that takes over WordPress sites without a password. It chains two WordPress Core vulnerabilities — CVE-2026-63030 and CVE-2026-60137 — into pre-authentication remote code execution on default installs. If your site runs WordPress 6.9.0 through 7.0.1, update to 7.0.2 right now, then check whether someone already got in. Those are two separate jobs, and skipping the second one is how sites stay hacked.
What Is WP2Shell?
WP2Shell is the name researchers gave to an exploit chain against WordPress Core, discovered by Searchlight Cyber and analyzed in detail by Wiz. It combines two flaws:
- CVE-2026-60137 — a SQL injection in WordPress Core
- CVE-2026-63030 — the piece that turns it into full remote code execution
Chained together, they let an attacker run their own code on your server with no account, no password, and no vulnerable plugin. That last part is what makes this one different. Most WordPress hacks come in through an outdated plugin or a stolen password. WP2Shell walks through WordPress itself, on a default install.
The name comes from the attackers' own tooling — scanners probing the internet for vulnerable sites identify themselves with user agents like wp2shell and rezwp2shell.
Is Your Version Affected?
Check your WordPress version right now (Dashboard → Updates, or the footer of your admin screen). Here's the exposure by version:
| Your WordPress Version | Exposure | What to Do |
|---|---|---|
| 7.0.0 – 7.0.1 | Full remote takeover (both CVEs) | Update to 7.0.2 immediately |
| 6.9.0 – 6.9.4 | Full remote takeover (both CVEs) | Update to 7.0.2 immediately |
| 6.8.0 – 6.8.5 | SQL injection only (CVE-2026-60137) | Update as soon as possible |
| 7.0.2 or later | Patched | Verify you weren't hit before patching |
| Older than 6.8.0 | Not exposed to this chain — but unsupported and exposed to everything else | Update anyway |
Notice the last row. Running a WordPress version old enough to dodge this bug is not a win — it means you're exposed to years of other known holes. A sane update strategy beats luck every time.
How the Attack Works, in Plain English
You don't need to be technical to understand this. The short version:
- The knock. Attackers scan the internet for WordPress sites and send a crafted request to the REST API batch endpoint —
/wp-json/batch/v1. This endpoint is part of WordPress core and is on by default. (Our REST API guide explains what this API normally does.) - The bypass. The malicious request slips past authentication. WordPress treats the attacker like a trusted user.
- The takeover. From there, the attacker runs code on your server. Wiz observed attackers installing malicious plugins through
/wp-admin/, enumerating user accounts, and readingwp-config.phpto steal database credentials. - The dig-in. Before doing anything noisy, attackers plant a way back in. Wiz catalogued three flavors of webshell: a one-line backdoor that executes whatever it's sent, a 150KB obfuscated "plugin" with file management and database modules built in, and a fake REST API plugin that accepts base64-encoded commands and answers in clean JSON.
Step 4 is the part most site owners underestimate — and it's why this post doesn't end at "just update."
Signs Your Site Was Already Hit
You can't confirm a compromise from the outside with certainty, but these are the red flags to check:
- A plugin you didn't install. Especially anything installed in the last few weeks that nobody on your team recognizes.
- An admin user you didn't create. Check Users → Administrators. Attackers create innocuous-looking accounts to keep access after cleanup.
- PHP files you can't explain in
wp-content/uploads/,wp-content/mu-plugins/, or the site root. Uploads should hold images, not code. - Server logs showing POST requests to
/wp-json/batch/v1(or/?rest_route=/batch/v1) from unfamiliar IPs, especially withwp2shellin the user agent. - Unexplained admin sessions or password reset emails you didn't trigger.
If any of these ring true, treat the site as compromised and work the full malware removal process — not just the visible symptom. You can also run our free AI infection scan, which checks your site from the outside the way a visitor (or Google) sees it.
Patch Now: The Three Steps
1. Update WordPress core to 7.0.2 or later. Dashboard → Updates → Update Now. This is the fix. Everything else on this list is a stopgap or a follow-up.
2. If you truly can't update today, block the batch endpoint at your firewall or WAF (/wp-json/batch/v1 and /?rest_route=/batch/v1) and restrict anonymous REST API access. This narrows the attack path; it does not remove it. Update anyway, as soon as you can.
3. Rotate credentials after patching. Wiz observed attackers reading wp-config.php — which holds your database username and password. If your site was exposed while unpatched, change the database password, WordPress salts, and admin passwords after the update and cleanup, not before. New passwords set while a backdoor is still active are new passwords the attacker gets to watch you type.
Why Patching Alone Won't Save an Already-Hacked Site
Here's the uncomfortable math from the disclosure window: exposure dropped from 60% of organizations to 50% within 24 hours as patches rolled out. That's fast. But every one of those sites was open at some point — and attackers were exploiting this before most people patched.
Updating WordPress to 7.0.2 closes the door. It does nothing about anyone who already walked through it. The webshells, the rogue plugin, the extra admin account, the stolen database password — all of that survives the update untouched. This is the same trap that keeps sites in the hack-clean-hack reinfection cycle: the visible problem gets fixed, the persistence stays, and the attacker walks back in a week later through the spare key they hid on day one.
A WP2Shell compromise that happened in December and got "fixed" by a January core update can still be an active breach in July. The patch is step one. The eviction is step two.
How TopSyde Sentinel Evicts WP2Shell
TopSyde Sentinel is our always-on AI security layer, included free with every TopSyde hosting plan. It was built for exactly the "step two" problem — finding and removing what attackers leave behind. Here's how its daily scan maps onto what WP2Shell actually drops:
| What WP2Shell Leaves Behind | How Sentinel Catches It |
|---|---|
| One-liner webshells in uploads or site root | Daily filesystem sweep for backdoor signatures and PHP where PHP shouldn't be |
| The 150KB obfuscated webshell "plugin" | AI behavioral judgment — code is flagged for what it does (execute remote input, touch the database, write files), not just how it looks |
| Fake REST API plugins accepting encoded commands | Plugin inventory review plus the same behavioral analysis |
| Modified or added WordPress core files | Daily core verification against the official release |
| Injected database content | Database scan for injected spam and executable code |
| Rogue admin accounts | Detection of admin users that appeared outside normal flows |
Signature lists struggle here for a reason: the obfuscated webshell exists precisely to look different on every install. Sentinel's AI-driven detection judges behavior instead, which is how it catches variants no signature database has ever seen. When it finds something, it removes it automatically — with a reversible snapshot taken first, so a false alarm never costs you a working site.
And because core updates are included with every TopSyde plan, the 7.0.2 patch itself is part of the service — step one and step two, handled, starting at $89/mo per site.
What to Do Today, in Order
- Check your version. Anything from 6.8.0 through 7.0.1 → update now.
- Update to 7.0.2 or later.
- Check for the red flags above — unknown plugins, unknown admins, PHP in uploads.
- Rotate database and admin credentials after the update.
- Get ongoing scanning in place. A one-time check tells you about today. WP2Shell won't be the last core vulnerability — daily automated scanning is what turns the next one from a breach into a log entry. Our free scanner is the zero-commitment place to start.
Frequently Asked Questions
Is my WordPress site affected by WP2Shell?
If it runs WordPress 6.9.0 through 6.9.4 or 7.0.0 through 7.0.1, it's exposed to the full remote takeover chain. Versions 6.8.0 through 6.8.5 are exposed to the SQL injection component only. WordPress 7.0.2 and later are patched. Check your version under Dashboard → Updates.
Does updating to WordPress 7.0.2 remove the hackers?
No. The update closes the vulnerability so new attacks fail. It does not remove webshells, rogue plugins, rogue admin users, or stolen credentials from an attack that happened before you patched. If your site was running a vulnerable version while WP2Shell was being exploited, you need a compromise check in addition to the update.
How do I check if WP2Shell hit my site?
Look for plugins and admin users you didn't create, PHP files in wp-content/uploads/ or mu-plugins/, and server log entries showing POST requests to /wp-json/batch/v1 — especially with wp2shell or rezwp2shell in the user agent. A clean-looking homepage proves nothing; WP2Shell's webshells are designed to stay quiet.
I can't update right away — what can I do today?
Block /wp-json/batch/v1 and /?rest_route=/batch/v1 at your WAF or server config, and restrict anonymous REST API access. Treat this strictly as a stopgap — it narrows the door without locking it. Schedule the core update as an emergency, not a someday.
Does TopSyde Sentinel detect WP2Shell webshells?
Sentinel's daily scan targets exactly the classes of persistence WP2Shell drops: webshells (including obfuscated ones, via AI behavioral analysis rather than signatures alone), modified core files, rogue plugins, database injections, and rogue admin accounts. It's included free with every TopSyde plan, and removal is automatic with a reversible snapshot taken before any change.
Founder & Lead Developer
20+ years full-stack development, WordPress, AI tools & agents
Colton is the founder of TopSyde with 20+ years of full-stack development experience spanning WordPress, cloud infrastructure, and AI-powered tooling. He specializes in performance optimization, server architecture, and building AI agents for automated site management.
