On July 17, 2026, Searchlight Cyber disclosed wp2shell, a pre-authentication remote code execution chain in WordPress Core. It’s about as bad as WordPress bugs get: no login, no vulnerable plugin, no special configuration. A stock, fully “up to date” install on the wrong version can be taken over by an anonymous attacker over the internet. Proof-of-concept exploits were on GitHub within hours, and scanning and live exploitation started almost immediately.
If you run WordPress, this is a drop-everything moment. This post explains what the bug actually is, what every site owner should do right now, what recovery looks like if you’re already compromised, and, because recovery is the hard part, how Backvera gets you back to a known-good state without turning a bad day into a lost week.
What is wp2shell?
wp2shell (tracked as CVE-2026-63030 and CVE-2026-60137) is a flaw in how WordPress Core handles its REST batch endpoint, the API at /wp-json/batch/v1 (also reachable as /?rest_route=/batch/v1) that lets clients bundle several REST calls into one request.
In plain terms: the batch handler can get confused about which request it’s actually processing. When sub-requests inside a batch call get out of sync, a request can be dispatched under the wrong REST handler. Public exploit chains abuse this by nesting batch calls to slip past the method restrictions that normally protect an endpoint, then reach a pre-authentication SQL injection through query parameters that were never meant to apply on the route they land on.
From that SQL injection foothold, the published tooling goes one of two ways:
- The plugin-upload route: escalate from the SQLi to an administrator account, then upload a malicious plugin that contains a webshell.
- The direct-to-disk route: write a PHP webshell straight to the filesystem using SQL’s
INTO OUTFILE.
Either way, the ending is the same for you: attacker-controlled PHP running on your server, and command execution through your web stack. From there an attacker can steal your database, plant persistent backdoors, inject spam or card-skimmers, pivot to other sites on the same host, or hold the whole thing for ransom.
It’s worth pausing on the scale. WordPress powers an estimated 500 million websites. A pre-auth RCE with no preconditions against stock installs is the kind of bug that gets sprayed across the entire internet indiscriminately. You don’t have to be a target. You just have to be reachable and unpatched.
Which versions are affected
| WordPress branch | Exposure | Fixed in |
|---|---|---|
6.8.5 and earlier | Not affected by the full RCE chain | n/a |
6.8.0 to 6.8.5 | SQL injection only (no full RCE on this branch) | 6.8.6 |
6.9.0 to 6.9.4 | Full pre-auth RCE | 6.9.5 |
7.0.0 to 7.0.1 | Full pre-auth RCE | 7.0.2 |
If you’re on the 6.9 branch, the fixed release is 6.9.5. If you’re on the 7.0 branch, it’s 7.0.2. (For what it’s worth, Backvera’s own site runs WordPress, and we moved to 7.0.2 as soon as the fix shipped. Practice what you preach.)
You can check whether a site is exposed using the public checker the researchers published at wp2shell.com.
What every WordPress owner should do right now
This applies to everyone, whether or not you’ve been compromised, and whether or not you use Backvera.
1. Patch immediately. Update WordPress Core to 7.0.2 (or 6.9.5 on the 6.9 branch). This is the only real fix. Everything else on this list is either a stopgap or cleanup. If you have auto-updates for Core enabled, confirm they actually applied; don’t assume.
2. Check your exposure. Run your site through wp2shell.com and confirm which version you’re actually on (via Dashboard, Updates, or the <meta name="generator"> tag in your page source).
3. If you genuinely can’t patch this minute, block the batch endpoint. As a temporary emergency measure only, block anonymous access to /wp-json/batch/v1 and /?rest_route=/batch/v1, either at your WAF/edge (Cloudflare, ModSecurity, etc.) or with a plugin that disables anonymous REST access. Be aware this can break legitimate integrations that rely on the REST API, so treat it as a bridge until you can update, not a permanent posture.
4. Assume compromise if you were exposed to the internet on a vulnerable version. Exploitation began within hours of disclosure. If your site was publicly reachable and running 6.9.0 to 6.9.4 or 7.0.0 to 7.0.1 at any point after July 17, patching forward does not remove a backdoor that was already planted. Patching stops new intrusions; it does not clean up an old one. Move on to the incident-response steps below.
5. Rotate secrets after cleanup. Once you’re confident the site is clean and patched, rotate everything an attacker could have grabbed: all admin passwords, database credentials, WordPress salts/keys (wp-config.php), API keys, and any secrets stored in the database or environment.
Signs you may have been hit
Look for the footprint this attack leaves behind. Based on public exploit behavior and in-the-wild telemetry:
- New or modified
.phpfiles inwp-content/plugins/orwp-content/cache/that you didn’t put there. The attacker’s webshell may sit inside a plugin directory, but the folder can be named anything, so don’t rely on recognizing a specific name. - Unexpected administrator accounts created during the exposure window.
- Access-log markers:
POSTrequests to/?rest_route=/batch/v1or/wp-json/batch/v1, sometimes with aUser-Agentofwp2shellorcve-2026-63030, and HTTP207 Multi-Statusresponses on batch requests. - Your web server spawning a shell, for example
apache2,php-fpm, ornginxlaunchingsh/bashto run commands likeid,whoami, orhostname. That web-server-runs-a-shell pattern is one of the strongest signals that code execution actually succeeded.
One important trap: some public exploits delete their own plugin directory after running, and that directory can be named anything in the first place. A missing or perfectly normal-looking plugin folder is not proof you’re clean. If your logs show batch exploitation, treat the host as compromised even if the obvious artifacts are gone.
If you think you’ve been hacked, and you’re not using Backvera
This is the hard road, and it’s worth spelling out honestly so you know what you’re in for.
1. Take the site offline or isolate it. Put it in maintenance mode, or better, pull it behind a firewall or take it out of the load balancer. You want to stop ongoing damage and stop the box being used to attack others.
2. Preserve evidence before you touch anything. Copy the current filesystem and database somewhere else first. If you clean in place without a copy, you destroy the evidence trail, and if you later discover the cleanup missed something, you’ve got nothing to compare against.
3. Find and remove the backdoors, all of them. This is the part that eats an evening (or a weekend). Reinstall WordPress Core from a known-good source, reinstall every plugin and theme from official copies, and hunt for injected PHP across wp-content/, especially uploads/, cache/, and plugins/. Diff against a clean install. Check the database for rogue admin users, malicious scheduled tasks (wp_cron), and injected options. The problem is that a competent attacker plants several backdoors in unrelated places precisely so that removing the obvious one doesn’t lock them out.
4. Assume you missed something. With RCE-level access, the only way to be truly certain a server is clean is to rebuild it from scratch on fresh infrastructure and restore only known-good data onto it. Cleaning in place is faster but leaves you wondering.
5. If you have host backups, tread carefully. Many hosts keep backups on the same system as the site, which means a backup taken after the compromise may already contain the backdoor, and ransomware-style attackers sometimes reach those backups too. Check the date of any restore point against when you were first exposed.
6. Patch, rotate every secret, and only then bring it back online.
None of this is impossible. But without a trustworthy, dated, off-site restore point, you’re doing archaeology under pressure, and the clock is running while your site is down.
If you’re using Backvera
Here’s where the day gets a lot shorter. Backvera doesn’t patch the bug for you (nothing but the WordPress update does), but it takes the two hardest parts of an incident, working out what was tampered with and getting back to a clean state, and makes them straightforward. A realistic recovery looks like this:
1. Patch first. This is non-negotiable. Update WordPress to 7.0.2 / 6.9.5 before you do anything else. If you restore a clean backup onto a still-vulnerable version, you’ll simply get re-exploited, possibly within minutes. Restore is for cleaning up the compromise; the patch is what stops it happening again. Do the patch first.
2. Use the change history to see exactly what was touched, and when. This is where Backvera earns its keep during an incident. Every backup records which files and which database tables changed since the one before it. So instead of guessing, you can scroll back through your restore points and spot the moment a stray .php file appeared under wp-content, or the moment your users table changed because an attacker injected a rogue admin account. That change trail does two jobs at once: it confirms whether you were actually hit, and it points you to the last restore point that was still clean.
3. Drill into the specifics with single-item downloads. When something looks off, you don’t have to pull down a whole site to investigate. Download the single file or the single database table that changed and compare it against a known-good copy. If your users table grew a row it shouldn’t have, or a plugin file changed between two nightly backups, you can see precisely what was modified, without touching production, and decide exactly how far back you need to roll.
4. Pick a restore point from before your exposure window. With the change history telling you when the tampering started, choosing a clean restore point stops being guesswork. wp2shell went public on July 17, so you want a point from before the earliest moment your site could have been hit. Backvera’s flexible retention (up to 365 days on the higher tiers) means those older, pre-incident restore points are still there when you need them, not overwritten by a nightly job that already captured the backdoor.
5. Verify in staging before you rely on it. Backvera’s staging spins a copy of your chosen restore point up on its own subdomain, with its own secrets and its own mail routing, so you can confirm it’s genuinely clean and the site works properly before it goes anywhere near production. Once you’ve verified it, restore it onto your patched server: the site drops into maintenance mode while the restore runs, then comes back on the clean build.
6. Your backups are out of the attacker’s reach. Because Backvera stores backups off-site by default and never touches the host it’s protecting, an attacker who owns your web server can’t reach, alter, or encrypt them. A ransomware hit on your box doesn’t take your backups down with it, and encryption (AES-256 at rest, TLS 1.3 in transit) plus integrity checksums mean the restore point you pull is byte-for-byte the one you stored. What off-site doesn’t do is make every restore point clean: if Backvera ran a backup while the site was already compromised, that backup contains the malicious files, and restoring it would put them right back. That’s exactly why the change history matters. It’s how you land on a restore point from before the tampering rather than one that quietly captured it.
7. Surgical recovery when you don’t need a full rollback. If the damage is contained, say a single injected file or a single modified table, partial restore brings back one file, one directory, one database table, or a single row without taking the whole site down. For WooCommerce and Easy Digital Downloads, Backvera captures order and payment data in realtime and supports point-in-time recovery, so store data can be recovered to a specific moment rather than only to a nightly snapshot.
The honest summary of Backvera’s role: it turns “rebuild everything from scratch and hope you got it all” into “see exactly what changed, roll back to a restore point you’ve verified is clean, on a patched server.” It is the recovery half of your defense. The patch is the prevention half. You need both.
The bottom line
wp2shell is a textbook reminder that security is layered:
- Prevention is patching fast and reducing your attack surface. Update to 7.0.2 / 6.9.5 today, and keep Core auto-updates on so the next one lands before the PoCs do.
- Detection is watching for the footprint: logs, file changes, and endpoint monitoring that flags your web server spawning a shell.
- Recovery is having clean, dated, off-site, verifiable backups so that when something gets through, you’re back online in minutes instead of rebuilding for days.
Backups don’t stop the break-in. They decide whether it’s a scare or a catastrophe. If you’ve been meaning to sort out real backups, an active internet-wide RCE campaign is the nudge: set them up before you need them, because you can’t take a clean backup of a site that’s already compromised.
Patch first. Then make sure your recovery plan is one you’d actually trust at 2 a.m.
Ready in a few clicks, stored off your server, waiting for the day you need it. Start a free Backvera trial »