Critical wp2shell RCE Vulnerability – Complete Details Including PoC and Active Exploitation

Overview

A critical pre-authentication remote code execution (RCE) vulnerability chain nicknamed “wp2shell” has been disclosed in WordPress Core, putting an estimated 500 million-plus websites at risk of full takeover by completely unauthenticated attackers.

The chain combines two separately tracked flaws CVE-2026-63030, a REST API batch-route confusion issue, and CVE-2026-60137, a SQL injection vulnerability in the author__not_in parameter of WP_Query to achieve full server compromise on a stock WordPress installation with zero plugins installed.

WordPress powers roughly 43 percent of all websites globally, making this one of the most consequential CMS security disclosures in recent memory.

What sets wp2shell apart from typical WordPress security issues is that it requires no preconditions whatsoever: no valid account, no vulnerable plugin, no special configuration, and no user interaction. Any anonymous attacker capable of reaching a vulnerable WordPress instance over the network can compromise it out of the box.

Discovery: An AI Model Found It for $25

The flaw was uncovered by security researcher Adam Kues of Searchlight Cyber’s Assetnote research team, using an unconventional method: an AI-driven vulnerability research project powered by OpenAI’s GPT-5.6 Sol Ultra model.

Kues adapted a prompt originally published by OpenAI one that had been used to help the model solve the “Cycle Double Cover” mathematical conjecture and repointed it at the WordPress core codebase, instructing the model to hunt for a pre-authentication-to-RCE chain using up to four parallel research agents over at least six hours.

Kues explicitly instructed the model not to consult changelogs, git history, or the internet to diff against patched versions, forcing it to discover the bug purely through first-principles code analysis. The model was also told it could clone and audit third-party dependencies if a full chain required bugs in underlying libraries such as PHP or MySQL itself.

The result: Sol identified a fully pre-authentication SQL injection within the codebase, which Kues initially doubted given WordPress’s decade-long track record without major pre-auth vulnerabilities. After validating the SQLi against a live test instance by extracting an administrator’s email address, Kues asked the model whether it could escalate the bug into full RCE.

Roughly four hours later, the model responded affirmatively with a working escalation chain. Total compute cost for the entire discovery, using a $200-per-month subscription, was approximately $25 on a pro-rated usage basis.

Kues noted that understanding and documenting the AI-generated exploit chain took him considerably longer than the model took to develop it, calling the post-exploitation technique “completely absurd” in its sophistication.

Technical Breakdown of the Exploit Chain

The Batch API Desynchronization Bug (CVE-2026-63030)

The root flaw lives in the WordPress REST API batch endpoint (/wp-json/batch/v1), a feature introduced in WordPress 5.6 back in 2020 that allows multiple virtual API requests to be bundled into a single call.

Under normal operation, each individual REST request passes through a four-step pipeline: parameter validation, parameter sanitization, a permission callback, and finally the endpoint’s execution callback.

The batch endpoint breaks this pattern by running validation and execution as two separate loops rather than processing each request serially. If one request in the batch is malformed, the validation array records the error but the matching array of resolved handlers is not updated in sync, due to a continue statement that skips array insertion on one side but not the other.

This desynchronizes the index alignment between the two arrays, so that when execution runs, request N’s validated parameters can end up applied against request N+1’s actual handler completely bypassing intended parameter sanitization. This flaw is classified under CWE-436 (interpretation conflict) and carries a CVSS v3.1 base score of 7.5 (High).

The SQL Injection Sink (CVE-2026-60137)

The desync bug alone grants nothing without a vulnerable sink to exploit. That sink is the author__not_in parameter of WP_Query, WordPress’s core class for building database queries. When the parameter is submitted as an array, WordPress sanitizes each value using absint(). But if it is submitted as a raw scalar string instead, the sanitization ste

p is skipped entirely, and the value is interpolated directly into a raw SQL NOT IN clause. Ordinarily this path is unreachable, since the public-facing author_exclude parameter is validated as an array of integers before ever reaching author__not_in.

The batch-route desync bug bypasses that validation, allowing a scalar SQL payload to slip through untouched and because the underlying endpoint only supports GET requests (which the batch API does not natively allow), the exploit uses a recursive, nested batch call to smuggle the GET request through the desync mechanism a second time.

This vulnerability is classified under CWE-89 (SQL injection) and rated 9.1 (Critical) on the CVSS v3.1 scale.

Escalating a Read-Only SQLi to Full RCE

The SQL injection alone is a “SELECT-only” data-leak bug that cannot directly retrieve crackable plaintext credentials, since WordPress hashes passwords in the database. The escalation path devised by the AI model exploited a chain of secondary WordPress behaviors:

• In-memory post cache poisoning: The SQLi’s UNION-based injection can fabricate fake WP_Post objects that get cached in memory for the duration of a request.
• Embed cache abuse: WordPress’s shortcode caches referenced local posts as oembed_cache rows in the database without verifying the referenced post ID actually exists, letting an attacker plant otherwise-legitimate-looking database rows.
• Cache/database reconciliation exploitation: When WordPress detects a mismatch between the in-memory and database-cached versions of a post, it favors the in-memory (attacker-controlled) values, effectively “popping” fabricated rows into existence as arbitrary post types.
• Customize changeset hijack: A customize_changeset post type stores drafted site-setting changes tagged with a user_id, and applying it temporarily assigns that user’s identity via wp_set_current_user() including administrator privileges, if user_id is forged as 1.
• Cycle-detection gadget: WordPress’s post-parent hierarchy cycle detection, meant to prevent infinite loops, can be abused to trigger secondary wp_update_post() calls that expose otherwise-protected fields like post_content.
• Hook replay via parse_request: While briefly holding administrator context, the attacker triggers the parse_request action hook, which replays the entire original batch request this time with elevated privileges allowing creation of a new, persistent administrator account.

With a rogue administrator account in hand, the attacker logs in normally and uploads a malicious plugin ZIP file, achieving full remote code execution on the server.

Kues stated the full exploit chain was produced by the AI model in just over 10 hours and expressed confidence that no human researcher could have discovered and completed the chain unaided within that timeframe.

Affected and Patched Versions

Data compiled from WordPress security advisories and vendor writeups.

The 6.8.x branch carries only the SQL injection component and is not exposed to the full unauthenticated RCE chain, because the batch-route confusion bug (CVE-2026-63030) was only introduced in WordPress 6.9.

Fixed releases are WordPress 6.8.6, 6.9.5, and 7.0.2, along with 7.1 Beta 2 for the pre-release branch.

Disclosure and Patch Timeline

WordPress shipped emergency security releases on July 17, 2026, addressing both vulnerabilities simultaneously. Given the severity, the WordPress.org security team took the rare step of enabling forced automatic updates via the platform’s auto-update system for all supported installations running affected versions a mechanism typically reserved for crisis-level situations.

Administrators are still urged to manually verify that the forced update actually completed, since auto-update settings, custom deployments, or managed hosting configurations can prevent it from applying.

CVE-2026-60137 was independently reported to the WordPress security team by researchers TF1T, dtro, and haongo, and was patched in the same release cycle as the Kues-discovered RCE chain.

Searchlight Cyber initially withheld full technical exploitation details to give site owners a window to patch over the weekend following disclosure, publishing only a free, non-intrusive public scanner at wp2shell[.]com so administrators could check their exposure.

Public PoC Release and Active Exploitation

Despite the researcher’s disclosure delay, public proof-of-concept exploits began circulating on GitHub within roughly 24 hours. Searchlight Cyber noted that during the withholding period, two other groups Calif and Hacktron had already independently reproduced the full exploit chain before additional PoCs surfaced publicly.

Multiple security vendors confirmed early real-world exploitation attempts. watchTowr CEO Benjamin Harris told reporters the firm was “already seeing PoC exploits in circulation” with “the first signs of exploitation in the wild”.

Hexastrike’s head of Cyber Threat Intelligence, Maurice Fielenback, stated the firm continued to see “attempted and successful wp2shell exploitation” and had “handled several confirmed and suspected incidents” after flagging initial exploitation attempts the prior Sunday.

Some publicly released exploit variants demonstrate extracting administrator password hashes via the SQL injection component and brute-forcing credentials offline, while others replicate the researcher’s full pre-auth RCE chain without needing to crack any password at all.

Cloudflare separately reported that the vulnerable code path is specifically reachable when a persistent object cache is not in use on the target server, and the company deployed WAF protections against both CVEs across all customer plans, including its free tier, for proxied domains.

Upgrading WordPress core to a patched version is described by every major vendor as the only complete fix. Recommended remediation steps include:

• Update immediately to WordPress 7.0.2, 6.9.5, or 6.8.6 depending on the currently running branch, either via the WordPress Dashboard’s Updates screen or by downloading the release directly from WordPress.org.
• Verify the forced automatic update actually applied on every managed site, since disabled auto-updates or custom deployments can block the forced push.
• Use the free wp2shell[.]com scanner, or manually query the batch endpoint, to confirm current exposure status.
• If immediate patching is not feasible, block both /wp-json/batch/v1 and the query-string variant ?rest_route=/batch/v1 at the WAF or web-server level filtering only the path form leaves the site exploitable via the query-string route.
• Install a plugin or must-use plugin that rejects anonymous REST API batch requests, such as via the rest_pre_dispatch hook, as an interim measure.
• Review logs for suspicious requests to the batch endpoint, check for unexpected new administrator accounts, and inspect for unfamiliar plugins, themes, or altered rows in wp_posts and wp_options tables on any site that ran an affected version.

Security vendors emphasize that WAF-level blocking and REST API restriction plugins are strictly temporary stopgaps that may disrupt legitimate site functionality, and that core version upgrades remain the only durable remediation.

Broader Implications for AI-Assisted Vulnerability Research

The wp2shell disclosure is notable beyond its technical severity because of how it was found. Kues’s account signals a shift in vulnerability research economics: a $25 AI compute spend uncovered a bug class that, according to Searchlight Cyber’s own framing, exploit brokers have historically paid up to $500,000 to acquire.

Kues argued that the exploitation techniques chained together by the model including recursive batch-call abuse, cache-desynchronization gadgets, and hook-replay privilege escalation reflected creative reasoning he had previously assumed was exclusive to experienced human researchers.

He suggested that as AI models take on more of the technical exploit-development workload, human security researchers’ roles may shift toward higher-level direction: choosing targets, crafting research prompts, and steering investigation strategy rather than manual code auditing.