WordPress’s wp2shell Core Flaw Mirrors the 2017 Bug That Defaced Millions

WordPress patched a core flaw on Friday that let anyone run code on an unpatched site with zero plugins installed. It is the same shape of bug that defaced more than a million pages in 2017. The new flaw carries two CVE identifiers, CVE-2026-63030 and CVE-2026-60137, and goes by the name wp2shell. Every WordPress 6.9 and 7.0 site sat exposed until versions 6.9.5 and 7.0.2 shipped that day.

A working exploit is already public on GitHub, built from two small mistakes that chain into remote code execution with no login required. WordPress has run this exact race before. Last time, it took less than 48 hours for the defacements to start.

Two Small Mistakes Open an Unauthenticated Shell

The chain starts with a routing mix-up. WordPress’s REST API batch endpoint, reachable at /wp-json/batch/v1, runs several sub-requests inside one call and tracks them in two parallel arrays. An error in one sub-request knocks those arrays out of step by exactly one position, so a request meant for one handler gets served by its neighbor’s instead.

Walked through carefully, that mismatch slips past the endpoint’s allow-list and lands attacker-controlled input inside WP_Query, the class WordPress uses to build database queries. The specific target is a parameter called author__not_in, which expects an array. Hand it a string instead, and the check meant to catch that gets skipped, dropping raw text straight into a SQL query.

Adam Kues of Assetnote, Searchlight Cyber’s attack surface management arm, found the routing flaw and reported it through WordPress’s HackerOne bug bounty program. His write-up describes the attack as having “no preconditions and can be exploited by an anonymous user.” Three other researchers, TF1T, dtro and haongo, reported the SQL injection separately. Within about a day of the patch, independent researchers had reconstructed both bugs from the released files and published a working detection proof-of-concept on GitHub.

The severity math is messy. WordPress’s own advisory calls the RCE chain Critical. Its formal CVE record scores that same chain 7.5, only High, because the metrics credit data exposure but not the code execution that follows it. The SQL injection alone, scored on its own, comes in above 9.1, Critical. Neither number by itself tells you what you actually need to know.

Why WordPress Pulled Its Most Disruptive Lever

Forcing an update onto sites that asked not to have one is not a step WordPress takes lightly. It did it anyway on Friday, pushing 6.9.5 and 7.0.2 through the auto-update system to every reachable site on an affected version. WordPress has not said whether that forced push reaches installs that turned auto-updates off entirely.

One condition narrows who is actually reachable through the code-execution path. Cloudflare, which shipped web application firewall rules alongside the disclosure, says the chain only works when a site has no persistent object cache running. A default WordPress install has no such cache, so default-install exposure stands. Sites fronted by Redis or Memcached may sit outside this specific path, though that is an accident of architecture rather than a fix, and it does nothing for the standalone SQL injection.

Scanners are catching up fast. Rapid7 says authenticated checks for InsightVM and Nexpose land July 20. wp2shell has no listing yet on CISA’s Known Exploited Vulnerabilities catalog, which requires confirmed exploitation first, and none had been reported as of July 18.

Has WordPress Core Broken This Way Before?

Yes, and the last time was worse before anyone got ahead of it. In February 2017, a different WordPress core flaw, also living in a REST API endpoint, let anonymous visitors rewrite site content. Within two days of disclosure, hacking crews had defaced more than a million pages. wp2shell is following a similar script, just compressed.

That 2017 bug sat inside the REST API’s content endpoints, which WordPress had introduced to WordPress 4.7.0 in December 2016, only two months before the flaw surfaced. WordPress’s own team found it, patched it silently in version 4.7.2, and sat on the disclosure for six days to let auto-updates roll out quietly first.

We believe transparency is in the public’s best interest. It is our stance that security issues should always be disclosed. In this case, we intentionally delayed disclosing this issue by one week to ensure the safety of millions of additional WordPress sites.

Aaron Campbell, then WordPress’s Core Security Team Lead, explained the six-day delay as a way to buy time for automatic updates to reach sites before attackers noticed.

It did not buy enough. Once the fix went public, Wordfence counted more than 800,000 attacks in 48 hours. Twenty separate hacking crews defaced more than 1.5 million web pages on sites still running the vulnerable versions.

The gap between those two disclosure approaches is the whole argument for forcing updates this time. WordPress could not quietly patch wp2shell and wait. The write-up’s core details, the patched files and a GitHub proof-of-concept were all public within about a day of release. Forcing the update was the only lever left to pull.

The Same Blueprint, Three Features Later

There is a pattern underneath both incidents. WordPress keeps building major infrastructure straight into core, switched on by default, no plugin required. The REST API arrived that way in December 2016. The batch endpoint followed in November 2020. This year’s WordPress 7.0 folded a PHP AI Client SDK into core the same way, live on every install without a separate download.

Default-on features are hard to avoid and hard to disable safely, which is exactly what makes them efficient attack surface. Core code itself rarely breaks. Patchstack, a WordPress vulnerability research firm, counted just six core vulnerabilities in all of 2025, and rated every one low priority, against 11,334 vulnerabilities across WordPress’s plugins and themes, a total that grew 42% over the year before. Ninety one percent of that pile sat in plugins alone.

That rarity is the point. When core does break, it breaks something reachable on every one of WordPress’s installs, whatever share of the web is used to measure it. W3Techs puts that share at roughly 41.5% of all websites this month. Searchlight’s own estimate for the raw install count runs past 500 million.

A Researcher Who Knows How Fast Patches Get Read

Searchlight is withholding its own technical write-up for now. Two months earlier, when Drupal patched an anonymous SQL injection in its own core, Searchlight itself turned that public fix into a same-day analysis with two working proofs of concept. That was someone else’s bug, and it took the firm roughly a day to tear it apart.

The same clock now runs against its own disclosure. Within about a day of the July 17 release, independent researchers had reconstructed both bugs from the patched files well enough to publish working exploit code, the reconstruction referenced above. Withholding a write-up buys hours, not weeks, once the patched source sits in a public repository.

If You Cannot Patch Today

Every stopgap Searchlight has published comes down to keeping anonymous callers off the batch endpoint. They do not replace the update, and each one can break a legitimate integration that relies on the REST API.

• Block both paths at the firewall: /wp-json/batch/v1 and the query string form ?rest_route=/batch/v1 both need blocking, since a rule covering only one leaves the other reachable.
• Disable the WP REST API entirely, which removes unauthenticated REST access wholesale, along with features some plugins and the block editor depend on.
• Drop in Searchlight’s published mitigation plugin, a short file that rejects anonymous batch requests until the real update lands.

These stopgaps do not buy real safety on their own. Patchstack’s research puts the median time to mass exploitation for the most heavily targeted core-level bugs at five hours once code goes public, and roughly half of high-impact flaws get hit within 24 hours. The same research found typical hosting-provider defenses blocked only 26% of exploit attempts tested, and just 12% of WordPress-specific attacks.

Wordfence pushed a firewall rule to its Premium, Care and Response customers on July 17, the same day WordPress shipped the fix. That is the fast end of the response curve. The slow end is every site still waiting on an auto-update WordPress has not confirmed will even reach it.

WordPress’s version statistics will eventually show how many sites took the patch. Scan logs against /wp-json/batch/v1 will show how many attackers came looking. In 2017, the gap between those two numbers closed inside 48 hours.

Frequently Asked Questions

Is WordPress.com Affected by wp2shell?

WordPress.com, Automattic’s hosted version of the software, manages core updates centrally across its own infrastructure, so site owners there do not need to manually patch anything themselves. The exposure described here applies to self-hosted WordPress.org installs, where the site owner or host controls when updates land.

How Do I Check Which WordPress Version My Site Is Running?

Log into wp-admin and open the Dashboard’s “At a Glance” panel or the Updates screen, which lists the exact core version installed. Anyone without admin access can often find the same number by viewing a page’s source code and searching for the generator tag WordPress adds automatically.

What Is a Persistent Object Cache, and Does My Site Have One?

A persistent object cache stores database query results in memory using software like Redis or Memcached, so WordPress does not repeat the same query on every page load. Some managed WordPress hosts enable one by default, while a typical shared-hosting account or a fresh self-managed install usually does not.

Does Disabling the REST API Break My Site?

It can. The block editor, many mobile apps, and plugins including WooCommerce and Jetpack rely on REST API calls to function. Turning it off entirely stops the wp2shell attack path, but Searchlight recommends it only as an emergency measure until the real update is applied, not as a long-term fix.