New wp2shell WordPress Core Flaw Lets Unauthenticated Attackers Run Code

Up to date July 18, 2026: the 2 flaws now carry CVE IDs, the complete mechanism has been revealed, a persistent-object-cache situation has surfaced, and a working proof-of-concept is public. The story beneath displays all of it.

An nameless HTTP request can run code on a WordPress website. The bug is in core, so a naked set up with zero plugins is exploitable. Each 6.9 and seven.0 website was in vary till Friday, when WordPress shipped 6.9.5 and seven.0.2 and enabled what it calls compelled updates by its auto-update system.

wp2shell is 2 bugs, not one, and each now carry CVE IDs. CVE-2026-63030 is the REST API batch-route confusion; CVE-2026-60137 is a SQL injection in WordPress core. Chained, they take an nameless request all the best way to code execution.

Since Friday, the complete mechanism has been revealed, and a working proof-of-concept has gone up on GitHub.

Adam Kues at Assetnote, Searchlight Cyber’s assault floor administration arm, discovered the batch-route bug and reported it by WordPress’s HackerOne program.

The writeup, revealed below the identify wp2shell, says the assault has “no preconditions and will be exploited by an nameless person.” The SQL injection was reported individually by TF1T, dtro, and haongo.

Searchlight remains to be holding its personal technical write-up and pointed house owners to a checker at wp2shell.com. The reticence is inappropriate now: the patch is public, and different researchers learn it.

Searchlight’s publish estimates that over 500 million web sites run WordPress. That determine is the entire set up base, not the uncovered set: the RCE chain solely exists from 6.9, which shipped on December 2, 2025. So each website uncovered to the code-execution path is working a launch lower than eight months previous, and no advisory says what number of that’s.

The chain has two small errors. The injection lives in WP_Query’s author__not_in parameter: hand it a string as an alternative of an array and the verify that expects an array is skipped, dropping the uncooked worth into the question.

Reaching that parameter and not using a login is the batch endpoint’s job. WordPress’s /wp-json/batch/v1 route runs a number of sub-requests in a single name and tracks them in two parallel arrays; an error in a single sub-request knocks the arrays out of step by one, so a request runs below a unique request’s handler.

Nested, that confusion walks previous the endpoint’s allow-list and lands the attacker’s enter within the susceptible question, unauthenticated. The batch endpoint has shipped since 5.6 in 2020; the confusion that abuses it’s new to six.9.

The scores are price studying carefully. WordPress’s personal advisory charges the RCE chain Essential. Its CVE file scores it 7.5, solely Excessive, and the affect metrics credit score knowledge entry alone, not the integrity or availability loss you’ll count on from code execution. The injection is determined by scores larger than 9.1, Essential.

The bug everybody is looking a vital RCE is, by its personal quantity, the lesser of the 2, as a result of the scoring rewards the injection’s direct attain into the database and treats the route confusion by itself as a parsing flaw. Observe each CVEs, not the label on both.

One situation narrows the blast radius. The code-execution path works solely when the location just isn’t working a persistent object cache, per Cloudflare, which shipped WAF guidelines alongside the disclosure. A default set up has no such cache, so default-install publicity stands.

A website fronting WordPress with Redis or Memcached as a persistent object cache could also be off this specific path, however that could be a facet impact, not a repair, and it doesn’t cowl the SQL injection.

With CVE IDs assigned, the scanners can lastly see it: Rapid7 says authenticated checks for InsightVM and Nexpose land July 20. It isn’t on CISA’s KEV catalog, which takes confirmed exploitation, and none has been reported as of July 18. That consolation is thinner than it reads.

Mass exploitation of WordPress is an trade now. Earlier than its server leaked in June, one caching-plugin flaw alone obtained the WP-SHELLSTORM crew into greater than 17,000 websites by its personal rely, utilizing a bug that was already public, already patched, and solely labored on a non-default setting. This one is public, patched, and works on the default setting.

If you cannot replace at the moment

Each mitigation Searchlight provides comes all the way down to retaining nameless callers off the batch endpoint. All are stopgaps till you replace, and all can break professional integrations:

• At a WAF, block each /wp-json/batch/v1 and rest_route=/batch/v1. Each need to go, as a result of a rule masking solely the /wp-json path leaves the query-string route open. Cloudflare says its managed WAF now blocks the chain for websites behind it.
• Disable WP REST API, which kills unauthenticated REST entry wholesale.
• A brief drop-in plugin Searchlight publishes that rejects nameless /batch/v1 requests at rest_pre_dispatch.

WordPress core is open supply, and the discharge names the recordsdata it modified. That was all the time going to be sufficient. Searchlight held its write-up; inside a day, different researchers had learn the patch, revealed the mechanism, and put an exploit on GitHub, which is the precise form the disclosure was racing.

You can’t ship the repair with out transport the map to the bug. The one lever left is how briskly the patch reaches websites earlier than somebody reads it, and WordPress pulled it arduous on Friday.

Now the exploit is public, and the replace remains to be rolling. WordPress’s model stats will present what number of websites took the patch; scan site visitors towards batch/v1 will present what number of attackers got here trying. Whichever curve is steeper decides how this one will get remembered.