WP2Shell: How One Missing Line Broke WordPress Core

Briefing

Are you exposed?

What happened

WordPress vulnerabilities are overwhelmingly plugin vulnerabilities — which is why "keep your plugin count low" has been reasonable advice for years. wp2shell is different. The entire chain lives in core. A default install with zero third-party code was fully exploitable by an anonymous HTTP request.

Two separate bugs did it. A REST API batch endpoint added in WordPress 6.9 could be knocked out of alignment so that it validated one request and executed another. That bypass exposed a SQL injection in WP_Query that had been sitting in core since 6.8. Chained, they gave an unauthenticated attacker administrator access and then a shell.

The remarkable part is how the attacker gets from a read-only SQL injection to writing files on the server: they never gain a write primitive of their own. They convince WordPress to perform the writes for them, using features that are working exactly as designed. The technical annex below traces that step by step.

The one-line fix

Before anything else, look at the patch. This is commit c8bdf1f in wordpress-develop — one file, one line added:

// src/wp-includes/rest-api/class-wp-rest-server.php
// in WP_REST_Server::serve_batch_request_v1()
if ( is_wp_error( $single_request ) ) {
$has_error    = true;
+   $matches[]    = $single_request;
$validation[] = $single_request;
continue;
}

That is the whole fix for the critical half of wp2shell. Millions of exposed sites, a CISA emergency listing and tens of thousands of exploitation attempts — resolved by pushing one value into one array.

Risk

Disclosure timeline

Multiple vendors attribute the speed partly to AI-assisted patch diffing, and the original research is itself credited as LLM-assisted. Treat that causal claim as vendor commentary rather than established fact — but the measured outcome is not in dispute: the reverse-engineering gap defenders have quietly relied on for two decades collapsed to hours.

What you should do

Current status

Your security team should act on the Technical Annex below. All IOCs, detection and remediation guidance are in Part 2.

Technical Annex (for security / SOC teams)

Vulnerabilities

How it works (brief)

An attacker sends one unauthenticated POST to /wp-json/batch/v1 containing a deliberately malformed sub-request. That desynchronises the batch handler's internal arrays, letting a following sub-request execute under a different request's handler and bypass its permission check. This delivers an unsanitised scalar to author_exclude, producing a read-only UNION SQL injection. The attacker uses it to forge wp_posts rows, lets WordPress's oEmbed cache persist them as real rows, recasts those as customizer changesets to trigger a re-entrant parse_request in administrator context, creates a genuine admin via POST /wp/v2/users, and uploads a plugin containing a PHP web shell.

Bug one — the array desynchronisation

The batch handler maintains two arrays indexed by position: $validation (is this sub-request permitted?) and $matches (which handler does it dispatch to?). The security model depends entirely on slot n in one describing slot n in the other.

When a sub-request's path failed wp_parse_url(), the error branch appended it to $validation but never appended a placeholder to $matches. From that index onward the arrays are off by one, and every subsequent sub-request is validated against one set of rules and executed with a different request's handler. WordPress checks the lock on one door and opens the door next to it.

Bug two — sanitisation that depended on type

The author__not_in parameter was sanitised properly, but only inside an is_array() branch running array_map( 'absint', ... ). Passing a plain string skips that branch entirely; the string is then (array)-cast into a single element, imploded, and concatenated directly into the SQL WHERE clause.

// Sanitised — the guard rail applies
author__not_in = [1, 2, 3]
// Not sanitised — walks straight into the query
author__not_in = "1) AND 1=0 UNION ALL SELECT NULL,NULL..."

Over REST the parameter is exposed as author_exclude, a collection-only parameter normally sitting behind validation that would never pass a raw string. Bug one removes that guard. The 7.0.2 patch routes the value through wp_parse_id_list() unconditionally, so sanitisation no longer depends on input type.

Turning a read-only SQLi into a write primitive

This is the part worth studying. The injection is a UNION ALL SELECT — read-only. It cannot INSERT, cannot UPDATE, cannot create a user. Conventional wisdom caps an attacker in this position at data disclosure: dump the password hashes and leave.

The UNION injects fabricated wp_posts rows that exist only in the memory of one query. Those phantom posts are then fed through WordPress's normal content-rendering path, and when it encounters embeddable content it does what it always does — it caches the oEmbed result. That cache write is a genuine database INSERT, performed voluntarily by WordPress, using attacker-chosen content. The read-only primitive has become a write primitive.

The now-real cache post IDs are reinterpreted as customize_changeset posts. Combined with a forged post_type=request row, this triggers a re-entrant parse_request executing in administrator context — from which POST /wp/v2/users creates a real administrator, which installs a plugin, which drops a shell.

Attack chain

Indicators of Compromise

Exploitation is HTTP-borne and database-driven. The highest-value indicators are log responses and database artifacts, not file hashes — attackers routinely delete their admin account afterwards.

Log indicators

Database artifacts

Filesystem artifacts

Detection & hunting

Remediation checklist

A note on the severity scores

Published writeups quote contradictory CVSS numbers for wp2shell. That is not sloppy reporting — it reflects a genuine disagreement between two scoring bodies, and NVD has published no score of its own on either CVE.

References (authoritative)

• WordPress — GHSA-ff9f-jf42-662q: REST API batch-route confusion (github.com)
• WordPress — GHSA-fpp7-x2x2-2mjf: SQL injection in author__not_in (github.com)
• wordpress-develop — commit c8bdf1f: "REST API: Ensure errors in batch requests propagate" (github.com)
• WordPress.org — WordPress 7.0.2 Security Release (wordpress.org)
• NIST NVD — CVE-2026-63030 (nvd.nist.gov)
• NIST NVD — CVE-2026-60137 (nvd.nist.gov)
• CISA — Known Exploited Vulnerabilities Catalog (cisa.gov)