On Friday, July 17, WordPress shipped versions 6.9.5 and 7.0.2 to plug wp2shell, a hole that lets someone run code on a site with no username and no password. It was being exploited that same evening. By Sunday, VulnCheck had counted more than twenty distinct public exploits. If your company has a WordPress site —and with over 500 million sites worldwide according to Searchlight Cyber, odds are you do—, this week's question isn't technical: it's who updated it? And if the answer is "I don't know", this post is about you.
What wp2shell is and why it isn't "just another advisory"
wp2shell isn't one flaw, it's two chained together, and both live in WordPress core, not in a plugin: CVE-2026-63030 (CVSS 9.8), a route confusion in the REST API batch endpoint (/wp-json/batch/v1) introduced in version 6.9, and CVE-2026-60137, a SQL injection in the author__not_in parameter of WP_Query that had been around since 6.8. Separately they're ugly; chained, they let an anonymous attacker go from an HTTP request to running code on the server.
What makes it different: it needs nothing from you. No vulnerable plugin, no careless user, no odd configuration. A default, out-of-the-box installation was exploitable. The vast majority of WordPress scares in recent years came from plugins and themes; serious core flaws are rare. This one is in core, it's pre-authentication, and it's code execution. The full trilogy.
The versions, plainly: the full chain (RCE) affects 6.9.0–6.9.4 and 7.0.0–7.0.1, fixed in 6.9.5 and 7.0.2. The 6.8 branch has the SQL injection on its own (no RCE chain): 6.8.0–6.8.5, fixed in 6.8.6. If your version isn't one of those three fixes —or newer—, stop reading and update.
From patch to weapon in one evening
The weekend's timeline deserves a slow read, because it's the real story. On Friday the 17th at 5:45 PM (US Eastern), Rapid7 published that there was no confirmed exploitation. Before 7 PM that same day, Patchstack was already reporting active exploitation. Between "no evidence" and "it's happening", not even ninety minutes went by. By Sunday the 19th, VulnCheck had verified more than two dozen unique public exploits. Tenable attributes part of that speed to AI-assisted exploit development tooling.
We already said it when covering July's record Patch Tuesday: the industry's capacity to manufacture exploits has scaled with AI; companies' capacity to apply patches has not. "I'll patch in the end-of-month change window" was a reasonable plan in 2016. In 2026, the distance between patch and weapon is measured in hours, and the end-of-month change window is an eternity.
The weekend paradox: the "abandoned" sites were the ones saved
Here comes the uncomfortable part. WordPress force-pushed the automatic update to installations that had it enabled. Result: the site nobody has looked at since 2022 patched itself over the weekend. And who stayed exposed all weekend? The installations that had automatic updates deliberately disabled: for change control, for a heavily customized theme that "breaks if you update", for a staging pipeline that validates before deploying. In other words: the more "managed" the site looked, the better its odds of spending the weekend exploitable, waiting for someone to come back on Monday.
The lesson isn't "turn on auto-updates and pray". It's that having a process is not the same as having maintenance. Maintenance means someone exists whose job includes finding out on a Friday afternoon that a critical patch is out, assessing it, and deciding to apply it now —even though it's Friday—. If your change process turns a critical security patch into a ticket that waits until Monday, your process is optimized for a world that no longer exists.
Who maintains your website? (seriously, put a name to it)
The pattern we see over and over in companies: the website was built by an agency four years ago. The project was delivered, paid for and closed. Since then, the website is a piece of furniture: unveiled once, then forgotten. Nobody renews its plugins, nobody reads its logs, nobody knows what PHP version runs underneath. Until a week like this one, when the furniture turns out to be what it always was: a server of yours, exposed to the Internet 24 hours a day, with your brand on the door.
And a compromised WordPress is almost never "noticeable". They don't deface your homepage: they use you. To host phishing pages, for SEO spam, to distribute malware from your domain. You find out when your domain lands on blocklists, corporate email stops getting delivered, and the one who tells you is a customer. The cost isn't the website: it's everything your brand drags behind it.
What to do today, in this order
- 1.Check the version. Dashboard → Updates, or
wp core versionwith WP-CLI. If you're not on 7.0.2, 6.9.5 or 6.8.6 (or newer), update right now, even if you're reading this over lunch. - 2.Don't assume the auto-update fired: verify it. Installations with automatic updates disabled, with core tracked in git, or on unusual hosting setups were left out of the forced update. Searchlight Cyber, who uncovered the flaw, published a check tool at wp2shell.com.
- 3.If you were exposed between the 17th and your update, investigate. POST requests to
/wp-json/batch/v1in the logs, new administrators nobody created, recent PHP files inuploads/. At any sign: rotate passwords and salts, and treat the site as compromised until proven otherwise. - 4.And the usual: this time it was core, but the real attack surface of the average WordPress is still its plugins. Fewer plugins, better updated, and drop the ones their author hasn't maintained in a year.
The structural fix isn't a plugin: it's an owner
Everything above is, literally, a patch. The structural fix is that your website —and the server it lives on— has an owner. Owner means: security patches applied with judgment and with urgency when it's due, backups someone has actually test-restored, monitoring that alerts when something odd happens, and a person reachable on a Friday at 7 PM. None of this is glamorous. Neither is paying to clean up a compromised site and explaining it to your customers.
At everyWAN we don't build websites; that's not our trade. We do the layer underneath: IT maintenance with patching, backups and monitoring as a discipline —whether it's a virtualization cluster or the server your website lives on— and 24/7 support so a Friday-afternoon advisory doesn't wait until Monday. It's the part of IT that never shines in a slide deck. It's also the part that decided, this past weekend, which websites woke up on Monday still belonging to their owners and which didn't.
In short
wp2shell is fixed with one click. What isn't fixed with one click is not knowing whose job that click was. This week the click was in WordPress; next month it will be somewhere else. The question remains the same: when the next critical patch drops on a Friday afternoon, who on your side is going to notice?
Sources (verified): technical detail of the chain, affected and fixed versions, and the /wp-json/batch/v1 endpoint — Tenable and BleepingComputer; timeline patch (Jul 17) → exploitation that evening (Rapid7/Patchstack) → more than two dozen exploits verified by VulnCheck on Jul 19 — Servola; forced update and general advisory — Help Net Security. The estimate of over 500 million WordPress websites is Searchlight Cyber's (who uncovered the flaw), as cited by BleepingComputer.
Does your website (and the server underneath) have an owner?
At everyWAN we've been maintaining infrastructure since 1996: patching with judgment, tested backups and monitoring that alerts you before a customer does. If wp2shell caught you not knowing who to call, that's the conversation you're overdue for.
Talk to everyWAN
Microsoft 365
ES 
CAT 
EN