WordPress 7.0.2 and the wp2shell Exploit: Why You Need to Update Today

On July 17, 2026, the WordPress security team shipped one of the most serious core security releases I’ve seen in years. WordPress 7.0.2 patches a vulnerability chain — informally nicknamed wp2shell — that allows an attacker to run code on a default WordPress install without logging in. No stolen password, no vulnerable plugin, no misconfiguration required. Just a stock WordPress site on an affected version.

I spent this weekend checking and updating every client site I manage, and in this post I’ll walk you through what the vulnerability actually is, how to check whether your site is safe, and the steps I recommend every site owner take this week.

What Is wp2shell?

WordPress 7.0.2 fixes two separate security issues that are dangerous on their own but devastating when combined:

• CVE-2026-63030 — a REST API batch-route confusion bug. In simple terms, WordPress could be tricked into routing a request through the wrong internal endpoint, bypassing the permission checks that would normally apply.
• CVE-2026-60137 — a SQL injection flaw in WordPress core, reachable through the author__not_in query parameter.

Individually, each of these would be a bad week for the WordPress ecosystem. Chained together, they become a pre-authenticated remote code execution (RCE) exploit: the route confusion gets the attacker’s request to the vulnerable parameter, and the SQL injection escalates from there to executing code on your server. That’s why researchers gave the chain its own nickname — wp2shell, as in “from WordPress to a shell on your server.”

Credit where it’s due: the RCE chain was responsibly disclosed by Adam Kues of Assetnote / Searchlight Cyber, and the SQL injection issue was reported by a team of researchers (TF1T, dtro, and haongo). Because it was disclosed responsibly, patches shipped before public exploitation — but now that the details are out, attackers are actively scanning for unpatched sites. The window to update is short.

Which WordPress Versions Are Affected?

This is the part to read carefully, because the affected range is wide:

• WordPress 7.0.0 – 7.0.1 — affected by both issues. Fixed in 7.0.2.
• WordPress 6.9.0 – 6.9.4 — affected by both issues. Fixed in 6.9.5.
• WordPress 6.8.0 – 6.8.5 — affected by the SQL injection issue only. Fixed in 6.8.6.
• Versions before 6.8 — not affected by these specific flaws (but if you’re running something that old, you have other problems — more on that below).
• WordPress 7.1 Beta 1 — affected; fixed in Beta 2.

The severity is high enough that WordPress.org has enabled forced automatic updates for sites running affected versions. Many sites have already been patched in the background without their owners doing anything. But “many” is not “all” — and that’s exactly why you should verify rather than assume.

How to Check Your Site Right Now

Checking takes under a minute. Log into your WordPress dashboard and look at the “At a Glance” widget on the main Dashboard screen, or go to Dashboard → Updates. You want to see 7.0.2, 6.9.5, or 6.8.6 (depending on your branch).

If you see an affected version, update immediately: click Updates → Update Now. The 7.0.2 release is a small, targeted security patch — it doesn’t introduce new features, so the risk of it breaking your theme or plugins is minimal. In my experience updating dozens of client sites this week, I haven’t hit a single compatibility issue.

Why Auto-Updates Sometimes Don’t Fire

A few common reasons a site misses a forced update:

• Automatic updates are disabled in wp-config.php (look for AUTOMATIC_UPDATER_DISABLED or WP_AUTO_UPDATE_CORE set to false).
• Version control (Git) manages the codebase, which WordPress detects and backs off from.
• File permissions or ownership prevent WordPress from writing to its own files.
• Your host manages core updates on its own schedule.

If any of these apply to you, the forced update likely never ran — and your site is still exposed. Managed hosts like Pantheon and others pushed the patch quickly, but if you’re on a plain VPS or shared hosting, the responsibility is yours.

What If You Think You’ve Been Compromised?

If your site sat unpatched for days after July 17, it’s worth a health check. Signs to look for: unfamiliar admin users, recently modified core files, unexpected PHP files in wp-content/uploads, and odd scheduled tasks (cron jobs). A scanner plugin can help, but if you find anything suspicious, the safest path is restoring from a clean backup taken before the compromise and then patching immediately.

This is also your regular reminder that backups only help if they exist. If you don’t have automated off-site backups running, set them up today — before you need them.

The Bigger Lesson for Site Owners

I build and maintain WordPress sites for a living, and here’s my honest take: this incident is not a reason to panic about WordPress. Core RCE vulnerabilities of this severity are rare, the security team’s response was fast, and the forced-update system did exactly what it was designed to do for millions of sites.

But it is a reason to take three habits seriously:

• Leave automatic security updates on. The sites that were protected fastest were the ones that let WordPress patch itself. Unless you have a specific operational reason to manage updates manually, don’t fight the auto-updater.
• Stay on a supported branch. Notice that versions before 6.8 weren’t affected here — but they’ve stopped receiving guaranteed security backports for other issues. Running ancient WordPress isn’t a security strategy; it’s deferred risk.
• Have a maintenance routine (or someone who does). Updates, backups, malware scanning, uptime monitoring — these are boring right up until the day they’re the only thing that matters.

My Recommended Action List

If you only do five things this week, do these: check your WordPress version today and update to 7.0.2 / 6.9.5 / 6.8.6 if needed; confirm automatic background updates are enabled; verify you have a recent, restorable backup; scan for signs of compromise if you were unpatched for several days; and update your plugins and themes while you’re in the dashboard anyway.

If you’re not sure whether your site was patched, or you’d rather have someone handle updates, security, and backups for you on an ongoing basis, that’s exactly the kind of work I do for my maintenance clients. Get in touch and I’ll take a look at your site — usually the check itself takes me just a few minutes, and the peace of mind lasts a lot longer.