BitFire blocks CVE-2026-63030 with verified-browser POST protection, SQL injection detection, and RASP prevention of administrator account creation.
wp-includes/rest-api/class-wp-rest-server.php and wp-includes/class-wp-query.phpWP2Shell is a critical, unauthenticated remote code execution chain in WordPress Core, but BitFire stops it at three independent points. First, bot blocking and browser verification prevent unknown bots, automated exploit code, and browsers that have not passed JavaScript validation from POSTing the malicious request to WordPress. Second, BitFire's WAF detects the SQL injection payload inside the POST body and blocks it before it reaches the vulnerable WordPress code. Third, BitFire PRO RASP follows the request during execution and prevents the exploit from creating an administrator account. Each layer can stop CVE-2026-63030 independently, providing practical zero-day protection even before a vulnerability has been seen or patched. BitFire PRO RASP adds the critical final safeguard directly inside the WordPress runtime.
The affected component, attack path, and practical risk for WordPress websites.
Three independent BitFire layers stop WP2Shell: reject the unverified POST, block the SQL injection, and prevent administrator account creation at runtime.
Research details, affected versions, exploitation behavior, and remediation guidance.
WP2Shell is a critical pre-authentication WordPress Core exploit chain. CVE-2026-63030 confuses route handling in the `/wp-json/batch/v1` REST API endpoint, allowing attacker-controlled input to bypass normal validation. The request then reaches CVE-2026-60137, an SQL injection vulnerability in the `author__not_in` parameter of WP_Query. That SQL injection is used to manipulate WordPress state and create an unauthorized administrator account, after which the attacker can upload malicious PHP and execute code. BitFire maps a separate protection layer to every major stage: bot and browser verification at the POST boundary, WAF inspection before vulnerable code, and RASP enforcement while the request executes.
WP2Shell must deliver its exploit through a POST request. BitFire's first layer prevents that request from reaching WordPress when the client has not earned permission to POST. Unknown bots, vulnerability scanners, scripted exploit tools, and other automated clients are denied unless they have been specifically allowed. A client presenting itself as a normal browser must first pass BitFire's JavaScript browser validation; until that verification succeeds, it cannot POST data to WordPress. This policy stops both automated exploit code and unverified browser sessions before PHP, the REST API, or any vulnerable WordPress function processes the payload. Legitimate integrations can be explicitly allowed without opening POST access to every bot on the Internet.
If a malicious request passes the client-verification layer, BitFire's Web Application Firewall independently inspects the POST data. WP2Shell must carry an SQL injection payload that abuses `author__not_in`; BitFire's normal SQL injection rules recognize that hostile SQL content and block the entire request. The payload therefore never reaches the vulnerable WP_Query code and cannot begin the database manipulation and privilege-escalation chain. This is not a special virtual patch written after WP2Shell became public. It is existing, out-of-the-box SQL injection protection doing exactly what it was designed to do against a previously unknown WordPress Core vulnerability.
Out-of-the-box WAF behavior matters during a zero-day because administrators cannot deploy a vulnerability-specific rule before the vulnerability is known. For this WP2Shell request, the default Cloudflare and Wordfence WAF protections evaluated do not provide out-of-the-box SQL injection blocking for the malicious POST payload. BitFire's standard SQL injection detection blocks the exploit without waiting for a CVE-specific signature or emergency rule. Cloudflare or Wordfence behavior may differ when administrators purchase additional rulesets, create custom rules, or change default configuration, but those changes are not the same as automatic protection available before disclosure.
BitFire PRO RASP supplies the final independent control inside the WordPress runtime. RASP follows the request as PHP and WordPress execute it rather than relying only on its appearance at the network edge. If an attacker somehow bypasses browser verification and WAF inspection—or if those protections have been disabled—RASP follows the WP2Shell execution path and prevents the SQL injection chain from creating an administrator account. Without that unauthorized administrator, the attacker cannot complete the privilege escalation, log in with full control, upload a malicious plugin, and turn the vulnerability into remote code execution. The exploit is stopped at the action that matters, even after entering WordPress.
These controls are independent rather than three names for the same signature. Bot blocking asks whether an automated client is allowed to POST. Browser verification asks whether an apparent browser has successfully executed the JavaScript challenge before POSTing. The WAF examines request content and blocks the SQL injection payload. RASP monitors what the request attempts to do during execution and prevents creation of the administrator account. WP2Shell can succeed only if the malicious POST arrives, the SQL injection reaches vulnerable code, and privilege escalation completes. BitFire interrupts all three conditions, demonstrating how layered security protects WordPress sites from never-before-seen vulnerabilities instead of waiting for a vulnerability-specific rule.
CISA added both CVEs to its Known Exploited Vulnerabilities catalog, and public proof-of-concept code exists. Patching does not remove an attacker who exploited the site earlier. Review BitFire events and server access logs for blocked or unusual POST requests to `/wp-json/batch/v1` and `?rest_route=/batch/v1`. Audit every WordPress administrator account, active session, recently added plugin, unexpected PHP file, scheduled task, and modified Core file. If compromise is suspected, preserve logs, isolate the site, remove unauthorized accounts and persistence, replace Core with known-good files, rotate WordPress salts and all hosting, database, SSH, SFTP, and administrator credentials, and restore from a verified clean backup when appropriate.
WP2Shell shows why protecting only the network edge is not enough. A request can evade bot controls, bypass a WAF rule, or exploit vulnerable code that has never been seen before. Installing BitFire PRO RASP adds protection where the attack ultimately has to succeed: inside the WordPress PHP runtime. RASP follows requests as they execute, recognizes dangerous privilege-changing behavior, and prevents WP2Shell from creating the administrator account required to complete the compromise. It continues protecting the site even when an attacker reaches WordPress through another path or when the first two security layers are unavailable. Combined with BitFire's bot blocking, JavaScript browser verification, and SQL injection WAF, PRO RASP gives WordPress administrators three independent barriers against remote code execution. Install BitFire PRO RASP on your WordPress server to stop attacks based on what they do—not only whether their signature was already known.
The relevant source is located in wp-includes/rest-api/class-wp-rest-server.php and wp-includes/class-wp-query.php.
// Batch validation could advance without a matching route entry.
if ( is_wp_error( $single_request ) ) {
$has_error = true;
$validation[] = $single_request;
continue;
}
// A scalar author__not_in value could reach the SQL query unsanitized.
$author__not_in = implode( ',', (array) $query_vars['author__not_in'] );
$where .= " AND {$wpdb->posts}.post_author NOT IN ($author__not_in) ";// Keep route matches aligned with validation results.
if ( is_wp_error( $single_request ) ) {
$has_error = true;
$matches[] = $single_request;
$validation[] = $single_request;
continue;
}
// Parse every author__not_in value as a list of integer IDs.
$author__not_in_id_list = wp_parse_id_list( $query_vars['author__not_in'] );
if ( count( $author__not_in_id_list ) > 0 ) {
sort( $author__not_in_id_list );
$where .= sprintf(
" AND {$wpdb->posts}.post_author NOT IN (%s) ",
implode( ',', $author__not_in_id_list )
);
}BitFire protects WordPress servers on day zero—before a vulnerability is publicly known and before other vendors have time to develop signatures or patches.
Bot controls and browser verification stop untrusted automated clients before previously unknown exploit code reaches WordPress.
General WAF protections identify dangerous request behavior and hostile payloads without waiting for a vulnerability-specific signature.
RASP follows execution inside PHP and prevents unauthorized changes to protected files, accounts, and database content.
BitFire combines bot controls, request inspection, malware detection, and runtime protection in one WordPress security platform.