wp2shell (CVE-2026-63030 & CVE-2026-60137): An RCE Inside WordPress Core — and How W7SFW Blocks It at the Edge

The WordPress security community just recorded one of its most notable findings: wp2shell — an exploit chain leading to Remote Code Execution (RCE) that lives entirely inside WordPress core. No plugins. No themes. No special configuration. And most importantly: no authentication required.

Assigned two identifiers, CVE-2026-63030 and CVE-2026-60137, wp2shell is especially dangerous because it attacks the very platform tens of millions of websites run on — in its default configuration.

This article breaks down the exploit chain from a technical angle, and explains why an edge firewall like W7SFW can block it before the request ever reaches WordPress.

The exploit chain: 5 stagesLink to heading

1. Route confusion at the batch REST endpoint. The /wp-json/batch/v1/ endpoint lets multiple sub-requests be bundled into a single call. The flaw: when a batch "member" fails to parse, the code appends to the validation array but never adds a matching placeholder to the matches array, creating an index misalignment. As a result, an unvalidated request executes with the handler permissions of a different request.

2. SQL injection via WP_Query. Route confusion delivers the request to the posts handler while skipping schema validation. The author__not_in parameter arrives as a raw, attacker-controlled scalar instead of a clean integer array. Because WP_Query only sanitizes array-formatted values, the unsanitized string reaches the SQL query directly — enabling injection through the NOT IN clause.

3. Object poisoning in cache. The SQLi results are used to "poison" cached WP_Post objects. These forged objects carry attacker-controlled fields: status, type, parent.

4. Nested saves → admin creation. Via the oEmbed cache (which re-saves a post with just an ID and new content, letting WordPress supply the remaining fields) and two nested saves (a customizer changeset publish makes WordPress switch its current user to the remembered user before saving), a user-creation request that was initially rejected gets re-evaluated with administrator privileges — successfully creating an admin account.

5. From admin to RCE. With an admin account, the attacker installs a plugin that allows arbitrary code execution → full RCE.

The entire chain begins with an anonymous request to /wp-json/batch/v1/ containing: a deliberately broken member (to trigger the index misalignment), requests that exploit the route confusion, and user-creation requests that fail at first but succeed upon re-evaluation.

Why patching alone isn't enough (in the short term)Link to heading

This is a core vulnerability affecting default installs. The moment details go public, exploitation bots begin scanning automatically — often within hours. The dangerous window is exactly the period when the vulnerability is public but your site isn't patched yet. For teams managing many sites, that window can stretch across days.

Where W7SFW blocks wp2shellLink to heading

The key point: the whole wp2shell chain travels over HTTP and carries a very clear signature at the request layer:

• A POST to /wp-json/batch/v1/ with malformed members that cause the index misalignment.
• SQL injection payloads in the author__not_in parameter (NOT IN patterns, SLEEP functions, OR conditions, etc.).

W7SFW is an edge firewall — it inspects every request before it reaches WordPress. The wp2shell exploitation patterns are detected and blocked at the perimeter; the WordPress behind it never receives the malicious request. This is "virtual patching": you are protected from the known exploitation pattern while you wait to patch core, instead of leaving your site exposed.

See it liveLink to heading

We keep a real WordPress site at w7s-protected.com, sitting behind W7SFW. You can verify it yourself: wp2shell exploit requests never reach that site's core.

RecommendationsLink to heading

1. Update WordPress core as soon as a patch is available — this is the root fix.
2. Put an edge firewall (such as W7SFW) in front of your sites to block the exploitation pattern during the dangerous pre-patch window.
3. Monitor for indicators: requests to /wp-json/batch/v1/ with malformed members; SQLi patterns in author__not_in; unusual customizer changeset creation; and above all, unexpected new administrator accounts.

W7SFW — an edge WordPress firewall. It blocks bots, CVE exploitation, and attacks before they reach your site. Try it free at dash.w7sfw.com.