wp2shell removal

What wp2shell is

wp2shell is the nickname for a chain of two vulnerabilities in WordPress core — not a plugin, not a theme — that together give an unauthenticated attacker remote code execution and full site takeover. It was reported by Adam Kues of Assetnote / Searchlight Cyber and disclosed on 17 July 2026.

• CVE-2026-63030 — a route-confusion flaw in the REST API batch endpoint (WP_REST_Server::serve_batch_request_v1()). When a sub-request path is prefixed with a triple slash (///), the step that validates the path and the step that executes it read it differently. Rated 7.5 on its own.
• CVE-2026-60137 — a SQL injection reachable through the author__not_in parameter in WP_Query, the class behind most of the database queries WordPress runs.

Individually they are serious. Chained, they are rated critical at CVSS 9.8: the route confusion gets an attacker to a query they should never reach, the injection turns that into code execution, and from there they create an administrator, install a plugin and drop a webshell — without ever logging in.

Affected and patched versions

• Vulnerable: WordPress 6.9.0 – 6.9.4 and 7.0.0 – 7.0.1
• Fixed in: 6.9.5 and 7.0.2 (a fix also shipped in 6.8.6)

Primary sources: Bitdefender's technical advisory and Rapid7's emergent threat report.

Why this one is worse on a shared VPS

Because the flaw is in core, every WordPress install on the machine is vulnerable at the same moment — there is no "we don't use that plugin" to fall back on. Automated scanning does not stop at the first site it finds, and once code execution lands on the box, the boundaries between sites are only as strong as the server configuration.

• Sites sharing a system user or PHP-FPM pool are reachable from whichever one was hit first.
• Database credentials sitting in several wp-config.php files can be read once any one of them is.
• The forgotten staging copy or the old client site nobody updates is usually the one still on a vulnerable version — and it is the way in to the rest.

This is exactly the spread we describe in VPS server security: one hacked site becomes a hacked server.

Indicators of compromise

Check for these across every site on the server, not just the one that prompted the search:

• Administrator accounts you did not create, particularly any using a w2s_ prefix
• HTTP 207 (Multi-Status) responses from /wp-json/batch/v1 in your access logs — the signature of the batch endpoint being driven
• Plugins in wp-content/plugins/ that nobody installed
• Randomly named PHP files in subdirectories of wp-content/

Absence of these is not proof of safety. An attacker who got in early may have tidied up, and access to compromised sites is routinely resold — the payload you eventually notice is often not the one installed first.

Patching is not wp2shell removal

This is the single most important point on this page. Updating to 6.9.5 or 7.0.2 stops the exploit working from now on. It does nothing about an administrator account created last week, a webshell already sitting in wp-content, or a scheduled job that reinstalls the payload after you clean it.

Sites patched but not cleaned are the ones that come back to us a fortnight later, reinfected and with the owner convinced the update failed. It did not — the persistence was never removed.

What proper wp2shell removal involves

1. Patch every install on the server first, so the entry point is shut while the cleanup runs. Do not skip the staging copies.
2. Preserve the evidence. Take a full backup of the infected state and copy the access logs before they rotate — the HTTP 207 pattern is what dates the compromise.
3. Audit every administrator account across every site, not just for the w2s_ prefix. Remove what should not be there and rotate the credentials of what remains.
4. Find the webshells. Randomised PHP in wp-content subdirectories, and anything executable in uploads. Quarantine rather than delete, so you keep what happened.
5. Remove the persistence. Unexpected plugins and must-use plugins, injected core files, tampered wp-config.php, cron and systemd jobs, unfamiliar SSH keys.
6. Clean the database — the second half of this chain is a SQL injection, so treat injected options and post content as in scope.
7. Rotate every secret the attacker could have read: database credentials, salts in wp-config.php to invalidate sessions, API keys, mail credentials.
8. Harden and keep watching. Block anonymous access to /wp-json/batch/v1 at the edge, deny PHP execution in uploads, lock down the firewall and SSH — then monitor, because reinfection attempts follow a success.

How we handle wp2shell across a whole server

PatientZer0 runs on custom-built security software designed for exactly this shape of incident — server-level rather than per-site, because a core vulnerability hits every install at once. On a shared VPS that means:

• Every site on the box is in scope, including the staging copies and the client sites nobody has logged into for a year.
• We look where site-level scanners cannot — the server's cron table and systemd timers, authorised SSH keys, running processes and fake system binaries, which is where the persistence behind a reinfection usually lives.
• Rogue administrators and webshells are quarantined with the evidence kept, not silently deleted, so the timeline survives the cleanup.
• Hardening is applied server-wide: blocking script execution in uploads across every site, firewall lockdown, SSH hardening and a WordPress admin audit.
• Monitoring continues afterwards, which matters more than usual here — a publicly available proof of concept means scanning for this will continue long after the news cycle ends.
• Cleanups are unlimited on every plan, so a second wave does not mean a second bill.

Common questions

I have already updated. Am I safe?

You are safe from further exploitation of this chain. You are not necessarily clean. If your site ran a vulnerable version while the exploit was public, it needs checking for the indicators above.

My host says they patched it. Is that enough?

Managed hosts often push core updates, which handles the patching. It does not handle removal — your host will not audit your administrator accounts or hunt a webshell in your uploads directory. That side remains yours.

Can I just restore a backup?

Only if you are certain it predates the compromise and you patch before putting it back. Restoring an unpatched site onto a live server simply invites the same automated scan that found it the first time.

Nothing looks wrong on my site. Do I still need to check?

Yes. This chain is used to establish quiet, persistent access — an administrator account and a webshell — which is then used later or sold on. A site that looks perfectly normal is the expected appearance.

Related guides