WordPress wp2shell Vulnerability (CVE-2026-63030): Quick FAQ for CISOs

WordPress patched wp2shell (CVE-2026-63030) on July 17, 2026, a critical pre-authentication RCE in core that lets an anonymous attacker run code on a default install with no plugins and no login. The fix ships in versions 6.9.5 and 7.0.2, and WordPress has enabled forced automatic updates. This FAQ walks CISOs and security teams through what wp2shell is, which versions are exposed, whether it is being exploited, and how to patch fast.

Key Takeaways

• wp2shell (CVE-2026-63030) is a critical pre-authentication RCE in WordPress core. No login, no plugins, no special configuration required.
• It chains a REST API batch-route confusion (CVE-2026-63030) with a SQL injection in WP_Query (CVE-2026-60137).
• Affected: WordPress 6.9.0-6.9.4 and 7.0.0-7.0.1. Fixed in: 6.9.5 and 7.0.2, released July 17, 2026.
• WordPress enabled forced automatic updates, but administrators should confirm the patch actually applied.
• A public PoC demonstrates the SQL injection and can read the database, including admin password hashes. The full path to code execution has not been published, and no in-the-wild exploitation is confirmed as of July 18, 2026.
• Action: Update to 6.9.5, 7.0.2, or newer today. Sites on 6.8.x should apply 6.8.6 for the separate SQL injection issue.

What Is wp2shell (CVE-2026-63030)?

wp2shell is a critical pre-authentication Remote Code Execution vulnerability in WordPress core that lets an anonymous attacker run code on a default installation with no plugins and no preconditions. WordPress released versions 6.9.5 and 7.0.2 on July 17, 2026 to fix it and enabled forced automatic updates.

The vulnerability was discovered by Adam Kues at Assetnote, the attack surface management arm of Searchlight Cyber, and responsibly disclosed through WordPress’s HackerOne program. The researchers describe the attack as having “no preconditions” and being exploitable “by an anonymous user” against a stock install. Searchlight Cyber withheld full technical details to give defenders time to patch and published a public checker at wp2shell[.]com.

wp2shell at a Glance

How Does the wp2shell Exploit Chain Work?

wp2shell is a chain of two core vulnerabilities that together produce unauthenticated code execution:

• CVE-2026-63030 – a REST API batch-route confusion weakness in WP_REST_Server::serve_batch_request_v1(). This is the entry point rated Critical in the GitHub advisory GHSA-ff9f-jf42-662q, introduced in WordPress 6.9.
• CVE-2026-60137 – a SQL injection in the author__not_in parameter of the internal WP_Query class, where unsanitized input reaches the database query. This flaw has been present since WordPress 6.8 and is tracked under GHSA-fpp7-x2x2-2mjf.

An anonymous attacker reaches the vulnerable REST API batch endpoint (/wp-json/batch/v1), uses the route confusion to slip a rogue parameter into WP_Query, and drives the SQL injection toward code execution. According to Cloudflare’s analysis, the RCE path is reachable when a persistent object cache is not enabled, which is a common default. The batch endpoint has shipped with WordPress since version 5.6 (November 2020); the batch-route confusion that opens the chain arrived in version 6.9, released December 2, 2025.

The 7.0.2 release modified three core files covering both fixes: /wp-includes/rest-api/class-wp-rest-server.php, /wp-includes/class-wp-query.php, and /wp-includes/rest-api.php.

Which WordPress Versions Are Affected?

Although WordPress enabled forced updates through its auto-update system, it has not confirmed whether the forced push reaches sites with auto-updates disabled. Verify the version you are actually running rather than assuming the update landed.

Is wp2shell Being Exploited in the Wild?

No confirmed in-the-wild exploitation has been reported as of July 18, 2026. At the time of the initial disclosures on July 17-18, Beazley Security and the researcher reported no public exploit. A public proof-of-concept has since appeared that confirms the SQL injection and can read the database, including administrator password hashes. The final step from SQL injection to full code execution – which depends on cracking a recovered hash and uploading a plugin – has not been publicly published. With the SQL injection demonstrated and WordPress core being open source, the window before wider exploitation is expected to be short.

How to Mitigate wp2shell

1. Update immediately to WordPress 6.9.5 or 7.0.2 (or 6.8.6 on the 6.8 branch). This is the only complete fix.
2. If you cannot update today, block anonymous access to the batch API as a temporary stopgap:
   • At the WAF level, block both /wp-json/batch/v1 and ?rest_route=/batch/v1. Blocking only the /wp-json path leaves the query-string route open.
   • Alternatively, install a plugin that disables anonymous REST API access, or use the drop-in plugin published at wp2shell[.]com that rejects anonymous /batch/v1 requests at rest_pre_dispatch.
   • Both approaches may break legitimate integrations and should be treated as emergency measures only.
3. A persistent object cache (for example Redis or Memcached) can block the exploit path, per Cloudflare’s analysis, but treat this as incidental hardening only. It is not a substitute for patching, so update regardless.
4. Use the public checker at wp2shell[.]com to verify whether your instance is vulnerable.
5. Monitor traffic against the /batch/v1 endpoint and for anomalous author__not_in parameters, which will be the earliest indicators of exploitation attempts.
6. Inventory every WordPress instance across your organization, including staging, marketing, and subsidiary sites, and confirm their versions. Forgotten installations are the most likely to remain unpatched.

How SOCRadar Helps

SOCRadar’s Attack Surface Management continuously discovers internet-facing WordPress instances across your organization and flags version-based exposure, which matters here because no CVE-keyed scanner detection existed at disclosure. SOCRadar’s Vulnerability Intelligence tracks CVE-2026-63030 and CVE-2026-60137 with exploit status and mitigation guidance as the situation develops, so security teams can prioritize patching before attackers weaponize the full chain.

wp2shell FAQ for CISOs

What is wp2shell?

wp2shell is a critical pre-authentication Remote Code Execution vulnerability in WordPress core. It chains a REST API batch-route confusion flaw (CVE-2026-63030) with a SQL injection issue (CVE-2026-60137). An unauthenticated attacker can exploit it with crafted HTTP requests against a default WordPress install, with no plugins and no login required. Successful exploitation gives full server control.

Which versions are affected?

WordPress 6.9.0 to 6.9.4 and 7.0.0 to 7.0.1 are exposed to the full RCE chain. Versions 6.8.0 to 6.8.5 carry only the SQL injection component, fixed in 6.8.6. Versions at or below 6.8.5 are not affected by the RCE chain. Update to 6.9.5, 7.0.2, or newer.

How critical is it?

Very high. The GitHub advisory rates the RCE chain Critical, and Rapid7 lists CVSS 7.5 for the batch-route confusion. WordPress enabled forced automatic updates, the attack needs zero credentials, and it works on stock installs. A public proof-of-concept for the SQL injection component has already appeared.

Is there a public exploit?

Partially. A public proof-of-concept has appeared that confirms the SQL injection and can read the database, including administrator password hashes. Searchlight has not published the final jump from SQL injection to full code execution, which requires cracking a recovered hash and uploading a plugin. As of July 18, 2026, no confirmed exploitation in the wild has been reported. Treat that as a shrinking window, not an all-clear.

How do I check if my sites are vulnerable?

Check your version in wp-admin under “At a Glance” or in the readme.html file. Use the official checker at wp2shell[.]com from Searchlight Cyber / Assetnote, or run a scan with a tool such as WPScan. Confirm the actual running version rather than relying on scheduled-update assumptions, since forced updates can fail to apply.

How do I test safely?

Never test in production. Use an isolated staging environment running the exact vulnerable version, and only use PoC code inside a sealed-off lab against systems you own or are authorized to test. Watch for unusual POST activity to the /wp-json/batch/v1 endpoint during testing.

How do I check logs for exploitation attempts?

Review these sources:

• Web server logs (Apache/Nginx): search for requests to /wp-json/batch/v1 or ?rest_route=/batch/v1, especially with author__not_in parameters or unusual payloads.
• WordPress debug/error logs: enable WP_DEBUG_LOG and look for SQL errors or unexpected queries.
• WAF / security plugin logs (Cloudflare, Sucuri, Wordfence): look for blocked or suspicious REST API activity.
• File integrity: check timestamps in /wp-content/ for new or modified PHP files, a common artifact after RCE.

There are no wp2shell-specific published indicators (filenames or IPs) in the primary disclosures, so do not rely on a fixed IoC list. Preserve logs before any cleanup.

What should I do right now?

1. Update all WordPress sites to the patched versions.
2. Verify the update actually applied, since forced updates can fail.
3. Enable automatic minor updates where not already on.
4. Review and harden REST API exposure if the batch endpoint is not needed.
5. Scan for web shells and backdoors, and review admin accounts and application passwords against an approved inventory.
6. Monitor logs closely for the next 48-72 hours.

Do I need to worry about older sites?

Only sites on 6.9.0-6.9.4 or 7.0.0-7.0.1 face the full RCE chain. Sites on 6.8.0-6.8.5 carry only the SQL injection issue (patch with 6.8.6). Pre-6.8 installs are not affected by this chain but may have other unrelated security issues.

Is this related to the WP-SHELLSTORM webshell campaign?

No. wp2shell is a WordPress core vulnerability requiring no plugins. The WP-SHELLSTORM campaign exploited an already-public, already-patched caching-plugin flaw that only worked on a non-default setting, reportedly compromising over 17,000 sites. The two are unrelated, though both reinforce the need to keep core, plugins, and themes patched.

What are the prevention tips going forward?

Keep core, plugins, and themes updated automatically where possible; deploy a capable WAF; limit REST API exposure when it is not needed; run regular vulnerability scans; enable a persistent object cache where practical (which incidentally closes this exploit path); and use hosting with strong tenant isolation.

Bottom line: patch today. The SQL injection half is already demonstrated in a public PoC, and the full chain is expected to follow.