WP2Shell: critical WordPress core vulnerability chain

WP2Shell chains two flaws in WordPress core to give an anonymous attacker full remote code execution on a stock install, with no plugins, no configuration quirks and no login required. It is being exploited in the wild. If you run WordPress, confirm you are on 6.9.5, 7.0.2 or 6.8.6 or later today, and check your site for the signs of compromise listed below.

What's happening

WP2Shell is a pre-authentication remote code execution chain in WordPress core itself, not in a plugin or a theme. It was found by researchers at Searchlight Cyber and disclosed on 17 July 2026. It combines two separate flaws:

• CVE-2026-63030, a logic flaw in the REST API batch endpoint (/wp-json/batch/v1, also reachable as ?rest_route=/batch/v1). When a sub-request path is prefixed with a triple forward slash, the validation step and the execution step read that path differently. Validation passes, then execution dispatches the sub-request under a handler that never applies the authentication check.
• CVE-2026-60137, an SQL injection in the author__not_in parameter of the posts endpoint. On its own it needs a logged-in user, so it is a moderate problem. Reached through the batch flaw above, it becomes anonymous.

Chained together, an attacker anywhere on the internet gets code execution on a default WordPress installation. There are no preconditions. No plugins are required, no unusual configuration, no user interaction, and no existing account. In observed attacks the payload is used to create an administrator account, log in, and install a malicious plugin, which then drops a persistent webshell on the server.

Both CVEs were added to CISA's Known Exploited Vulnerabilities catalog on 21 July 2026, which confirms active exploitation. Multiple working proof-of-concept exploits were public within days of disclosure, so the barrier to running this attack is now very low.

You can read the official WordPress release announcement for the vendor's own account of the fix.

Affected and fixed versions

• The full remote code execution chain affects WordPress 6.9.0 through 6.9.4 and 7.0.0 through 7.0.1.
• It is fixed in 6.9.5 and 7.0.2, both released 17 July 2026, and in 7.1 Beta 2.
• The 6.8 branch is affected by the SQL injection component only, not the full chain. That fix was backported to 6.8.6.

WordPress enabled forced automatic updates for affected sites, which has patched a large share of installs without anyone lifting a finger. Do not treat that as a guarantee. Forced updates do not land on sites with auto-updates disabled, sites where file permissions prevent core from writing to itself, sites whose host defers or manages updates on its own schedule, or sites where core files have been modified. Verify the version yourself rather than assuming it was handled.

What to do if you run a WordPress site

• Check your version now. It is shown in the dashboard under Updates, and in the "At a Glance" panel. If you are below 6.9.5, 7.0.2 or 6.8.6, update immediately.
• If you genuinely cannot update today, block /wp-json/batch/v1 and ?rest_route=/batch/v1 at your web application firewall or web server, and restrict anonymous REST API access. Treat this as a stopgap for hours or days, not a fix.
• Reset passwords for every account. The SQL injection can read password hashes out of the wp_users table, so any password on an exposed site should be considered captured.
• Rotate secrets. Regenerate the salts and keys in wp-config.php, which invalidates existing sessions, and rotate any API keys or integration credentials the site holds.
• Then check for compromise. Patching stops the entry route, it does not remove a webshell or a rogue admin account that was created before you patched.

Signs of compromise to look for

One important detail about this attack: it is largely log blind. The malicious instructions travel inside the body of a batch POST request, so a normal access log shows an unremarkable POST to a valid endpoint and nothing more. Database evidence is more reliable than server logs here.

• Administrator accounts you do not recognise, particularly usernames matching wp2_ or w2s_ patterns, or addresses on the wp2shell.invalid and wp2shell.shellcode.lol domains.
• Gaps in the sequence of user IDs, or orphaned rows left behind in wp_usermeta.
• Entries in the active_plugins option that you never installed, or plugin directories with names you do not recognise.
• PHP files created or modified since 16 July 2026, especially anywhere under wp-content/uploads, where executable files should never appear.
• Unusual customize_changeset posts with unexpectedly high parent IDs, odd oEmbed cache rows, or injected _transient_ entries in wp_options.
• POST requests to /wp-json/batch/v1 or ?rest_route=/batch/v1 in your access logs, which at least tells you the endpoint was probed.

If any of these turn up, preserve the evidence before you start cleaning. Take a copy of the database and the web root first, so the entry point and the timeline can still be traced. A cleanup done in a hurry usually destroys the only record of what actually happened, and often misses a second backdoor.

How we help our clients

This one undercuts the usual advice. The standard guidance for WordPress security is to keep your plugins lean and your themes trustworthy. That advice is sound, and it would not have helped here. WP2Shell needed no plugins at all. A perfectly maintained, stock install was fully exploitable by an anonymous attacker, because the vulnerability was in the platform.

That is the argument we keep making. Most small business websites do not need a public REST API, a database and an admin login exposed to the internet. Jigsaw, our alternative, has none of them, so this entire class of vulnerability simply does not apply.

For clients whose site genuinely needs a CMS, our WordPress management plan runs on tooling rather than on someone remembering to click update: versions tracked against published vulnerability data so security releases are applied on our schedule, multi-factor authentication on administrator logins, brute force protection, alerting on new or newly escalated admin accounts, a web application firewall, malware and file integrity scanning, and hourly off-server backups. The account alerting earns its keep here, because creating a rogue administrator is the first thing a WP2Shell payload does.

If you are not sure which version your site is running, or you would like us to check it for the indicators above, request a chat.

Corey Crowden Creative and Technical Lead (And director of Tas Web Co)