WP2SHELL: Critical Pre-Auth RCE in WordPress Core

Technical Mechanics of the WP2SHELL Chain

The WP2SHELL threat is not a single bug, but rather an elegant and highly destructive vulnerability chain. It combines a REST API route and validation desynchronization vulnerability, tracked as CVE-2026-63030, with a core SQL injection vulnerability, tracked as CVE-2026-60137, in the main WordPress query engine class. The exploit bypasses authentication barriers and manipulates SQL queries, culminating in remote code execution on the host operating system.

The Role of CVE-2026-63030: REST API Route Confusion

The WordPress REST API batch endpoint, located at /wp-json/batch/v1, is designed to handle multiple nested sub-requests inside a single HTTP request. This optimization improves performance for dashboard interactions and mobile apps. However, a severe logical flaw exists in the batch dispatcher framework.

When parsing incoming nested sub-requests, the dispatcher evaluates them sequentially. An attacker can craft a payload where the very first sub-request is designed to fail validation immediately, such as by passing an invalid target path like http://:. When this validation failure occurs, the dispatcher generates a WP_Error object. Due to an implementation error, this failed request is excluded from the internal match array but retained in the main dispatcher index. This mismatch creates an off-by-one array offset desynchronization.

Consequently, subsequent sub-requests in the batch queue are evaluated against the dispatch and permission callbacks of the previous sub-request. This logical flaw allows an unauthenticated attacker to completely bypass route-level access restrictions and execute actions reserved for authenticated administrative sessions.

The Role of CVE-2026-60137: Core SQL Injection

Once the route restrictions are bypassed, the attacker dispatches a nested sub-request directly to the core query engine, specifically targeting the WP_Query class. This query engine handles database searches and post fetching. The vulnerability lies within the processing of the author__not_in parameter, which is designed to exclude specific author IDs from query results.

Normally, this parameter expects an array of integer values. However, if an attacker passes a raw string instead of an array, the core type check functions are bypassed. The database abstraction layer fails to sanitize the input properly when a string is received in this specific context, dropping the raw, attacker-controlled string directly into the SQL query string. This results in an unauthenticated, blind, or time-based SQL injection vulnerability.

The Path to Remote Code Execution

Through the SQL injection vector, attackers can execute commands to retrieve sensitive data from the database. This includes extracting administrator session hashes, database credentials, and altering tables. After acquiring these credentials, the attacker logs in as an administrator and uploads a malicious theme or plugin containing a PHP-based backdoor, commonly known as a webshell. This backdoor allows the attacker to execute arbitrary shell commands on the underlying web server, resulting in a full system compromise.

This remote code execution chain is highly reliable on default WordPress configurations, especially where a persistent object cache like Redis or Memcached is not utilized to abstract database interactions.

Threat Actor Landscape and MITRE ATT&CK Mapping

Shortly after the public disclosure of WP2SHELL, cybercrime networks and automated scanning ecosystems integrated the exploit chain. Mass-exploitation groups, particularly Webshell Access Brokerages, actively scan the internet to compromise vulnerable WordPress instances. These groups establish persistent backdoors and sell access to ransomware syndicates or initial access brokers.

Practical Detection and Validation Procedures

Security engineers can safely test their websites to determine if the routing engine exhibits the off-by-one desynchronization behavior. The following safe proof-of-concept probe simulates the validation mismatch without executing malicious database commands.

POST /?rest_route=/batch/v1 HTTP/2.0
Host: target-website.com
Content-Type: application/json

{
  "validation": "normal",
  "requests": [
    {"method": "POST", "path": "http://:"},
    {"method": "DELETE", "path": "/wp/v2/categories/0"},
    {"method": "POST", "path": "/wp/v2/block-renderer/core/paragraph"}
  ]
}

If the response indicates that the routing engine attempted to process the restricted DELETE or POST commands without returning standard authorization errors, the WordPress core is vulnerable to route desynchronization. In addition to validation, active monitoring at the network layer is essential to detect ongoing exploitation attempts.

Web Application Firewall (WAF) Detection Logic

To block or alert on incoming exploit attempts, security teams can implement rules targeting unauthenticated access to the batch routes. The following ModSecurity-compatible rules identify and block the typical batch request structures:

# Block REST API Batch Endpoint accesses from unauthenticated sources
SecRule REQUEST_URI "@contains /wp-json/batch/v1" \
    "id:2026101,phase:2,deny,status:403,msg:'WP2SHELL REST API Batch Exploit Blocked'"

# Block alternative Query String Route format
SecRule ARGS:rest_route "@contains /batch/v1" \
    "id:2026102,phase:2,deny,status:403,msg:'WP2SHELL REST Query Batch Exploit Blocked'"

Log Hunting and SIEM Queries

Security Operations Centers can use log search queries to hunt for historical exploitation attempts or unauthorized scanning. The following query helps identify traffic directed to the vulnerable batch endpoints:

(uri_path="/wp-json/batch/v1" OR uri_query="*rest_route=/batch/v1*") AND method="POST"

Analysts should inspect the payloads of matching requests for nested structures containing abnormal paths or string inputs assigned to variables like author__not_in.

Containment, Mitigation, and Remediation Strategy

The most effective method to mitigate the WP2SHELL vulnerability chain is to update WordPress Core immediately. The WordPress Security Team has released updates to address both core vulnerabilities. Organizations must verify that their instances run the correct secured versions:

• If your organization utilizes the 7.0 branch, update to version 7.0.2 immediately.

• If your organization utilizes the 6.9 branch, update to version 6.9.5 immediately.

• If running legacy 6.8 installations, update to version 6.8.6 to eliminate the core SQL injection vulnerability.