If you run a WordPress site and you’ve updated it three times in the past month, you’re not imagining things. Between July 17 and August 12, 2026, WordPress core shipped three back-to-back security releases — 7.0.2, 7.0.3, and 7.0.4 — each one closing a critical or high-severity hole. The first of the three fixed a vulnerability now widely known by its nickname, “wp2shell,” and it’s the one worth understanding in detail, because it was pre-authentication, actively exploited within days of becoming public, and capable of handing an attacker a full webshell on a default WordPress install with no login required.
Here’s what actually happened, whether your site was in the blast radius, and what to check right now.
The short version
WordPress 7.0.2 (July 17) fixed a two-part vulnerability chain — an unauthenticated SQL injection combined with a REST API routing flaw — that let attackers run arbitrary code on unpatched sites without logging in. WordPress 7.0.3 (August 6) followed with fixes for 11 more issues, including a separate pre-authentication flaw affecting the login screen. WordPress 7.0.4 (August 12) closed a critical file-upload vulnerability affecting any site using the Imagick image library. If you’re on 7.0.4 (or a patched point release on an older branch — WordPress backported these fixes as far back as version 4.7), you’re covered. If you’re not sure, checking is the first thing to do before reading any further.
What is wp2shell, exactly?
wp2shell is the name security researchers gave to the vulnerability chain patched in WordPress 7.0.2. It combines two separate bugs: a SQL injection in a WP_Query parameter, and a routing confusion in WordPress’s REST API “batch” endpoint (/wp-json/batch/v1) that let an attacker chain requests together in a way the API wasn’t designed to allow. On its own, the SQL injection (tracked as CVE-2026-60137) could expose site data. Combined with the batch-routing flaw (CVE-2026-63030), the two bugs together allowed a completely unauthenticated attacker to execute arbitrary PHP code on the server — the technical definition of a full site takeover.
The flaw was reported by security researcher Adam Kues at Assetnote/Searchlight Cyber, alongside a second SQL injection reported independently by researchers TF1T, dtro, and haongo. WordPress’s security team responded with a forced background update rollout on July 18, pushing the fix automatically to compatible sites — an unusually aggressive response that reflects how serious the team considered it.
That seriousness turned out to be justified. Once technical details became public, security firms tracking exploitation began seeing real attacks within days, with attackers dropping webshells ranging from simple one-line backdoors to elaborate 150KB PHP panels with full file management, database access, and privilege escalation built in.
Am I affected?
The full remote-code-execution chain affected WordPress 6.9.0–6.9.4 and 7.0.0–7.0.1. The SQL injection component alone also reached back to 6.8.0–6.8.5, though it couldn’t achieve full code execution on those older versions. If your site was running any of those versions between the vulnerability’s disclosure and your next update, it was exposed during that window — whether or not it was actually attacked depends on whether anyone found it.
Two things are worth checking specifically: whether automatic background updates are enabled on your install (many managed hosts turn this on by default, which means you may already be patched without realizing it), and whether you or a plugin has disabled or restricted the REST API — sites running certain security plugins with the API locked down were less exposed even before the official patch.
How to check if you were already compromised
Updating closes the door, but it doesn’t undo anything that happened before you updated. If your site was on a vulnerable version for any length of time after mid-July, it’s worth actually checking rather than assuming you got lucky. Signs worth looking for: administrator accounts you don’t recognize, unfamiliar PHP files in your uploads folder or inside plugin directories (webshells are often disguised with names that look like legitimate WordPress files), requests to /wp-json/batch/v1 or /?rest_route=/batch/v1 in your server access logs from IPs you don’t recognize, unexpected outbound connections from your server, and any core files that don’t match a clean WordPress install checksum. None of these are conclusive on their own, and a well-hidden webshell is specifically designed not to be obvious from the dashboard — which is the main reason a proper malware scan matters more here than a quick look around. If you want a second pair of eyes on this, our free website scan will check for exactly these indicators.
What to do right now
Update to the latest WordPress core version today if you haven’t already — this is the single highest-leverage thing you can do, and it takes minutes. If you manage multiple sites or a VPS/dedicated server with several WordPress installs, check all of them; a compromised site on shared infrastructure can be a foothold for attacking the others. If updating isn’t immediately possible for compatibility reasons, restrict access to the REST API batch endpoint at the firewall level as a stopgap — but treat that as temporary, not a substitute for patching. And if there’s any chance your site was exposed during the vulnerable window, run a proper malware scan rather than assuming everything’s fine because the site “looks normal” — that’s exactly what a well-installed webshell is built to achieve.
Why this is bigger than one vulnerability
Three emergency releases in under a month is unusual even by WordPress’s own standards, and it’s not a coincidence. WordPress’s HackerOne bug bounty program received roughly 450 vulnerability reports in July 2026 alone, compared to a historical monthly average in the 10–30 range — a jump largely attributed to AI-assisted security research accelerating how fast new flaws are found, on both the defensive and offensive sides. That shift, and what it means for how often your site needs attention going forward, is the subject of our next post.
FAQ
Do I need to do anything beyond updating WordPress? If your site auto-updates and you’re already on 7.0.4 (or a patched backport), you’re protected against these specific flaws. It’s still worth a malware scan if your site was on a vulnerable version for more than a few days, since patching doesn’t remove anything an attacker may have already planted.
Is this a plugin vulnerability or a WordPress core vulnerability? Core. This is unusual — most WordPress security incidents trace back to outdated plugins or themes, not WordPress itself. That’s part of why it drew so much attention.
How do I know what WordPress version I’m running? Log into your WordPress dashboard and check the “At a Glance” panel, or go to Dashboard → Updates.
What if I don’t manage my own hosting or updates? Ask whoever does (your host, developer, or agency) to confirm you’re on 7.0.4 or a patched equivalent, and ask specifically whether a malware check was run for the window your site may have been exposed.