SURIQ
On July 17, WordPress shipped an emergency security release, versions 6.9.5 and 7.0.2, that closes a pre-authentication remote code execution hole in Core. The flaw, nicknamed wp2shell and tracked as CVE-2026-63030, needs no account, no plugin, and no click from a victim. A single anonymous request to a default install can end in code running on the server.
One thing to be clear about up front: as of July 18, no in-the-wild exploitation has been reported. Both Rapid7 and reporting from The Hacker News say attacks have not been observed yet. That is the good news and the reason to move now. The researchers are holding back the technical writeup, but a working fix is public, and a public fix is a roadmap. Treat the quiet as a head start, not a reprieve.
Two bugs, chained into a takeover
wp2shell is really two problems stacked together. The base layer is a SQL injection issue, CVE-2026-60137, that reaches back to WordPress 6.8. On its own it is serious but bounded. The second layer, the one that only exists from 6.9 onward, is a route-confusion bug in the REST API batch endpoint at /wp-json/batch/v1. That endpoint was built to let the block editor bundle several API calls into one request. The confusion in how it resolves those bundled routes is what lets an anonymous caller reach the injection and turn a database read into code execution on the host.
The discovery came from Adam Kues at Assetnote, the research arm of Searchlight Cyber, reported through WordPress's HackerOne program. In their advisory, the team wrote that they are not releasing technical details yet to give defenders time to patch. There is no public exploit code, which is exactly why the next few days matter.
Who is exposed, and the one setting that blunts it
Two questions decide whether this touches you.
Version. The remote code execution hits the 6.9.x line below 6.9.5 and the 7.0.x line below 7.0.2, so any build from 6.9.0 up to and including 6.9.4, or 7.0.0 and 7.0.1. The separate injection reaches every branch back to 6.8. If you run any 6.9.x or 7.0.x below the fixed builds, assume you are in scope. The vulnerable code shipped with 6.9 back in December 2025, so this has been latent on a lot of sites for months.
Object cache. Per Cloudflare's writeup, the code path that reaches execution only opens on a site with no persistent object cache running. A stock WordPress install does not ship one, so most default and small self-hosted sites are exposed. Sites fronted by Redis or Memcached as a persistent object cache do not reach the RCE path, though the underlying injection still argues for patching. If you are not sure whether you run one, assume you do not.
A note on severity, because the numbers disagree. WordPress's GitHub advisory classifies wp2shell as Critical, while an early CVSS score of 7.5 has also circulated. For an unauthenticated, no-interaction path to code execution on the most widely run content management system on the web, the Critical label is the one to plan around.
Patch now, then confirm the update actually landed
Update to 7.0.2 or 6.9.5 depending on your branch. Sites on 6.8 should move to 6.8.6 for the injection fix, and the same patch is in the 7.1 Beta 2 line. WordPress.org pushed forced automatic updates for affected installs, so many sites will already be safe, but do not assume it. Disabled auto-updates, a locked filesystem, or a staging clone that never phones home can all leave a box behind. Log in, check the version string, and confirm it reads a fixed build. Searchlight published a checker at wp2shell.com if you want an external read on a site.
If you genuinely cannot patch in the next few hours, the interim move is to block anonymous access to the batch route, /wp-json/batch/v1 and the ?rest_route=/batch/v1 form, at your web server or a firewall in front of it. Cloudflare shipped two managed rules for this on July 17 at 17:03 UTC, set to block by default across all plans, so sites behind it get some cover for free. Blocking the route can affect legitimate editor functionality, so treat it as a stopgap until the update is in, not a substitute for it.
How to tell if you were reached before you patched
Patching closes the door. It does not tell you whether anyone walked through it during the window between December's 6.9 release and today. For any internet-facing site, that is the question worth an hour tonight.
Start in the web server access logs. Anonymous POST requests to /wp-json/batch/v1 or to ?rest_route=/batch/v1 from clients with no valid session are the signal to pull on. A normal WordPress site sees batch calls from logged-in editors, not from anonymous internet traffic, so unauthenticated hits to that route stand out. Widen from there to injection-style patterns in REST parameters around the same timestamps.
The higher-value hunt is for what a successful attempt leaves behind. Post-exploitation on WordPress almost always means a web shell: a new or modified PHP file dropped somewhere under the webroot, often in wp-content/uploads or salted into a plugin directory where a stray file blends in. File integrity monitoring across wp-content and wp-includes catches the write even when the request that caused it is long gone from rotated logs. Pair that with any unexpected outbound connection from the web host. In ATT&CK terms you are looking for Exploit Public-Facing Application (T1190) followed by a Web Shell (T1505.003).
This is the layer a managed detection service earns its keep on. Suriq watches web hosts for exactly this shape of event, the anonymous hit on a sensitive endpoint and the file that appears after it, and raises an alert mapped to the ATT&CK technique so an analyst can judge it rather than a logline scrolling past unread. The point is not that a tool patches for you. It is that you find out in minutes if a site was touched in the window, instead of finding out from someone else weeks later.
The window is the whole story
There is no proof anyone is exploiting wp2shell today. There is a public patch, a public scanner, and one of the largest install bases on the internet running the vulnerable code. Those three facts tend to collapse the gap between disclosure and mass scanning to days. WordPress powers a large share of the web, and commodity attackers are very good at turning a Core fix into a spray-and-pray campaign the moment the details are worked out. Update this week, verify it took, and check your logs while there is still a quiet week to check them in.