wp2shell: Critical WordPress RCE Without Login Actively Exploited

Published on 28 July 2026

Imagine an attacker taking complete control of your WordPress website – without a password, without a vulnerable plugin, without you having misconfigured anything. A perfectly ordinary, up-to-date WordPress installation is enough. This is exactly the reality behind wp2shell, a critical security flaw that has been actively exploited since 17 July 2026. It is the first critical, unauthenticated remote code execution vulnerability (running malicious code from afar) in the WordPress core in almost a decade. And if your website has not yet been updated, you should treat it as an active emergency.

What happened?

On 17 July 2026, the WordPress security team released emergency updates for two chained vulnerabilities in the WordPress core. Together they go by the name wp2shell – a nod to the goal of the attack: from WordPress straight to a "shell", i.e. complete control over the server.

The two vulnerabilities are:

• CVE-2026-60137 (CVSS 7.5, "High") – an SQL injection, i.e. the injection of database commands via a manipulated parameter.
• CVE-2026-63030 (CVSS 9.8, "Critical") – a flaw in the REST API that bypasses authentication.

Individually, both would be unpleasant. Combined, they are devastating: an anonymous attacker from the internet can create a new administrator account and execute arbitrary code with the privileges of the web server, all with a single HTTP request. No login, no user interaction, no additional plugin required.

The flaw was discovered by security researcher Adam Kues (Assetnote / Searchlight Cyber) – with the help of an AI model, and for just around 25 US dollars in compute costs. For comparison: according to Kues, exploit brokers pay up to 500,000 US dollars for a working WordPress RCE exploit. This discrepancy shows how dramatically AI has lowered the technical barrier for developing such attacks.

The technical background – explained clearly

The attack chain consists of two interlocking flaws. Here is a simplified explanation:

The entry point: the REST API confusion (CVE-2026-63030)

WordPress offers a so-called Batch API – an interface through which multiple requests can be bundled together at once. The relevant part of the program first checks these requests (validation) and then executes them. The problem: if a single sub-request fails the check, only one of the two internal lists is updated, the other is not. As a result, the mapping shifts – subsequent requests are executed under the wrong "handler", i.e. processed by a part of the program that performs no check at all on the parameters passed to it. Ben Marr, Security Engineer at Intruder, describes it as follows:

"CVE-2026-63030 is the entry point – a route-confusion bug in the REST API batch endpoint that bypasses authentication and allows an attacker to invoke internal handlers without any permission check whatsoever." – Ben Marr, Intruder

The lever: the SQL injection (CVE-2026-60137)

Via this bypassed check, the attacker can now manipulate a parameter called author__not_in. Normally this value is only properly sanitised when passed as a list of numbers. If it is instead supplied as a simple string, it lands unchecked directly in a database query – the classic breeding ground for an SQL injection.

The escalation to server takeover

Via the SQL injection, WordPress's internal cache can be "poisoned". Through further mechanisms – the oEmbed cache, Customizer changesets and a cycle-detection component – the attacker temporarily assumes the identity of an administrator. At that moment, a previously rejected request to create a user is re-evaluated – and this time successfully. A new admin account is created (HTTP status 201). The attacker logs in, installs a malicious plugin and executes code.

The only prerequisite: a publicly reachable WordPress installation of version 6.9.x or 7.0.x without a persistent object cache, in which the endpoint /wp-json/batch/v1 is reachable.

Who is affected?

The following WordPress versions are affected:

• 6.8.0 to 6.8.5 – only the SQL injection (CVE-2026-60137)
• 6.9.0 to 6.9.4 – the full RCE chain
• 7.0.0 to 7.0.1 – the full RCE chain

Versions prior to 6.8 as well as the patched versions 6.8.6, 6.9.5 and 7.0.2 are not affected.

The scale is enormous. According to Wiz Research, at the time of publication 60 per cent of all organisations using WordPress had at least one vulnerable instance, and 25 per cent exposed a vulnerable server directly to the internet. WordPress powers around 42.6 per cent of all websites worldwide – over 522 million installations.

For German SMEs the situation is particularly acute: with around 1.9 million WordPress websites, Germany is the second-largest WordPress market in the world. Benjamin Harris, CEO of watchTowr, puts the rarity into context:

"WordPress often gets a bad reputation when it comes to security. But in truth, an impactful, unauthenticated SQL injection or remote code execution flaw in the WordPress core is fairly rare. That's exactly what makes this one so special – and it's why everyone is currently trying to patch before mass exploitation picks up speed." – Benjamin Harris, watchTowr

Exploitation is already underway

The alarming part: the attacks began almost immediately. As early as 23:29 UTC on 17 July 2026 – less than six hours after the patches were released – Wordfence registered the first probes against the REST API endpoint. At 23:42 UTC the first clear SQL injection attempt followed. From 18 July, public proof-of-concept exploits were circulating on GitHub.

Jake Knott, Principal Security Researcher at watchTowr, reports:

"By the early hours of Saturday morning (UTC), successful exploitation was already in full swing – initially with public exploit code to harvest hashed credentials, followed by remote code execution once further details became public. From our vantage point, we're seeing widespread impact across organisations of every size and every industry." – Jake Knott, watchTowr

WatchTowr registered "tens of thousands of exploitation attempts" in its honeypots. Over 100 backdoor administrator accounts were observed following successful exploitation. On 21 July 2026, the US agency CISA added both CVEs to its Known Exploited Vulnerabilities (KEV) catalog. Germany's BSI classified the flaw as criticality 3 and published cybersecurity warning 2026-271984-1032.

How to check whether you are affected

1. Check your WordPress version: View the current version in the dashboard under "Dashboard → Updates". Alternatively, read off the value of $wp_version in the file wp-includes/version.php.
2. Identify a vulnerable version: If the version is 6.8.0–6.8.5, 6.9.0–6.9.4 or 7.0.0–7.0.1, action is required.
3. Use a public checker: Enter the URL of your installation at https://wp2shell.com to check for the vulnerability automatically.
4. Check for compromise: Under "Users → All Users", look for unknown administrator accounts, especially recently created ones.
5. Check plugins: Under "Plugins → Installed Plugins", look for unknown or recently installed plugins with unusual names or no identifiable author.
6. Review web server logs: Search the access logs for POST requests to /wp-json/batch/v1 or ?rest_route=/batch/v1 – in particular with response codes 207 (Multi-Status) or 200.
7. Check Wordfence logs (if installed): look for blocked requests to the endpoints mentioned above.
8. Check the file system for web shells: Search in wp-content/uploads/ and wp-content/plugins/ for unknown PHP files. Suspicious files often contain eval(), base64_decode(), gzuncompress() or passthru().

What you need to do now

1. Update IMMEDIATELY (top priority): Update WordPress Core to 6.8.6, 6.9.5 or 7.0.2 – depending on the version installed. In the dashboard under "Updates", click "Update Now". WordPress has forcibly enabled automatic updates for affected versions – but do not rely on this blindly; verify success.
2. Verify the update: After the update, check the version again.
3. Temporary mitigation (if an immediate update is not possible): Block the batch endpoint /wp-json/batch/v1 and ?rest_route=/batch/v1 at the WAF level, or install a plugin that disables anonymous REST API access (e.g. "Disable REST API"). This is not a substitute for patching.
4. Enable a web application firewall: Cloudflare rolled out WAF rules for all plans (including Free) on 17 July 2026 at 17:03 UTC. Wordfence Premium/Care/Response customers have been protected since 17 July 2026; Wordfence Free will receive protection from 16 August 2026.
5. Clean up administrator accounts: Check all admin accounts and delete unknown ones immediately.
6. Clean up plugins: Deactivate and delete unknown plugins.
7. Check for web shells: Search the file system and, if in doubt, run a malware scanner (e.g. Wordfence Scan, MalCare).
8. Change credentials: Change all admin passwords, the database password (in wp-config.php) and hosting credentials if compromise cannot be ruled out.
9. If compromise is suspected: Initiate a full incident response – take the website offline, save the compromised state as a backup (do not overwrite it), perform a forensic analysis, restore a clean backup or reinstall.

GDPR: Why this is more than a technical problem

A successful wp2shell attack can lead to access to personal data – such as customer data, order data in WooCommerce shops, comments, email addresses or contact form entries. Observed post-exploitation activities explicitly include the harvesting of admin usernames and email addresses as well as attempts to access wp-config.php with database credentials.

This gives rise to concrete obligations:

• Notification obligation (Art. 33 GDPR): If personal data has been compromised or such access cannot be ruled out, you must report the data breach without undue delay and, where feasible, within 72 hours to the competent data protection authority.
• Duty to inform (Art. 34 GDPR): Where there is likely to be a high risk to those affected – for example when passwords or payment data are leaked – the individuals concerned must also be notified.
• Documentation obligation (Art. 33(5) GDPR): Even where there is no notification obligation, the breach must be documented internally.

Important for liability: failure to apply an available security patch promptly can be regarded as a breach of Art. 32 GDPR (security of processing). The fines range up to 10 million euros or 2 per cent of global annual turnover, and for more serious breaches up to 20 million euros or 4 per cent. On top of this come possible claims for damages from those affected under Art. 82 GDPR. For context: in Europe alone, around 1.2 billion euros in GDPR fines were imposed in 2024.

Assessment and conclusion

wp2shell is among the most serious WordPress vulnerabilities of recent years and is comparable to historic CMS flaws such as Drupalgeddon. The combination of CVSS 9.8, unauthenticated exploitability, absence of prerequisites, publicly available exploits, confirmed active exploitation and inclusion in the CISA KEV catalog results in a maximum risk profile.

The good news: patches exist, and the community's response was swift. Within 24 hours of publication, the proportion of vulnerable organisations fell from 60 to 50 per cent, and the share with an internet-exposed server from 25 to 10 per cent. The bad news: a tenth of all WordPress organisations were still exploitable a day later – and attackers scan the internet around the clock.

Ryan Dewhurst of KEVIntel gets to the heart of the actual problem: websites where automatic updates are disabled, unsupported or have failed remain vulnerable. This is precisely where the greatest danger lies for many SMEs.

Our clear recommendation: Check your WordPress version today. If it is vulnerable and your website is publicly reachable, treat it as an emergency – patch immediately, check for compromise and change your credentials. Every hour counts.