Everyone's telling you the same thing right now: update WordPress. Which is, fine, yes, obviously but that's not enough. Patching closes the hole. What is someone is already In your system?
So let's actually walk through this properly what to do right now, what to do if you can't patch immediately, and what to do if you think you were already hit.
Need more context? I wrote a summarising one here.
S1: Stop assuming you're patched. Go check.
WordPress flipped on forced automatic background updates for this one because of how serious it is. That's great, except "forced" doesn't mean "guaranteed", VERIFY IT.
Go look at your actual running version right now:
- In the dashboard:
wp-admin > Updates - Via WP-CLI, if you have shell access:
wp core version
You want to see 7.0.2 if you're on the 7.0 line, or 6.9.5 if you're on 6.9.
If you see anything else — 6.9.0 through 6.9.4, or 7.0.0/7.0.1 — you're still exposed. Update it now!! Come back when done.
A few situations where the forced update quietly doesn't happen, in what I read on internet:
- Managed hosting environments where the host controls the update pipeline and hasn't pushed it yet
- Sites with a "disable auto-updates" plugin installed months ago for stability reasons and never revisited
-
wp-config.phpwithWP_AUTO_UPDATE_COREexplicitly set tofalse - Staging or dev environments nobody thinks of as "production" but that are still internet-facing
If any of that describes you, don't wait on the automation. Update manually.
S2: If you genuinely can't update right now, here's your stopgap
aybe you're facing a compatibility issue, a change freeze, or a custom plugin that isn't ready yet. It happens. If you need a little more time before applying the real fix, here's a workaround that helps.
Block anonymous access to the batch REST endpoint. The vulnerable surface is specifically /wp-json/batch/v1 and its query-string equivalent, ?rest_route=/batch/v1. You can handle this a couple of ways:
- At your WAF or reverse proxy (Cloudflare, Nginx, whatever sits in front of your site) — block or challenge requests to those paths from unauthenticated traffic
- With a plugin that restricts REST API access to logged-in users only
I want to be upfront about the tradeoff here: both of these can break legitimate things. The block editor uses REST endpoints. So do a lot of mobile apps and third-party integrations. This is a temporary bandage, not a real fix — treat it that way and get back to updating properly as soon as you can.
If you're behind Cloudflare, also check whether their managed ruleset for this specific vulnerability is switched on for your zone. They shipped detection rules pretty quickly after disclosure.
S3: Figure out if you were already hit
This is the part almost everyone skips, and it's the part that actually matters if your site was sitting in an affected version between when this became exploitable and when you patched.
Quick gut check on timeline: disclosure was July 17. In-the-wild exploitation was confirmed within days of that. So if your site was running 6.9.0-6.9.4 or 7.0.0-7.0.1 and internet-facing anytime after that, don't just assume nothing happened please go look.
Things worth checking:
Admin accounts. Anything new that you didn't create? Any password resets you didn't trigger? This is usually the first thing an attacker does once they've got code execution — plant a persistent admin account so they don't need the exploit again.
File timestamps. Look through wp-content, especially theme and plugin directories, for files modified around dates that don't line up with anything you actually did. A stray .php file with a weird name sitting in an upload directory is a classic sign.
Scheduled tasks. Check wp_cron for anything unfamiliar. Attackers sometimes use this for persistence.
Access logs. Search for anonymous POST requests hitting /wp-json/batch/v1 or ?rest_route=/batch/v1 around your exposure window. That's the fingerprint of someone probing or actually exploiting the chain.
Database. If you're comfortable poking around directly, check wp_users and wp_options for anything that looks off — unexpected serialized data, options keys you don't recognize.
If you find something genuinely anything from that list — this stops being a "patch and move on" situation. At that point:
- Rotate every credential tied to the site: WordPress admin passwords, database credentials, API keys, FTP/SSH if applicable
- Actually search for backdoors rather than just deleting the one file you found — attackers who get RCE rarely plant just one way back in
- If you've got a clean backup from before the exposure window, restoring from that is usually faster and safer than trying to manually clean an infected install
- If this is a business-critical site, this is probably the point where you loop in someone who does incident response for a living rather than doing forensics solo at 1am
S4: The stuff that's worth doing regardless of this specific bug
None of this is wp2shell-specific, but it's exactly the kind of thing that determines whether the next core vulnerability catches you exposed or not:
- Actually turn on auto-updates for core, and check periodically that it's still working rather than assuming it forever
- Keep an eye on whether your host's update pipeline is timely — some managed hosts lag behind official releases
- Don't expose more REST API surface than you need; if you're not using the batch endpoint for anything legitimate, there's no downside to restricting it permanently
- Have a "did this site get patched" checklist for exactly moments like this one, so you're not scrambling to remember which of your fifteen WordPress installs is still on an old version
telling simply, if that's all you needed(so longer one)
Check your actual WordPress version, don't trust that the forced update ran. Get to 7.0.2, 6.9.5, or 6.8.6 depending on your branch. If you can't update immediately, block anonymous access to /wp-json/batch/v1 as a temporary measure. If your site was exposed anytime after July 17, go check for signs of compromise before you assume patching was the end of it. That's the whole job.
Based on public source from WordPress.org, and Cloudflare's reporting on wp2shell (CVE-2026-63030 / CVE-2026-60137), current as of late July 2026.
Top comments (0)