An anonymous HTTP request can execute code on WordPress sites running recent versions. The vulnerability exists in WordPress core, making even bare installations with no plugins exploitable. WordPress released emergency patches on Friday, shipping versions 6.9.5 and 7.0.2 through forced automatic updates.

Two Vulnerabilities Create Critical Attack Chain

The wp2shell attack combines two distinct security flaws, each now assigned CVE identifiers. CVE-2026-63030 involves REST API batch-route confusion, while CVE-2026-60137 represents a SQL injection vulnerability in WordPress core. When chained together, these vulnerabilities allow anonymous attackers to achieve remote code execution.

Adam Kues at Assetnote discovered the batch-route bug and reported it through WordPress’s HackerOne program. The vulnerability requires no preconditions and can be exploited by unauthenticated users. TF1T, dtro, and haongo separately reported the SQL injection flaw.

A working proof-of-concept exploit is now publicly available on GitHub. Searchlight Cyber’s attack surface management team published details under the name wp2shell. The company initially held back its technical write-up but has released a checker tool at wp2shell.com.

Version-Specific Exposure and Patch Details

The two vulnerabilities affect different WordPress versions, creating distinct exposure levels. The batch-route confusion only exists from version 6.9 onward, while the SQL injection affects older releases as well.

Version 6.8.0 through 6.8.5 face SQL injection exposure only, patched in version 6.8.6. Versions 6.9.0 through 6.9.4 are vulnerable to the full RCE chain, fixed in 6.9.5. Similarly, versions 7.0.0 through 7.0.1 face complete RCE exposure, resolved in 7.0.2.

WordPress 7.1 beta2 includes both security fixes. Sites running version 6.8 cannot be exploited for RCE through this chain, which explains why version 6.8.6 only patches the injection vulnerability.

Verify Your Installation Status

WordPress has not confirmed whether forced updates reach sites with auto-updates disabled. Site administrators should verify their actual running version rather than assume the patch deployed automatically. The auto-update system pushed patches to millions of installations, but confirmation remains essential.

Technical Attack Mechanism Explained

The SQL injection vulnerability resides in WP_Query’s author__not_in parameter. When attackers provide a string instead of an expected array, the validation check fails, allowing raw values to enter the database query. Reaching this parameter without authentication requires exploiting the batch endpoint vulnerability.

WordPress’s /wp-json/batch/v1 route processes multiple sub-requests in a single call. The route tracks these requests in two parallel arrays. An error in one sub-request causes the arrays to fall out of sync by one position, causing a request to execute under a different handler.

This confusion bypasses the endpoint’s allow-list, delivering attacker input to the vulnerable query without authentication. The batch endpoint has existed since version 5.6 in 2020. However, the confusion that enables its abuse only appeared in version 6.9.

Severity Ratings and Impact Assessment

WordPress’s official advisory rates the RCE chain as Critical. However, the CVE record scores it 7.5, categorized as High severity. The impact metrics acknowledge data access alone, not the integrity or availability loss typically associated with code execution.

The SQL injection vulnerability scores higher than 9.1, earning a Critical rating. The vulnerability most commonly called a critical RCE actually scores lower because the scoring system rewards the injection’s direct database access. The route confusion is treated as a parsing flaw on its own.

One technical condition narrows the blast radius significantly. According to Cloudflare, the code-execution path only works when sites do not run a persistent object cache. Default WordPress installations lack such caching, maintaining their exposure. Sites using Redis or Memcached as persistent object caches may avoid this particular attack path, though this provides no protection against the SQL injection.

Exploitation Landscape and Detection

No confirmed exploitation has been reported as of July 18. The vulnerability does not yet appear on CISA’s Known Exploited Vulnerabilities catalog, which requires confirmed active exploitation. Rapid7 announced that authenticated checks for InsightVM and Nexpose will become available on July 20.

However, this apparent calm offers limited reassurance. Mass exploitation of WordPress vulnerabilities has become an established criminal enterprise. Before its server leaked in June, one caching-plugin flaw allowed the WP-SHELLSTORM group to compromise over 17,000 sites. That attack used a publicly known, already-patched bug that only worked on non-default settings.

The wp2shell vulnerability is now public, patched, and exploitable on default settings. Searchlight’s analysis estimates over 500 million websites run WordPress globally. This figure represents the total install base, not the exposed subset. Only sites running version 6.9 or later face RCE exposure, and WordPress shipped version 6.9 on December 2, 2025.

Immediate Mitigation Steps Before Updating

Every mitigation Searchlight recommends focuses on blocking anonymous access to the batch endpoint. All approaches serve as temporary stopgaps until proper updates can be applied. These measures may break legitimate integrations that rely on the affected functionality.

At web application firewall level, block both /wp-json/batch/v1 and rest_route=/batch/v1. Both paths require blocking because rules covering only the /wp-json path leave the query-string route exposed. Cloudflare reports its managed WAF now blocks the attack chain for protected sites.

Alternatively, administrators can disable the WP REST API entirely, which eliminates unauthenticated REST access across the board. Searchlight has published a short drop-in plugin that rejects anonymous /batch/v1 requests at the rest_pre_dispatch hook. This provides more targeted protection than completely disabling REST functionality.

The Disclosure Timeline Reality

WordPress core operates as open source software, and each release identifies the files it modified. This transparency always provides enough information for skilled researchers to reverse-engineer vulnerabilities. Searchlight initially withheld its detailed write-up. Within 24 hours, other security researchers had analyzed the patch, published the attack mechanism, and released exploit code on GitHub.

This represents the exact scenario responsible disclosure aims to prevent. Shipping the fix inevitably ships the roadmap to the underlying bug. The only remaining control factor is how quickly patches reach vulnerable sites before attackers reverse-engineer them. WordPress responded aggressively on Friday by forcing updates across its ecosystem.

The exploit code is now public while updates continue rolling out. WordPress’s version statistics will reveal how many sites successfully applied the patch. Meanwhile, scan traffic targeting batch/v1 endpoints will show how many attackers actively search for vulnerable installations. Whichever curve proves steeper will determine this incident’s ultimate impact and legacy.

Original Source: thehackernews.com