WordPress wp2shell Flaw Lets Hackers Run Code Remotely

An anonymous HTTP request can now run code on your WordPress site. Regarding WordPress vulnerability, No login required. No plugins needed. Just a bare WordPress install running the wrong version, and you are exposed.

This is wp2shell, and it is as bad as it sounds.

Two Bugs Working Together

The vulnerability is actually two separate bugs that work together. The first bug (CVE-2026-63030) involves confusion in WordPress’s REST API batch routing system. The second bug (CVE-2026-60137) is a SQL injection vulnerability in WordPress core itself.

When attackers chain these two flaws together, they can go from an anonymous web request straight to executing code on your server. No authentication. No special conditions. Just a working exploit that is now publicly available on GitHub.

WordPress shipped emergency patches on Friday. Version 6.9.5 and 7.0.2 went out through the automatic update system. However, that does not mean every site got the fix.

Which Sites Are Actually at Risk

Not every WordPress version faces the same level of danger. The two bugs affect different versions, which creates three distinct risk levels.

Sites running WordPress 6.8.0 through 6.8.5 face SQL injection only. That is serious, but attackers cannot execute code remotely through this chain. WordPress patched these versions to 6.8.6.

Sites running WordPress 6.9.0 through 6.9.4 face the full remote code execution chain. These versions got patched to 6.9.5.

Sites running WordPress 7.0.0 through 7.0.1 also face the full RCE chain. These versions got patched to 7.0.2.

The code execution path only exists from version 6.9 forward. That version shipped on December 2, 2025, which means every site exposed to remote code execution is running a release less than eight months old.

How the Attack Actually Works

The technical details matter less than the outcome, but here is the short version. The SQL injection lives in a WordPress parameter called author__not_in. When you pass it a string instead of an array, WordPress skips a security check and drops your input directly into a database query.

Reaching that parameter without logging in is where the second bug comes in. WordPress has a batch endpoint at /wp-json/batch/v1 that lets you run several requests at once. An error in one sub-request knocks two internal tracking arrays out of alignment by one position.

That misalignment means one request runs under a different request’s security handler. Attackers use that confusion to bypass the endpoint’s security list and land their malicious input in the vulnerable database query. No login required.

The batch endpoint has existed since WordPress 5.6 in 2020. The confusion bug that makes it dangerous only appeared in version 6.9.

One Thing That Might Protect You

There is one condition that narrows who gets hit. The code execution path only works when your site is not running a persistent object cache. A default WordPress install does not have this type of cache, which means most sites are exposed.

If your site uses Redis or Memcached as a persistent object cache in front of WordPress, you might avoid this particular attack path. However, that is a side effect, not a real fix. You are still vulnerable to the SQL injection part.

Additionally, that protection only exists by accident. It is not a security control you can rely on.

Why the Severity Ratings Are Confusing

WordPress’s own security advisory calls the full RCE chain “Critical.” However, the official CVE record scores it 7.5, which is only “High” severity. The scoring system credits data access alone, not the integrity or availability loss you would expect from code execution.

Meanwhile, the SQL injection by itself scores higher than 9.1, which is “Critical.” The bug everyone calls a critical RCE is actually rated lower than the SQL injection that feeds it.

The scoring system rewards the SQL injection’s direct database access. It treats the routing confusion on its own as just a parsing flaw. Track both CVE numbers, not just the label on either one.

Who Found This and When

Adam Kues at Assetnote, which is Searchlight Cyber’s attack surface management division, found the batch-route bug. He reported it through WordPress’s HackerOne program. The SQL injection was reported separately by researchers named TF1T, dtro, and haongo.

Searchlight published details under the name wp2shell. Their writeup says the attack has “no preconditions and can be exploited by an anonymous user.” They also set up a checker at wp2shell.com for site owners.

The company initially held back its full technical write-up. That restraint is meaningless now. The patch went public, and other researchers read it. Within a day, someone published the full mechanism and put a working exploit on GitHub.

What You Should Do Right Now

Check what version of WordPress you are actually running. Do not assume the automatic update landed. WordPress enabled forced updates through its auto-update system, but the company has not confirmed whether that reaches sites that turned auto-updates off.

If you cannot update immediately, you need to block anonymous access to the batch endpoint. Every mitigation comes down to keeping unauthenticated requests away from /wp-json/batch/v1. These are all temporary measures until you can update properly.

At your web application firewall, block both /wp-json/batch/v1 and rest_route=/batch/v1. You need to block both paths because a rule covering only the /wp-json path leaves the query-string route open. Cloudflare says its managed WAF now blocks the chain for sites behind it.

You can disable the WordPress REST API entirely, which kills all unauthenticated REST access. This approach works, but it can break legitimate integrations that your site depends on.

Searchlight published a short drop-in plugin that rejects anonymous requests to /batch/v1 at the rest_pre_dispatch hook. This is more surgical than disabling the entire REST API, but it is still just a stopgap.

Why This One Matters More Than Most

Searchlight’s post estimates that over 500 million websites run WordPress. That figure is the total install base, not the number of sites exposed. The RCE chain only exists from version 6.9 forward, which narrows the blast radius.

However, mass exploitation of WordPress is an industry now. Before its server leaked in June, one caching-plugin flaw alone got the WP-SHELLSTORM crew into more than 17,000 sites. They used a bug that was already public, already patched, and only worked on a non-default setting.

This vulnerability is now public, patched, and works on the default setting. The only question is whether the patch reaches sites faster than attackers can scan for them.

Rapid7 says authenticated vulnerability checks for InsightVM and Nexpose will be available on July 20. The flaw is not on CISA’s Known Exploited Vulnerabilities catalog yet, which requires confirmed exploitation in the wild. As of July 18, no exploitation has been reported.

That lack of confirmed exploitation is thin comfort. WordPress core is open source, and the security release names every file it changed. That was always going to be enough information. You cannot ship the fix without shipping a map to the bug.

The Race That Decides Everything

Searchlight held its detailed write-up to give the patch time to spread. Within a day, other researchers read the patch, published the mechanism, and put an exploit on GitHub. This is exactly the outcome the disclosure timeline was racing against.

Now the exploit is public, and the automatic update is still rolling out. WordPress’s version statistics will eventually show how many sites took the patch. Scan traffic against the batch/v1 endpoint will show how many attackers came looking.

Whichever curve is steeper decides how this vulnerability gets remembered. Update now, or become part of the statistics that prove why automatic updates exist in the first place.

Original Source: thehackernews.com