How to Check Whether Your Site Is Exposed
Start with the version number. In wp-admin, the WordPress version shows on the Updates screen and in the footer of most admin pages; on the command line,
wp core version tells you instantly. If you are on 6.8.6, 6.9.5, 7.0.2 or later, you are patched.
If you want independent confirmation, the researchers who discovered the flaw (Searchlight Cyber) operate a free checker at
wp2shell.com. For security teams, a defensive detection template for the open-source nuclei scanner was published alongside the disclosure. It confirms exposure with a timing-based check rather than extracting any data. Only ever run security tests against systems you own or have explicit permission to test.
If you cannot patch immediately, the stopgap is to block access to the batch endpoint at your application or CDN layer. Cloudflare deployed managed rules for both flaws across all plans, including free ones. A block buys time; it is not a fix.
Finally, and this is the part most coverage skips:
patching does not evict an attacker who got in before you patched. If your site sat unpatched during the exploitation window, audit it. Look for administrator accounts you do not recognize, plugins or must-use plugins you did not install, and unexpected files in
wp-content/uploads.
If You Cannot Update: Blocking the Batch Endpoint
"Just block the endpoint" is easier said than done, because it answers to two addresses:
/wp-json/batch/v1 and
?rest_route=/batch/v1. Here are two practical ways to cover both, one in WordPress itself and one at the edge.
Option 1: a must-use plugin (PHP). Drop a single file into
wp-content/mu-plugins/, for example
block-rest-batch.php. Must-use plugins load automatically on every request, with no activation step and no way to disable them from wp-admin:
block-rest-batch.php
<?php
/**
* Plugin Name: Block REST Batch Endpoint (WP2Shell stopgap)
* Description: 403 for anonymous requests to the REST API batch
* endpoint. Remove after updating to 6.8.6, 6.9.5, or 7.0.2.
*/
add_filter( 'rest_authentication_errors', function( $result ) {
if ( ! empty( $result ) ) {
return $result;
}
$uri = isset( $_SERVER['REQUEST_URI'] ) ? $_SERVER['REQUEST_URI'] : '';
$rest = isset( $_GET['rest_route'] ) ? $_GET['rest_route'] : '';
$is_batch = ( false !== strpos( $uri, '/wp-json/batch/v1' ) )
|| ( false !== strpos( $rest, '/batch/v1' ) );
if ( $is_batch && ! is_user_logged_in() ) {
return new WP_Error(
'rest_batch_disabled',
'The REST API batch endpoint is disabled on this site.',
array( 'status' => 403 )
);
}
return $result;
} );
The
is_user_logged_in() check matters: the block editor and some admin tooling use the batch endpoint legitimately, so only anonymous traffic is blocked. Verify by requesting
/wp-json/batch/v1 in a private browser window; you should get a 403. Delete the file once you are on a fixed version.
Option 2: a CloudFront behavior (edge). Blocking at the CDN keeps the traffic off your server entirely. The path form is a one-minute job with a CloudFront Function:
- In the CloudFront console, go to Functions and create a function (viewer request type) that simply refuses the request:
viewer-request.js
function handler(event) {
// Attach (viewer request) to a behavior with
// path pattern /wp-json/batch/v1*
return {
statusCode: 403,
statusDescription: 'Forbidden',
body: { encoding: 'text', data: 'The batch endpoint is disabled.' }
};
}
- Open your distribution, go to Behaviors, and create a new behavior with path pattern
/wp-json/batch/v1*, above the default behavior, pointing at your normal origin with your normal cache policy.
- Under Function associations on that behavior, attach the function as a viewer request function and save.
Path patterns do not match query strings, so the
?rest_route=/batch/v1 form needs a second function attached to the default behavior:
default-viewer-request.js
function handler(event) {
// Attach (viewer request) to the default behavior
var q = event.request.querystring;
var cookies = event.request.cookies || {};
var loggedIn = Object.keys(cookies).some(function(name) {
return name.indexOf('wordpress_logged_in') === 0;
});
if (!loggedIn && q.rest_route && q.rest_route.value.indexOf('/batch/v1') === 0) {
return {
statusCode: 403,
statusDescription: 'Forbidden',
body: { encoding: 'text', data: 'The batch endpoint is disabled.' }
};
}
return event.request;
}
The cookie check keeps the endpoint working for your logged-in editors while refusing anonymous traffic, and requests that do not match pass through unchanged. Once WordPress is updated, detach both functions and remove the extra behavior.
How the chain fits together: a route confusion in the batch endpoint opens the door; SQL injection does the work; the end result is a remote shell on the server.