wp2shell: Pre-Auth RCE in WordPress Core Explained

Cybersecurity News Last updated: 21 Jul 2026

Written By

Sarwat Iftikhar

Glowing blue WordPress logo centered on a dark, blurred background filled with floating WordPress icons, creating a modern cyber-tech theme

WordPress shipped emergency security updates on July 17 after researchers disclosed a critical vulnerability that lets attackers take full control of a site without ever logging in. The flaw, nicknamed wp2shell, affects millions of installations running the two most recent major versions, and working exploit code is already public. If you manage a WordPress site, this is not a “patch when you get to it” issue. It is a “patch today” issue.

What Happened With the WordPress wp2shell Vulnerability?

Searchlight Cyber’s security researcher Adam Kues reported a vulnerability chain in WordPress Core that allows a completely anonymous HTTP request to result in full remote code execution. No account, no plugin, and no misconfiguration is required. A default, out-of-the-box WordPress install with zero plugins installed is exploitable.

The chain combines two separate bugs. The first is a route confusion issue in the REST API’s batch endpoint, which is on by default and reachable without authentication. The second is a SQL injection flaw in a query parameter used internally by WordPress Core. Chained together, an attacker can bypass the authentication checks that should protect the vulnerable code path, pull sensitive data such as administrator password hashes, and use that access to upload a malicious plugin or web shell. Some published proof-of-concept exploits reportedly skip the credential-cracking step entirely and reach code execution more directly.

Which WordPress Versions Are Affected?

The full attack chain, from anonymous request to remote code execution, affects WordPress 6.9.0 through 6.9.4 and 7.0.0 through 7.0.1. The SQL injection component on its own also affects 6.8.0 through 6.8.5, but on those older versions it cannot be chained into full RCE, since the route confusion bug was only introduced in the 6.9 release line.

If your site is running anything in the 6.9.x or 7.0.x range and has not been updated since July 17, treat it as exposed.

How Does the Attack Work Without Any Login?

This is what makes wp2shell dangerous rather than merely inconvenient. Most remote code execution vulnerabilities need something else to go wrong first: a weak password, a vulnerable plugin, an exposed admin panel. This one does not.

The attacker crafts a request to the REST API batch endpoint that tricks WordPress into misrouting a sub-request, using the handler intended for a different request entirely. That misrouting sidesteps the authentication check that would normally block access to the vulnerable query path. From there, the attacker feeds a malicious string into a parameter that WordPress does not sanitize correctly, triggering the SQL injection and giving them a path to full compromise. It is, in effect, a logic bug wearing the shape of an authentication bug, which is exactly the kind of flaw that automated scanners tend to miss and manual testers are trained to look for.

When Did WordPress Release a Fix?

WordPress shipped coordinated security releases on July 17: version 7.0.2 for current installs, with backports to 6.9.5 and 6.8.6 for sites running older branches, plus a fix in the 7.1 beta line. Sites with auto-updates enabled for core should already be patched. Sites managed manually, or on hosting environments where auto-updates are disabled, are not.

Are Attackers Already Exploiting This in the Wild?

At the time of disclosure, there were no confirmed reports of active exploitation. That window has narrowed fast. Full technical details of the vulnerability chain were published within a day of the patch, and a working proof-of-concept exploit is now public on GitHub. Given that WordPress powers a large share of all websites, and that AI-assisted code analysis makes it faster than ever to reverse-engineer a patch into a working exploit, security researchers widely expected mass scanning and exploitation attempts to begin almost immediately after disclosure. Treat the absence of a confirmed breach report as a head start, not as safety.

What Should Site Owners Do Right Now?

  1. Check your WordPress core version in the admin dashboard under Updates.
  2. If you are running 6.9.0 to 6.9.4 or 7.0.0 to 7.0.1, update to 7.0.2, 6.9.5, or 6.8.6 immediately.
  3. Confirm auto-updates are actually enabled and working, rather than assuming they are.
  4. If you use a web application firewall or a CDN with WAF rules, check whether virtual patching rules for this vulnerability have already been deployed on your account.
  5. Review recent admin activity and file changes for anything unfamiliar, particularly new plugins or unexplained admin accounts, in case the window between disclosure and your patch was already exploited.
  6. Rotate admin credentials as a precaution, since the SQL injection component of this chain is designed specifically to extract password hashes.
Affected version rangeFixed in
6.8.0 to 6.8.5 (SQLi only, not full RCE)6.8.6
6.9.0 to 6.9.4 (full RCE chain)6.9.5
7.0.0 to 7.0.1 (full RCE chain)7.0.2

What Does This Vulnerability Reveal About WordPress Core Security?

wp2shell is a reminder that the most damaging vulnerabilities are rarely the ones an automated scanner flags with a clean CVE match. They are logic flaws: a routing quirk here, an unsanitized parameter there, that on their own look low-risk and only become critical once someone works out how to chain them. That is precisely the gap between a vulnerability scan and a real penetration test. A scanner checks whether known signatures are present. A tester tries to chain what is actually reachable, the same way an attacker would.

For any business running WordPress or a comparable CMS in production, this is also a case for testing cadence. Annual testing means a chain like wp2shell can sit undiscovered for most of a year. Teams on continuous or quarterly assessment schedules catch this class of issue closer to when it is introduced, not months after attackers already have a public proof-of-concept to work from. It is also why attack surface management matters even for smaller teams: someone needs to know your CMS version is exposed before an attacker does.

If you run WordPress in production and are not sure whether your current security process would have caught something like wp2shell, that is worth a conversation before the next one shows up.

Related Articles

Copied.