Clicking 'update' closes the door. It doesn't check whether someone already walked through it, or whether the other doors are locked. A practical, no-nonsense checklist for after a critical WordPress vulnerability.
You saw the wp2shell headlines, you clicked 'update,' you felt responsible. I want to gently ruin that feeling, because updating is step one of maybe five. A patch stops future exploitation — it does nothing about whether someone already got in during the window when your site was vulnerable and a proof-of-concept was public, and it doesn't touch the doors a core update was never meant to lock. Here's the audit I'd actually run, and it's about ten minutes.
Step 1 — Confirm you're actually patched
Don't trust that the update happened; verify the version. Log into wp-admin and read the number in the footer, or open Dashboard → Updates. You want to see 6.9.5, 7.0.2, or 6.8.6. If you manage sites at scale, check each one — the forced auto-update is best-effort and sites with auto-updates disabled or servers that can't reach WordPress.org may have been skipped. A site you assumed was patched because 'WordPress handles that' is exactly the one to check first.
Step 2 — Check whether you were already hit
This is the step people skip, and it's the one that matters most if your site ran a vulnerable version after the PoC dropped. Coalition's honeypots caught active exploitation attempts in the wild, so 'nobody would target my small site' isn't a safe assumption — automated scanning doesn't care how big you are. Look for the fingerprints of a takeover:
Users → All Users: scan for administrator accounts you don't recognise. A new admin you didn't create is the clearest sign of compromise.
Review recent posts, pages and comments for injected spam or scripts, and check for theme/plugin files with recent modification dates you can't explain.
Look in wp-content/uploads for PHP files — legitimate uploads there are images and documents, never executable code. A .php in uploads is a classic backdoor.
Check server access logs for suspicious hits on /wp-json/batch/v1 and unusual POST requests around the exposure window (mid-to-late July).
If you find any of it, stop treating this as maintenance and treat it as an incident: the wp2shell chain leads to code execution, so a successful attacker could have done far more than create a user. Take a backup for evidence, then consider a clean restore from a known-good point before the exposure window rather than trying to surgically remove a backdoor you might not fully find.
A PHP file in wp-content/uploads is not a real upload — it's a backdoor. Look for it. · Pexels
Step 3 — Lock down the surface it abused
wp2shell reached code execution through the REST API's batch endpoint. You've patched the specific bug, but the broader lesson is that an exposed, permissive REST API is attack surface. Most sites don't need the REST API open to anonymous users for everything it exposes. A WAF — whether your host's, Cloudflare's, or a plugin like Wordfence — gives you a layer that can block exploit patterns even before you've patched, which is the protection Patchstack and Coalition customers leaned on during the exposure window. If you run WordPress without any WAF in front of it, this incident is the argument for fixing that.
Step 4 — Rotate what a takeover would have grabbed
Admin passwords, especially if you found anything suspicious in step 2. Assume they leaked.
Secret keys and salts in wp-config.php — regenerating them invalidates all existing sessions, kicking out anyone who may be logged in with stolen cookies.
API keys and tokens the site stores — payment gateways, email services, any third-party integration. A code-execution bug means anything on disk was reachable.
Database credentials if you have any reason to think the host itself was touched.
Step 5 — Harden what a patch never touches
The patch fixed one bug. These are the standing defenses that make the next one less costly, and they're worth the ten extra minutes while you're already in here:
Enable two-factor authentication on all admin accounts — it turns a stolen password from a takeover into a non-event.
Audit your plugins: delete (don't just deactivate) anything you don't use, and update the rest. Deactivated plugin code can still be vulnerable.
Confirm you have working, off-site backups you could actually restore from — test one, don't just trust it exists.
Keep auto-updates on for core and security releases, so the next forced push actually reaches you.
Quick answers
I'm patched and found nothing suspicious. Am I in the clear?
Very likely, yes — if you're on 6.9.5/7.0.2/6.8.6, have no unexplained admin users, no injected content, and no rogue files, you've done the meaningful checks. Nothing is ever 100%, but you've closed the vulnerability and verified the common signs of compromise. Rotating passwords and enabling 2FA is cheap insurance on top.
How far back should my 'known-good' backup be if I was compromised?
Before the exposure window — for wp2shell, before mid-July 2026 when the PoC went public. The risk with a more recent backup is that it already contains the backdoor. If your only backups are recent, restore the cleanest one, then immediately run the compromise checks again on the restored site and patch it before putting it back online.
Do I need a security plugin like Wordfence or Patchstack?
It's not mandatory, but a WAF-style layer earns its place — it can block exploit attempts before you've patched, which is exactly the gap that hurt during the wp2shell window. If you run a single small site with disciplined updates you may be fine without one; if you manage client sites or can't guarantee fast patching, a virtual-patching service is worth the cost.
This is a lot. What's the one thing if I only do one?
Verify your version is 6.9.5/7.0.2/6.8.6 and enable two-factor on your admin account. The first closes the actual hole; the second makes the most common follow-on attack — a stolen or reused admin password — useless. Everything else in this audit is important, but those two give you the most protection per minute spent.
That's the audit. It's deliberately practical because 'be more secure' is useless advice and 'here are five things to click' isn't. If you're still catching up on what wp2shell actually is, start with our core-flaw breakdown; if you run the miniOrange login plugin, that's a separate fire this audit's step 1 won't put out. Patch, verify, check for guests, then lock the rest.
