Every so often a vulnerability comes along that deserves the word "important" without the usual inflation, and this is one of them. There is now an unauthenticated remote code execution flaw in WordPress core itself — not a plugin, not a theme, the core software that runs a very large share of the web. It has a name, wp2shell, and the name is the whole story: from an anonymous web request to a shell on your server, with no login required.

The patch landed on 17 July. If you run WordPress anywhere — including the marketing site you have half-forgotten about — the only question that matters this week is whether you are on the fixed version. Let me explain why this one is different, what it actually is, and why the quiet around it right now is the reason to move, not the reason to relax.

Why a core flaw is a different order of problem

For years the sensible mental model of WordPress security has been: the core is pretty good, the plugins are where you get hurt. That model is mostly right. WordPress core is mature, widely reviewed, and hardened by years of scrutiny; the mass compromises I have written about — including the crew that backdoored 25,000 sites — rode almost entirely on vulnerable plugins, not core.

wp2shell breaks that model. This is a flaw in the base software, which means it affects a stock WordPress install with no plugins, no themes, nothing added — a clean, fully-patched-until-last-week site is vulnerable purely by being WordPress on the affected versions. That is a different and much larger blast radius than a plugin bug, because you cannot dodge it by being disciplined about what you install. If you are running the affected core, you are exposed, full stop.

What it actually is

The flaw is now tracked as CVE-2026-63030. It was found by Adam Kues at Assetnote, the research arm of Searchlight Cyber, reported responsibly through WordPress's HackerOne programme, and patched on 17 July.

Technically, it lives in WordPress's REST API batch endpoint — the route at /wp-json/batch/v1 that lets clients bundle several API calls into one request. The research describes a batch-route confusion combined with a SQL injection that chains all the way to remote code execution. In plain terms: the batch mechanism could be tricked about which route it was really handling, attacker-controlled input reached a database query it should never have reached, and from that SQL injection the attacker gets to running code on the server. Each link in that chain is bad; together they are close to the worst outcome a web application can offer.

The three properties that make it serious are the ones I keep flagging on flaws like this: it is unauthenticated — no account, no credentials, nothing; it is network-reachable — a plain HTTP request to a public site; and it needs no user interaction — nobody has to click or be phished. Anonymous request in, code execution out.

The affected versions are narrow and recent: WordPress core 6.9.0 through 6.9.4, and 7.0.0 through 7.0.1. The fixes are 6.9.5 and 7.0.2 (and 7.1 Beta 2). Because the 6.9 branch only shipped in December 2025, every vulnerable site is running something less than eight months old — which produces the uncomfortable irony that the sites most exposed here are, broadly, the well-maintained ones that kept themselves current. The batch endpoint is a relatively new piece of surface, and this is the oldest lesson in security wearing new clothes: every new feature is new attack surface, even in software as scrutinised as WordPress core.

A word on the score, because it will mislead people. The CVSS rating is 7.5, which the calculator files under "high." The GitHub security advisory calls it critical, and on this occasion believe the label over the number. An anonymous request that ends in code execution on the core software behind a big slice of the internet is as bad as web vulnerabilities get, whatever a scoring formula outputs. If you were waiting for a 9-point-something to take it seriously, don't.

The quiet before the storm

Here is the part that should change your behaviour today rather than next sprint. As of the last reporting, there is no confirmed exploitation in the wild, and no public proof-of-concept. Searchlight is deliberately sitting on the technical details and has published only a checker tool rather than a working exploit. The Hacker News summed up the trap neatly: with no CVE to tag at first and no public signature to match, nobody is really looking yet.

That quiet is not safety. It is a countdown. Rapid7's assessment is worth quoting because it names the mechanism: "Due to WordPress Core being an open-source project and given the current ability of AI models to analyse open-source code, Rapid7 Labs believes it is highly likely that a public PoC will be made available in a short period of time." The patch is public. The vulnerable code is public. Reconstructing the exploit from the difference between the two — patch-diffing — is a well-worn craft, and it is getting faster as models get better at reading code. The window between "fix released" and "working exploit circulating" is the thing you are racing, and I have written before about how brutal that window can be.

Now put that together with who is waiting at the other end. The mass-exploitation crews I described in the WP-ShellStorm write-up built an entire industrial operation — target lists a million lines long, automated scanners, thousands of webshells — on the back of plugin vulnerabilities that needed particular versions of particular add-ons. Hand those same operators an unauthenticated remote code execution in WordPress core itself, and the targeting problem disappears: every affected site is a target, no plugin required. The moment a reliable exploit exists, this scales to the whole internet at once. That is why the honest read of "nobody is exploiting it yet" is "you have a head start, and it is short."

What to actually do

The instruction is blunt and it is the same for a one-page business site as for a large estate.

Patch to 6.9.5 or 7.0.2 now. WordPress has pushed this as a forced update through its auto-update system, which is genuinely good news and will have quietly protected a lot of sites already. But do not assume it reached yours. Plenty of managed hosts, agencies and cautious owners turn auto-updates off for stability, and WordPress has not confirmed the forced push reaches those. Check what you are actually running — the version is in the admin dashboard or via wp core version — rather than trusting that it landed.

Inventory your WordPress, including the sites you have forgotten. The recurring theme of every WordPress mass-compromise is the abandoned microsite: the campaign page, the events site, the old brand someone stood up years ago and never decommissioned. You cannot patch what you do not know you run, and those orphaned installs are exactly what the scanners will find first.

If you genuinely cannot patch this hour, mitigate — as a stopgap, not a fix. Searchlight's interim options are to block both the /wp-json/batch/v1 and rest_route=/batch/v1 paths at a web application firewall, or to restrict anonymous access to the REST API. Note "both" — blocking one path and not the other leaves the door ajar. And note the caveat: each of these can break legitimate integrations that rely on the REST API, so they buy you time, they do not end the problem. Patch as soon as you can.

Watch for the shift from quiet to loud. Right now the priority is to patch before a weapon exists. But keep half an eye out, because the day a PoC drops the picture changes to assume-breach: if you were exposed and unpatched when exploitation begins, patching afterwards closes the door without telling you whether anyone already came through. Know where your webshells would hide — the wp-content/uploads directory and its neighbours — and be ready to hunt, not just update.

And if your organisation's public face runs on WordPress, this is a board-level question this week, not an IT footnote: who owns patching the website, and can they confirm — not assume — that the fix has landed on every one of your sites?

The reassuring half and the unreassuring half

There is a genuinely encouraging story buried in this. The process worked as it is supposed to: a skilled researcher found a serious flaw, disclosed it responsibly through the proper channel, WordPress patched it quickly and force-pushed the fix, and the technical details are being withheld to give defenders a head start. That is the system functioning well.

The unreassuring half is that responsible disclosure buys days, not weeks. The exploit will be reconstructed from the patch — faster now that AI can help read the code — and the people who turned plugin bugs into a 25,000-site backdooring operation are extremely good at moving quickly when the target set expands to "all of WordPress." WordPress core very rarely hands attackers an unauthenticated route to code execution. This week, it did, and then fixed it. Whether that fix protects you depends entirely on one thing: whether your sites — every one of them, including the forgotten ones — are on 6.9.5 or 7.0.2. Go and check. Now, while it is still quiet.