WP2Shell (CVE-2026-63030): How a WordPress API Bug Becomes a Shell

WordPress checked the request, everything looked fine, and then it executed a different one.

That small mix-up in the REST API gave attackers access to a SQL injection vulnerability they should never have been able to reach. From there, they could extract database information, create an administrator account and eventually execute code on the server.

Meet WP2Shell, a critical vulnerability chain affecting WordPress core.

Two Bugs Led to One Very Bad Outcome

WP2Shell was disclosed on 17 July 2026 by security researcher Adam Kues of Assetnote / Searchlight Cyber.

The attack combines two vulnerabilities in WordPress core:

CVE-2026-63030 is a route-confusion vulnerability in WordPress's REST API batch endpoint. It allows a request to reach a handler different from the one used to validate it.

The underlying SQL injection also affects WordPress 6.8, although that branch isn't vulnerable to the same unauthenticated WP2Shell chain. A site doesn't need a poorly maintained plugin or an unusual custom configuration to be exposed.

The API Checked the Wrong Request

To understand the vulnerability, start with a useful WordPress feature: batch requests.

WordPress's REST API allows applications to interact with posts, users and other site resources over HTTP.

The batch endpoint, accessible through /wp-json/batch/v1, lets a client bundle several API operations into a single request.

Instead of sending multiple separate requests, an application can ask WordPress to process them together. Each operation should still be checked against the rules of the endpoint it targets.

A request for user information, for example, should be validated and executed according to the requirements of the users endpoint. That's where WP2Shell found its opening.

One Index Out of Place

The vulnerable batch handler maintained information about matched routes and their validation results in separate arrays.

Under normal conditions, those arrays remained aligned. The entry describing a validated request corresponded to the handler that would eventually execute it.

A specially malformed request could disrupt that relationship.

Certain invalid paths affected the validation results without producing a corresponding matched route. The arrays then fell out of step.

When WordPress dispatched the batched operations, a request could be processed by the wrong handler.

In the researchers' demonstration, the confusion allowed input associated with the /wp/v2/users route to reach functionality belonging to /wp/v2/posts.

The users endpoint didn't validate a particular unexpected parameter because it wasn't part of the expected request.

The posts handler, however, could pass that same parameter into a database query.

WordPress had effectively examined the request under one set of rules before letting another part of the application process it.

The result was a path around validation and permission checks that would ordinarily protect the vulnerable query.

The flaw is an example of an interpretation conflict, where different components disagree about what a request represents.

And the query waiting on the other side had problems of its own.

The SQL Injection Was Already There

The second vulnerability, CVE-2026-60137, affects how WordPress builds certain database queries.

The public-facing posts API supports an author_exclude parameter, which allows a request to exclude posts belonging to selected authors.

Internally, WordPress maps that parameter to the author__not_in argument used by WP_Query.

In vulnerable versions, insufficient sanitisation could allow specially crafted input to interfere with the resulting SQL query.

Ordinarily, reaching that behaviour from an unauthenticated request was constrained by the surrounding API validation and routing. But WP2Shell changed the situation.

By exploiting the batch-route confusion, an attacker could pass malicious input into the vulnerable query without authenticating.

The two flaws complemented each other:

• CVE-2026-63030 allowed the request to bypass the intended validation path.
• CVE-2026-60137 allowed attacker-controlled input to alter the database query.

Together, they exposed database operations that should never have been reachable through that unauthenticated workflow.

For anyone learning how SQL injection works, the underlying principle is familiar. Applications become vulnerable when data supplied by a user can influence the structure of a database query.

Our guide to SQL injection and safe lab practice explains the different techniques attackers use to extract information through these mistakes.

WP2Shell demonstrates how an unrelated routing bug can make an existing SQL injection substantially more dangerous.

The Database Starts Answering Questions It Shouldn't

With the SQL injection reachable, the next stage involves extracting information.

One technique demonstrated in the WP2Shell training room is boolean-blind SQL injection.

Rather than returning the requested database value directly, this technique allows an attacker to infer information from differences in the application's responses.

Think of it as a series of yes-or-no questions.

The attacker tests a condition against a database value and observes whether the response indicates that the condition is true or false.

By narrowing the possibilities through repeated comparisons, the attacker can reconstruct information character by character.

A binary-search approach makes the process more efficient by reducing the number of guesses needed.

In the WP2Shell scenario, this technique can expose information such as WordPress version details and administrator account data, including password hashes stored in the database.

But the researchers didn't need to stop at stealing information.

The same vulnerability also created opportunities to manipulate the data WordPress believed it had retrieved.

From Reading the Database to Inventing Its Contents

SQL injection is often associated with extracting private records, bypassing authentication or changing database contents.

Using a UNION SELECT operation, an attacker can influence the rows returned by a database query.

The resulting data can be made to resemble legitimate WordPress post records, even though the attacker hasn't directly inserted those records into the underlying posts table.

The query results are fabricated, and WordPress may then process them as though they came from real database records. The attack chain exploits the consequences of that trust.

When a Fake Post Becomes Something More

WordPress contains features that process post content and maintain related information, including cached data used for embedded content.

The researchers showed how forged query results could interact with this processing and lead to persistent changes through legitimate WordPress functionality.

The chain then reached another WordPress feature: Customizer changesets.

Customizer changesets are records used to store and publish changes to a site's configuration and appearance.

In the vulnerable workflow, attacker-influenced data could be treated as a trusted changeset. The subsequent processing allowed the attack to cross another security boundary.

Instead of remaining a manipulated database result, the forged data could influence privileged application behaviour.

The demonstrated outcome was the creation of a new administrator account.

The attacker didn't have to guess the existing administrator's password or convince someone to approve the account.

WordPress's own processing supplied the route to administrative access.

That is what makes the chain particularly interesting. A read-oriented SQL query became the starting point for an application-level write and privilege escalation through several interacting features.

Once the attacker controlled an administrator account, the final step became much more straightforward.

An Administrator Account Is a Dangerous Place to End Up

A WordPress administrator normally has extensive control over a site.

Depending on the deployment and its configured permissions, that can include installing or managing plugins.

Plugins are PHP code packages that extend WordPress functionality. They can also become a route to server-side code execution when an attacker is able to introduce malicious PHP code.

In the demonstrated WP2Shell chain, the newly created administrator account enabled the attacker to reach that capability and deploy a webshell.

A webshell is a malicious server-side script that can provide an attacker with a way to execute commands through web requests.

Successful execution generally runs with the permissions available to the web server process.

Those permissions determine what files, configurations and connected resources may be accessible.

The result is remote code execution without prior authentication to WordPress.

There is also an important difference between WP2Shell and the related XSS2Shell vulnerability.

XSS2Shell relies on an authenticated administrator opening a crafted link.

WP2Shell's demonstrated chain does not require that interaction. The attacker can initiate the relevant API requests remotely, provided the installation is vulnerable and the exploit's required conditions are met.

That absence of a user-interaction requirement helps explain the critical severity.

How to Spot WP2Shell Activity

A successful compromise may leave traces in several places: web server logs, WordPress activity records, database changes and the filesystem.

The investigation should begin with the installation's patch status and available request telemetry.

Watch the Batch API

The endpoint involved in the attack is:

Depending on the site's configuration, equivalent requests may use an alternative REST routing format such as:

Requests to these paths are not automatically malicious. The batch API is a legitimate WordPress feature.

What deserves investigation is unusual activity involving nested batch operations, malformed request paths or unexpected SQL-related content.

Look for Changes That Don't Match Normal Administration

If exploitation is suspected, examine the site for:

• Unexpected administrator accounts or account creation events.
• Unfamiliar plugins and recently introduced PHP files.
• Suspicious changeset or cached-content activity, where appropriate records are available.
• Unexplained access to administrative functions through newly created accounts.
• Unusual web requests involving the REST API and subsequent server-side activity.

These findings require context. A new administrator or plugin installation may be legitimate, so verify changes against authorised activity.

Public proof-of-concept tools may use recognisable names or file paths, but those indicators can easily be changed.

Follow the Wrong Request All the Way to a Shell

Understanding WP2Shell means following the attack through each trust boundary.

The route confusion exposes a query that should be protected. The SQL injection makes database information accessible. Forged query results then interact with WordPress's internal processing, eventually enabling an administrator account and code execution.

The WP2Shell: CVE-2026-63030 room brings that chain into a hands-on environment.

You'll investigate the vulnerable REST API behaviour, practise the SQL injection techniques used to extract database information and explore how the application-level logic flaws combine to produce a much more serious outcome.

The room also covers detection and mitigation, giving defenders an opportunity to connect the technical exploit to the evidence they might encounter during an investigation.