On July 17, 2026, WordPress pushed a forced security update to every site running versions 6.8.0 through 7.0.1. The reason: two vulnerabilities that, when chained together, give any unauthenticated attacker on the internet full remote code execution on your WordPress site. No login required. No user interaction. No exploit complexity. The security community is calling the chain wp2shell, and if you haven't verified your sites are patched, stop reading and go check right now.

This is not a theoretical risk. Proof-of-concept exploit code hit GitHub the same day the patches dropped. By July 18, security firms watchTowr and Searchlight Cyber were reporting widespread scanning activity. Qualys confirmed active exploitation in the wild on July 20. If your site was running an affected version and didn't auto-update, there is a real chance it has already been compromised.

What wp2shell actually does

The chain combines two separate bugs. Neither one alone is catastrophic. Together, they are about as bad as a WordPress vulnerability gets.

CVE-2026-63030 (CVSS 9.8, Critical) is a REST API batch-route confusion flaw. WordPress has a batch endpoint at /wp-json/batch/v1 that is supposed to handle authenticated batch requests. The bug is an interpretation conflict — the endpoint accepts requests in a way that bypasses authentication checks under certain conditions. An attacker can send a crafted POST to the batch endpoint and reach internal API routes that should require a logged-in user. No credentials needed.

CVE-2026-60137 (CVSS 9.1, Critical) is a SQL injection vulnerability in WP_Query, specifically in the author__not_in parameter. On its own, this lets an attacker read arbitrary data from the WordPress database — including password hashes for every user, including administrators. On versions 6.8.0 through 6.8.5, this is where it stops. Painful, but not full code execution.

The problem is versions 6.9.0 through 7.0.1. On those versions, CVE-2026-63030 gives unauthenticated access to the batch API, which can route requests to internal endpoints that trigger CVE-2026-60137. The SQL injection then extracts an admin password hash. The attacker cracks it — or in some PoC variants, uses the SQL injection to write a webshell directly — and now they own the server. Full administrative access. The ability to install plugins, modify themes, inject redirects, deploy cryptominers, or pivot to anything else connected to that server.

Adam Kues of Searchlight Cyber discovered and reported both vulnerabilities through WordPress's HackerOne program. The WordPress.org team responded by enabling forced auto-updates for all affected versions, which is an unusual step they reserve for the most severe disclosures.

Who is affected

Every WordPress site running these versions is vulnerable:

  • Full RCE chain (unauthenticated): 6.9.0–6.9.4 and 7.0.0–7.0.1
  • SQL injection only (still serious): 6.8.0–6.8.5

That covers the vast majority of active WordPress installations. WordPress powers over 500 million websites. Even if only a fraction were on these specific versions, the attack surface is enormous.

What you need to do

First, verify your version. Do not assume auto-update worked. Open your WordPress dashboard and check "At a Glance" on the main screen, or run wp core version if you have WP-CLI access. Check every site you manage, including staging, development, and "we'll get to it later" sites that are still publicly accessible.

The patched versions are:

  • 7.0.x → update to 7.0.2
  • 6.9.x → update to 6.9.5
  • 6.8.x → update to 6.8.6

If you cannot update immediately — and "immediately" means today, not this week — there are temporary mitigations. Block both /wp-json/batch/v1 and /?rest_route=/batch/v1 at your WAF. Block both. Blocking only one leaves the alternate route open. Cloudflare has already pushed managed WAF rules for both CVEs. A plugin that restricts anonymous REST API access is another option, though it may break functionality that depends on public API endpoints.

After you patch

Patching closes the door, but it does not undo damage that may have already happened. If your site was running an unpatched version between July 17 and now, treat it as potentially compromised. Run wp core verify-checksums to check for file integrity mismatches. Look for new admin accounts you did not create. Check wp-content/uploads and wp-content/plugins for unexpected PHP files. Review your database for injected redirects or JavaScript. If anything looks off, restore from a backup taken before July 17 and apply the update before bringing the site back online.

The speed of this exploit chain — from disclosure to public PoC to active exploitation in under 24 hours — is the new normal for WordPress vulnerabilities. The platform's market share makes it the single most attractive target in web security. Forced auto-updates are a safety net, not a guarantee. Own your patching. Verify it yourself. Every time.