"This is the one you patch tonight. Not tomorrow. Tonight."

On July 17, 2026, the WordPress Security Team released WordPress 7.0.2 — a critical security update that patches a chain of two vulnerabilities allowing unauthenticated remote code execution on any affected WordPress installation. The update also backports fixes to WordPress 6.9 (6.9.5) and 6.8 (6.8.6).

If you're running WordPress 6.8, 6.9, or 7.0 — and you haven't updated yet — your site is currently exploitable by anyone on the internet. No authentication required. No plugins needed. No special configuration. Just an HTTP request.

Update (July 18): This is no longer a theoretical risk. Security firm PatchStack reported exploitation attempts against CVE-2026-63030 within hours of disclosure, and a working proof-of-concept exploit is now circulating publicly. If you're still unpatched, treat this as an active attack, not a "get to it this week" item.

Here's what you need to know, what to do right now, and how to check if you're already protected.


What Happened: Two Vulnerabilities, One Chain

The WordPress Security Team patched two vulnerabilities that, when chained together, escalate from SQL injection to full remote code execution. They're tracked as CVE-2026-60137 and CVE-2026-63030, and the chain has been dubbed "WP2Shell" by security researchers.

CVE-2026-60137 — SQL Injection in WP_Query

Severity: High Affected versions: WordPress 6.8 through 7.0.1 Patched in: 6.8.6, 6.9.5, 7.0.2

This vulnerability exists in the WP_Query component. The author__not_in parameter lacks proper escaping and query preparation, allowing an unauthenticated attacker to inject SQL statements. The issue was reported by researchers TF1T, dtro, and haongo.

What an attacker can do: - Read arbitrary data from the WordPress database (user credentials, post content, configuration) - Modify or delete database records - Potentially escalate to further exploitation

On its own, this is a serious information-disclosure bug. Chained with CVE-2026-63030, it's a stepping stone to full server compromise — which is why it can't be treated as a "patch when convenient" issue even though it's rated High rather than Critical.

CVE-2026-63030 — REST API Batch Route Confusion → RCE

Severity: Critical Affected versions: WordPress 6.9.0 through 6.9.4, 7.0.0 through 7.0.1 Patched in: 6.9.5, 7.0.2 CVSS score: 7.5 per the official GitHub Security Advisory (classified Critical by WordPress); Wordfence independently scored the full chain 9.8.

This vulnerability is a REST API batch-route confusion issue in the /wp-json/batch/v1 endpoint. Discovered by Adam Kues at Assetnote / Searchlight Cyber, it allows an unauthenticated attacker to confuse the routing mechanism and chain it with the SQL injection from CVE-2026-60137 to achieve remote code execution.

What an attacker can do: - Execute arbitrary PHP code on the server - Install backdoors, create admin accounts, exfiltrate data - Take complete control of the WordPress installation - Use the compromised site as a pivot point into the hosting environment

Key detail: This is a core vulnerability — it affects stock WordPress installations with default settings. No plugins, themes, or custom configuration required.

Why the Chain Matters

Neither vulnerability alone is as dangerous as the chain. The SQL injection gives database access. The batch route confusion gives code execution. Together, they create a complete compromise path from an unauthenticated HTTP request to full server control.

Rapid7's initial analysis, published the evening of disclosure, cautioned that a lack of confirmed exploitation at that point shouldn't be read as low risk — noting the attack requires no authentication and WordPress's footprint is enormous. That caution has since proven warranted: exploitation attempts and a public PoC followed within about a day.


Which WordPress Versions Are Affected

WordPress Version CVE-2026-60137 (SQLi) CVE-2026-63030 (RCE) Fix Version
6.8.x (prior to 6.8.6) ✅ Affected ❌ Not affected 6.8.6
6.9.0 – 6.9.4 ✅ Affected ✅ Affected 6.9.5
7.0.0 – 7.0.1 ✅ Affected ✅ Affected 7.0.2
7.1 beta ✅ Affected ✅ Affected 7.1 Beta 2
Prior to 6.8 ❌ Not affected ❌ Not affected N/A

If you're running any version between 6.8.0 and 7.0.1, you need to update now.


What to Do Right Now

Step 1: Check Your WordPress Version

Log in to your WordPress admin dashboard. Your version is displayed at the bottom of any admin page, or at Dashboard → Updates.

Alternatively, check via SSH:

wp core version

Or check your wp-includes/version.php file:

grep '\$wp_version =' wp-includes/version.php

Step 2: Update Immediately

WordPress 7.0.x → 7.0.2: - Go to Dashboard → Updates and click "Update Now" - WordPress has enabled forced auto-updates for affected installations, but don't rely on that — check manually

WordPress 6.9.x → 6.9.5: - Same process — Dashboard → Updates

WordPress 6.8.x → 6.8.6: - Same process — Dashboard → Updates

Via WP-CLI:

wp core update
wp core update-db

Via SSH:

# Back up first
wp db export backup-$(date +%Y%m%d).sql

# Update
wp core update
wp core update-db

Step 3: Verify the Update

After updating, confirm your version:

wp core version

You should see 6.8.6, 6.9.5, or 7.0.2 depending on your branch.

Step 4: If You Can't Update Immediately

If updating right now isn't possible (staging environment, custom deployment pipeline, compatibility concerns), Searchlight Cyber recommends these emergency temporary mitigations:

  1. Block anonymous access to the batch API at your WAF level:
  2. Block /wp-json/batch/v1
  3. Block ?rest_route=/batch/v1

  4. Install a plugin that blocks anonymous REST API access entirely

⚠️ Both mitigations may impact legitimate site functionality. They are temporary measures only — update as soon as possible. With PoC code already public, treat these as a stopgap measured in hours, not days.

If you're behind Cloudflare, the WAF managed ruleset already includes protections for this vulnerability chain. Cloudflare released an emergency rule on July 17, 2026. Verify it's active in your dashboard under Security → WAF → Managed Rules.


How to Check if You've Already Been Compromised

If you updated but want to verify your site wasn't exploited before the patch:

1. Check for New Admin Accounts

wp user list --role=administrator

Look for any accounts you don't recognise.

2. Check for Suspicious Files

# Look for recently modified PHP files
find /path/to/wordpress -name "*.php" -mtime -7 -type f

3. Check Database for Injections

wp db query "SELECT user_login, user_email, user_registered FROM wp_users WHERE user_registered > '2026-07-01'"

4. Review Access Logs

Look for unusual POST requests to /wp-json/batch/v1 from unknown IP addresses, especially from July 17, 2026 onward — this is when PatchStack first observed exploitation attempts.

5. Scan with Wordfence or Similar

Wordfence Premium, Care, and Response users received firewall protection on July 17. Free users will get it after the standard 30-day delay (around August 16). If you don't have Wordfence, consider running a scan with another security tool in the meantime.


Why This Vulnerability Is Different

Most WordPress security issues affect plugins or themes — third-party code that you choose to install. This one is in WordPress core itself. That means:

  • Every WordPress installation is a potential target — not just those with vulnerable plugins
  • No special configuration is required — default installations are affected
  • The attack is unauthenticated — no login, no credentials, no social engineering
  • The impact is complete — from SQL injection to full server control
  • Exploit code is already public — this isn't a "someday" risk, it's an active one

The combination of "core vulnerability" + "unauthenticated" + "RCE" + "public exploit code" makes this one of the most significant WordPress security events in recent years.


What This Means for Your Security Strategy

This vulnerability is a reminder that security isn't a one-time purchase — it's an ongoing practice:

  1. Keep WordPress updated. Automatic updates exist for a reason. Enable them, and verify they're working.

  2. Monitor for security releases. WordPress.org publishes security releases at wordpress.org/news. Subscribe to their security category.

  3. Use a WAF. Cloudflare, Wordfence, or Sucuri can provide protection while you patch. But a WAF is a temporary shield, not a permanent solution.

  4. Run regular security scans. You can't fix what you don't know about. A baseline scan tells you your exposure before an attacker does.

Run a free security scan →

  1. Have an incident response plan. If you discover you've been compromised, you need to know what to do — not figure it out while your site is down.

The Bottom Line

WordPress 7.0.2 is a critical security release. If you're running WordPress 6.8 through 7.0.1, update now. The vulnerabilities allow unauthenticated attackers to take complete control of your site — no plugins required, no special setup needed — and exploit code is already circulating publicly.

The patch is available. The auto-update is rolling out. But don't wait for it. Check your version, update manually, and verify you're protected.

This isn't a "wait and see" situation. It's a "patch tonight" situation.


WardenBit helps small businesses find and fix security gaps before they become breaches. Our automated scanner checks your website across 40+ categories — including WordPress version detection, security headers, and known vulnerabilities — in under 60 seconds. Run a free scan →