wp2shell (CVE-2026-63030): Unauthenticated RCE in WordPress Core — No Login, No Plugins, No Preconditions, 500 Million Sites at Risk, Patch Now

Sources: Searchlight Cyber / Assetnote — wp2shell primary research and disclosure (Adam Kues) · Cloudflare Blog — “Cloudflare WAF Protects WordPress Applications from Two High-Severity Vulnerabilities” · The Hacker News — “New wp2shell WordPress Core Flaw Lets Unauthenticated Attackers Run Code” · Cyber Kendra — “WP2Shell: Critical WordPress Flaw Lets Anyone Run Code” · Aikido — “Unauthenticated RCE in WordPress Core (wp2shell)” | CVEs: CVE-2026-63030 (RCE, Critical) · CVE-2026-60137 (SQL injection, CVSS 9.1) | Discovered by: Adam Kues, Assetnote / Searchlight Cyber | Reported via: WordPress HackerOne program | Patched: WordPress 7.0.2 and 6.9.5 — July 17, 2026 | Affected: WordPress 6.9.0–7.0.1 (RCE) · WordPress 6.8.0–6.8.5 (SQL injection only) | Not affected: WordPress below 6.8.0 | Entry point: /wp-json/batch/v1 — REST API batch endpoint, ships in every WordPress install since 5.6 (November 2020) | Wild exploitation: Not confirmed as of publication — technical details withheld by researcher | Estimated exposed population: 500+ million WordPress sites (Searchlight Cyber estimate)

“No preconditions and can be exploited by an anonymous user.” WordPress core. Zero plugins required. The batch endpoint has been in every installation since November 2020.

On July 17, 2026, WordPress released emergency security updates — versions 7.0.2 and 6.9.5 — and simultaneously enabled what it calls forced updates through its auto-update system, pushing the patch to sites without waiting for manual action. The vulnerability being closed: a chain of two flaws in WordPress core that, when combined, allow an unauthenticated attacker to execute arbitrary code on any WordPress site running version 6.9.0 through 7.0.1, with no login required, no plugins required, and no user interaction required. Adam Kues at Assetnote — the attack surface management arm of Searchlight Cyber — found the flaw and disclosed it through WordPress’s HackerOne program. His characterization: the attack has “no preconditions and can be exploited by an anonymous user.”

The entry point is the WordPress REST API batch endpoint — /wp-json/batch/v1 — a feature that has shipped in every WordPress installation since version 5.6 in November 2020. The batch endpoint is not new. WordPress has shipped it since 5.6 in November 2020 and documented the request format publicly ever since. Nothing published so far explains what changed in 6.9 to open it. The batch endpoint was introduced to allow REST API clients to bundle multiple API requests into a single HTTP call, reducing round trips for complex operations. In versions 6.9 and above, something in this endpoint’s handling of batch requests introduced the condition that enables the exploit chain.

WordPress powers an estimated 43% of all websites — Searchlight Cyber estimates more than 500 million sites run WordPress globally. Unauthenticated RCE in core with no plugin dependency and no preconditions is one of the broadest-surface vulnerabilities of 2026. A successful exploit gives the attacker code execution in the context of the web server — from which they can read or modify any file the web server can access, extract database credentials from wp-config.php, plant a web shell for persistent access, deploy malware, or pivot to the underlying hosting infrastructure.

The two-CVE chain — how REST API batch-route confusion leads to remote code execution

WordPress’s own release post describes the vulnerability more fully than the researcher has: a REST API batch-route confusion and SQL injection issue leading to Remote Code Execution. Cloudflare’s advisory, published simultaneously with WordPress’s patch release, provides the most complete technical characterization available while full details remain withheld:

CVE-2026-63030: Unauthenticated remote code execution. A vulnerability in WordPress version 6.9 and later allows an unauthenticated attacker to execute code through the batch endpoint of the REST API when a persistent object cache is not in use. This vulnerability is related to the SQL injection described above. No login or user interaction is required to exploit this vulnerability.

CVE-2026-60137: SQL injection. A vulnerability in WordPress version 6.8 and later allows crafted input to alter a database query.

The relationship between the two CVEs is what makes the RCE possible. wp2shell is not one vulnerability but two, and their relationship is what makes it dangerous. The first, CVE-2026-60137, is an SQL injection in the author__not_in parameter of WP_Query, the core class that builds nearly every database query WordPress issues. It reaches back to WordPress 6.8. The RCE (CVE-2026-63030) requires version 6.9 or later and is specifically triggered through the REST API batch endpoint.

The technical mechanism of the batch-route confusion component — how the batch endpoint misroutes requests in a way that enables the SQL injection to chain into code execution — has not been published by either the researcher or WordPress. Assetnote / Searchlight Cyber are deliberately withholding technical details to give defenders time to patch. The best way to protect yourself is to update WordPress to version 7.0.2, or 6.9.5 if you are on the 6.9 branch. The three files WordPress 7.0.2 touched provide indirect insight into the exploit path: /wp-includes/rest-api/class-wp-rest-server.php (the REST API server — the batch endpoint handler), /wp-includes/class-wp-query.php (the query builder where the SQL injection lives), and /wp-includes/rest-api.php (the REST API bootstrap).

One important caveat from Cloudflare’s advisory: CVE-2026-63030 — a vulnerability in WordPress version 6.9 and later allows an unauthenticated attacker to execute code through the batch endpoint of the REST API when a persistent object cache is not in use. The “when a persistent object cache is not in use” condition is significant: sites running Redis, Memcached, or another persistent object cache as their WordPress object cache backend are not vulnerable to the RCE component under current understanding. The SQL injection (CVE-2026-60137) affects 6.8+ regardless of object cache configuration. The majority of WordPress installations — particularly small business sites, blogs, and default hosting configurations — do not use a persistent object cache and are therefore vulnerable to the full RCE chain.

Why the forced auto-update does not mean you are safe

WordPress’s decision to enable forced auto-updates for this patch is the right call given the severity and the breadth of the exposure — but it comes with operational ambiguities that defenders need to resolve explicitly rather than assuming.

• Sites that disabled auto-updates may not have received the push. WordPress has not said whether the forced push reaches sites that turned auto-updates off. Check what you are actually running rather than assume it landed. Many enterprise WordPress deployments, managed hosting environments, and staging/production pipelines disable auto-updates specifically to maintain control over version changes. Those sites will not have received the forced patch automatically.
• Managed WordPress hosts handle updates differently. WP Engine, Kinsta, Pressable, WordPress VIP, and other managed hosts have their own update mechanisms that may or may not align with WordPress core’s auto-update push timing. Verify with your host that the patch has been applied to your specific environment.
• The auto-update only covers the patch — not detection of prior exploitation. If your site was compromised before the patch arrived, the auto-update closes the vulnerability but does not remove any web shells, backdoors, or other persistence an attacker may have planted. Sites that were running 6.9.0 through 7.0.1 exposed to the internet for any period between the vulnerability’s introduction in 6.9 and today’s patch should be investigated for indicators of compromise, not just patched.
• Verify your version explicitly. Log in to wp-admin → Dashboard → At a Glance (version shown in footer), or wp-admin → Updates, or run wp core version via WP-CLI. Do not rely on the auto-update notification alone.

The scope of exposure — why this is different from a plugin vulnerability

The vast majority of WordPress security vulnerabilities are plugin vulnerabilities — flaws in specific plugins that only affect sites where that plugin is installed. Plugin vulnerabilities can be severe, but they are scoped: if you don’t run the plugin, you’re not affected. wp2shell is categorically different because the flaw is in WordPress core, meaning every WordPress installation in the affected version range is vulnerable regardless of what plugins, themes, or configuration choices are in use.

The batch endpoint at /wp-json/batch/v1 is present and active in every WordPress installation running 5.6 or later. It does not need to be enabled, configured, or used by any installed functionality to be exploitable. A default WordPress installation with no plugins and no theme customization — the absolute minimum possible WordPress deployment — was vulnerable from version 6.9.0 until today’s patch. That is the definition of a core vulnerability.

Searchlight Cyber estimates over 500 million sites run WordPress. WordPress’s own market share data places it at approximately 43% of all websites tracked by W3Techs. Even if the vast majority of those sites received the forced auto-update promptly, the residual unpatched population — enterprise sites with disabled auto-updates, sites on managed hosting with delayed update cycles, sites that are in maintenance or have been abandoned — represents tens of millions of vulnerable installations that will remain unpatched for hours, days, or weeks after today.

What attackers can do with unauthenticated RCE on a WordPress site

Remote code execution in the context of a web server on a WordPress site opens a specific and well-documented post-exploitation surface:

• Extract wp-config.php — contains database hostname, database name, username, password, and WordPress security keys. On shared hosting, the database credentials often provide access to every database on the hosting account, not just the WordPress database.
• Plant a web shell — drop a PHP file in the uploads directory or anywhere the web server can write to, providing persistent access that survives a WordPress update. The web shell can be used for ongoing access, data exfiltration, or as a staging point for lateral movement to the hosting infrastructure.
• Enumerate and exfiltrate the database — WordPress stores user email addresses, hashed passwords, post content, private drafts, comments (including unpublished ones), plugin settings, and often customer data depending on what plugins are installed. WooCommerce sites store payment metadata, order history, and shipping addresses.
• Serve malware or phishing content — inject malicious JavaScript or redirect visitors to attacker-controlled infrastructure. At the scale WordPress represents, this is a significant malware distribution vector.
• Pivot to hosting infrastructure — on shared or VPS hosting, code execution on the web server frequently provides access beyond the WordPress installation to the underlying operating system, other hosted sites on the same server, or credentials stored in server configuration files.
• Deploy SEO spam or cryptominer — historically the most common monetization of compromised WordPress sites at scale.

Immediate actions — the complete checklist

1. Verify your WordPress version right now. Go to wp-admin → Dashboard → At a Glance, or wp-admin → Updates. Confirm you are running 7.0.2 (if on the 7.0 branch), 6.9.5 (if on the 6.9 branch), or 6.8.6 (if on the 6.8 branch). Do not assume the auto-update landed.
2. If you cannot patch immediately: Block /wp-json/batch/v1 and ?rest_route=/batch/v1 at your WAF, Nginx, or Apache configuration. This prevents exploitation of the RCE entry point. Be aware this may break legitimate REST API batch consumers — this is an emergency temporary measure only until you can apply the update.
3. Audit for indicators of compromise if you were running 6.9.0–7.0.1 with internet exposure. Check for unexpected files in wp-content/uploads/ with .php extensions. Review access logs for unusual POST requests to /wp-json/batch/v1. Check for new administrator accounts in wp-admin → Users. Review wp-config.php and .htaccess for unauthorized modifications.
4. If you run WordPress 6.8: Update to 6.8.6 for the SQL injection fix (CVE-2026-60137). You are not vulnerable to the RCE, but the SQL injection is independently exploitable.
5. Managed WordPress hosting: Contact your host to confirm the patch status of your specific environment. Do not rely on general announcements — verify your site’s version specifically.
6. Enable a persistent object cache if you haven’t already. Redis or Memcached as a WordPress object cache not only improves performance significantly — it also eliminates the condition required for the CVE-2026-63030 RCE. This is a defense-in-depth measure, not a substitute for patching.
7. Update 7.1 beta2 carries the same fix — if you are running beta, you are protected, but move to a stable release as soon as available.

Sources and further reading

• Searchlight Cyber / Assetnote — wp2shell: Pre-Authentication RCE in WordPress Core (Primary Research, Adam Kues)
• Cloudflare Blog — Cloudflare WAF Protects WordPress Applications from Two High-Severity Vulnerabilities (CVE IDs and Technical Description)
• The Hacker News — New wp2shell WordPress Core Flaw Lets Unauthenticated Attackers Run Code
• Cyber Kendra — WP2Shell: Critical WordPress Flaw Lets Anyone Run Code
• Aikido — Unauthenticated RCE in WordPress Core (wp2shell) — Patch Guidance and Runtime Mitigation

DataWater publishes daily cybersecurity intelligence for enterprise and government security leaders. Article #44 — July 17, 2026. Previous: GPT-5.5 Offensive Cyber Benchmark (July 16) · UEFI Secure Boot Bypass — 11 Microsoft-Signed Shims (July 15) · CitrixBleed 2 — Seven Steps to DragonForce Ransomware (July 13). Browse the full threat brief archive →