A Pre-Auth RCE in WordPress Core Puts 500 Million Sites at Immediate Risk

In July 2026, security researcher Adam Kues from the cybersecurity research organization Searchlight Cyber publicly disclosed a WordPress core-level vulnerability, designated wp2shell. This is a Pre-Authentication Remote Code Execution (RCE) vulnerability. Attackers do not need to log in or install any plugins; they can directly launch remote attacks on a native, default installation of WordPress.

Given that over 500 million active websites run on WordPress, the scope of this vulnerability's impact needs no further elaboration.

Vulnerability Overview

The danger level of wp2shell is high because the attack threshold is extremely low. Unlike the vast majority of WordPress security incidents, the problem this time lies within WordPress Core itself, not in third-party plugins or themes. Attackers require no preconditions; an anonymous user can achieve remote code execution on a default WordPress installation.

To leave a sufficient patching window for global site administrators, Searchlight Cyber has not currently disclosed the technical details of the vulnerability but has provided an online detection tool for administrators to check whether their sites are affected.

Affected Versions at a Glance

WordPress Version Range	Affected	Fixed Version
< 6.9.0	Not affected	—
6.9.0 – 6.9.4	Affected	6.9.5
7.0.0 – 7.0.1	Affected	7.0.2

If a site runs a version between 6.9.0 and 6.9.4, it needs to be upgraded to 6.9.5; sites running 7.0.0 or 7.0.1 need to be upgraded to 7.0.2. Versions below 6.9.0 are not affected by this vulnerability.

Why wp2shell Deserves High Attention

In recent years, WordPress security issues have mostly been concentrated in the plugin ecosystem. For example, a plugin with millions of downloads might have an SQL injection or XSS vulnerability, and administrators could resolve it by uninstalling or updating the plugin. The situation with wp2shell is completely different.

First, the vulnerability is located in WordPress Core. This means that regardless of what plugins a site has installed or what theme it uses, as long as the WordPress version is within the affected range, it can be exploited.

Second, this is a pre-authentication vulnerability. Attackers do not need to obtain any account passwords, nor do they need to acquire administrator credentials through social engineering or phishing. They can directly launch attacks against the target site. Once this zero-interaction attack surface is weaponized for automation, large-scale scanning and mass intrusion are only a matter of time.

Third, the impact base is enormous. WordPress holds approximately 43% of the global CMS market share, with hundreds of millions of active sites. Even assuming only 10% of sites are within the affected version range, the number of threatened sites is still in the tens of millions.

Complete Fix and Mitigation Solutions

Solution 1: Directly Upgrade WordPress (Recommended)

Upgrading is the best way to resolve the issue. WordPress 7.0.2 and 6.9.5 already include the fix patch for wp2shell.

Go to the WordPress backend → Dashboard → Updates, confirm the current version number, and execute the update operation. If the site has automatic updates enabled, it is recommended to log into the backend to confirm whether the update has been automatically applied.

Solution 2: Install the Disable WP REST API Plugin

If upgrading is temporarily not possible due to compatibility testing or other reasons, you can first install the Disable WP REST API plugin. This plugin will prohibit unauthenticated users from accessing the WordPress REST API, thereby cutting off the attack path for wp2shell.

It should be noted that this may affect site features that rely on the REST API (such as certain front-end rendering frameworks, headless WordPress architectures, or third-party integrations). A round of functional regression testing should be performed after installation.

Solution 3: Block Specific Paths via a WAF Firewall

If a WAF (Web Application Firewall) is deployed in front of the site, you can add rules to block the following two request patterns:

Block URL Path:

/wp-json/batch/v1

Block Query Parameter:

rest_route=/batch/v1

Both rules must be configured simultaneously. Blocking only one is insufficient to defend against this vulnerability, as the WordPress REST API supports accessing the same endpoint via both URL paths and query parameters.

Taking Nginx as an example, you can add the following to the server configuration block:

# Block the batch API path related to the wp2shell vulnerability
location ~* /wp-json/batch/v1 {
    deny all;
    return 403;
}

# Block requests accessing the batch API via query parameters
if ($query_string ~* "rest_route=/batch/v1") {
    return 403;
}

If using Apache with mod_rewrite enabled, you can add the following to .htaccess:

# Block batch API path requests
RewriteEngine On
RewriteRule ^wp-json/batch/v1 - [F,L]
RewriteCond %{QUERY_STRING} rest_route=/batch/v1 [NC]
RewriteRule .* - [F,L]

Solution 4: Deploy a Custom Security Plugin (Officially Recommended)

Searchlight Cyber has provided a piece of WordPress plugin code that can be directly deployed as an emergency measure. The logic of this code is to intercept all requests from unauthenticated users to the /batch/v1 endpoint; logged-in users are not affected.

Save the following code as disable-batch-api-for-unauth.php, upload it to the wp-content/plugins/ directory of the WordPress site via SSH or FTP, and then activate it on the backend plugins page.

<?php
/**
 * Plugin Name: Disable Unauthenticated REST Batch API
 * Description: Requires an authenticated WordPress user for REST batch requests.
 * Version: 1.0.0
 * Requires at least: 5.6
 * License: GPL-2.0-or-later
 */

defined( 'ABSPATH' ) || exit;

/**
 * Reject anonymous requests to the core REST batch endpoint.
 *
 * @param mixed           $result  Pre-calculated dispatch result.
 * @param WP_REST_Server  $server  REST server instance.
 * @param WP_REST_Request $request Current REST request.
 * @return mixed|WP_Error
 */
function wporg_require_authentication_for_rest_batch( $result, $server, $request ) {
    $route = untrailingslashit( $request->get_route() );

    if ( '/batch/v1' !== $route || is_user_logged_in() ) {
        return $result;
    }

    return new WP_Error(
        'rest_batch_authentication_required',
        'Authentication is required to use the batch API.',
        array( 'status' => 401 )
    );
}

add_filter( 'rest_pre_dispatch', 'wporg_require_authentication_for_rest_batch', -1000, 3 );

Code Explanation:

• rest_pre_dispatch is a filter hook in the WordPress REST API that runs before the actual request execution. The priority is set to -1000 to ensure this security check executes before other filters.
• untrailingslashit() removes any trailing slash from the end of the route to prevent interception failures due to path format differences.
• If the request route is /batch/v1 and the user is not logged in, it directly returns a WP_Error with an HTTP status code of 401.
• Logged-in administrators or editors can use the batch API normally without being affected.

This plugin is suitable as a temporary emergency measure; it is recommended to uninstall it after completing the version upgrade.

About the REST API Batch Endpoint

WordPress introduced the REST API batch feature in version 5.6 (endpoint path /batch/v1), allowing clients to package multiple REST API calls into a single HTTP request. The original design intention was to reduce network round trips and improve the performance of the front-end editor (such as the Gutenberg block editor).

This mechanism itself is not a security vulnerability, but the processing chain for batch requests is more complex than for single requests, involving permission verification, request splitting, response aggregation, and other steps. wp2shell exploits a flaw in this chain to achieve remote code execution.

For sites that do not depend on the batch API (the vast majority of standard WordPress sites do not directly call this endpoint), closing this endpoint during the temporary mitigation period will have almost no functional impact.

Security Management for Local Development Environments: From Patching to Infrastructure-Level Thinking

The wp2shell incident highlights a persistently overlooked issue: a large number of WordPress sites run in developers' local environments for development and testing, and security updates for these local instances cannot be ignored.

If using a local integrated development environment tool (such as ServBay, an AI-native development management platform that handles databases and PHP versions in one stop), the installation and version management of WordPress are usually centrally managed by the tool. Such tools have an advantage when handling security incidents: administrators can see the PHP version and WordPress version status of all local sites in a single control panel and perform batch upgrade operations, without having to log into each site's backend individually to click the update button.

Taking a step further, more and more developers are now starting to use Coding Agents (such as Claude Code, Cursor, Codex) to assist in developing and maintaining WordPress sites. In this working mode, the security management of API keys becomes another aspect that cannot be ignored. Developers typically have API keys for multiple AI services scattered across different project configuration files. Once a WordPress site is compromised, attackers may traverse the file system to find API keys stored in plaintext.

ServBay's AI Gateway exists to solve this problem. It centrally encrypts and stores all AI service API keys in a local gateway. Various projects and tools call AI services through a unified entry point, and the keys themselves are never written into project code or configuration files. Virtual keys can also be created.

Even if a WordPress instance is compromised, attackers cannot obtain the original keys for the AI services. This approach of moving credential management from the application layer down to the infrastructure layer can effectively reduce the blast radius after a credential leak.

Self-Check Checklist

After completing the fix, it is recommended to perform a full round of security self-checks on the site:

1. Confirm WordPress Version — Log into the backend and check the version number in the lower right corner of the dashboard to confirm it has been upgraded to 6.9.5 or 7.0.2 or above.
2. Use the Official Detection Tool — Visit the wp2shell online detection page provided by Searchlight Cyber and enter the site domain for scanning.
3. Check the User List — In the backend → Users, check if any unknown administrator accounts have been created.
4. Audit File Changes — Check the wp-content directory for any suspicious PHP files that have appeared recently.
5. Check Scheduled Tasks — Check via WP-Cron or server-level cron for any abnormal scheduled tasks that have been added.
6. Audit REST API Logs — If the site has request logging enabled, check for any unusual call records to the /batch/v1 endpoint.

Summary

wp2shell is one of the core-level vulnerabilities to emerge in the WordPress ecosystem in recent years. It does not depend on plugins, requires no authentication, and its attack surface covers all default installations of the affected versions. The good news is that the official WordPress response was very fast, and 6.9.5 and 7.0.2 already contain the fix patch.

For site administrators, upgrading immediately is the first choice. If upgrading is not possible in the short term, implementing temporary mitigation according to the WAF rules or custom plugin solutions provided above can also effectively block the attack path.

For developers who use local development environments to manage multiple WordPress instances, this incident is also a reminder: the security maintenance of local sites also needs to be incorporated into daily operational processes. Unified environment management tools and centralized credential management strategies can improve efficiency during security incident response.