wp2shell: WordPress Handed Attackers The Keys, Then Forced You To Change The Locks

On 17 July 2026, Searchlight Cyber's Assetnote team disclosed a pre-authentication remote code execution vulnerability in WordPress Core and gave it a name — wp2shell. Not a plugin. Not a theme. Not some abandoned page-builder shipped by a company that hasn't pushed a commit since 2021. The core. The bit the entire ecosystem sits on. The bit the marketing site tells you is 'battle-tested' and 'powering 43% of the web,' as if ubiquity were a security feature.

It is not one bug. It is two, chained together, which is the modern shape of catastrophe. On its own, each is 'bounded.' Together, they hand an anonymous attacker a shell on your server. This is the platform. This is what half the internet is running on tonight.

What actually happened

The chain is textbook horror. CVE-2026-60137 is a SQL injection in the author__not_in parameter of WP_Query — the class that runs basically every database query WordPress makes. It reaches back to WordPress 6.8. CVE-2026-63030 is a route confusion issue in the REST API batch endpoint at /wp-json/batch/v1, an endpoint that has shipped by default since WordPress 5.6 in 2020. Six years of exposure. Enabled for you, at the factory, with love.

Bolt those two together and an unauthenticated attacker — no login, no plugin fingerprint, no misconfiguration to chase — pokes the front door of a stock WordPress install and walks out with code execution. That is not a bug. That is a design outcome.

“No preconditions. No plugin. No misconfiguration. A stock install answers the request.”

How bad is it, on a scale of 'change your career'?

WordPress runs, by common estimate, around 500 million sites. The vulnerable path is a default endpoint. Not a niche feature. Not something you opted into by installing a plugin from a Ukrainian developer whose GitHub is now a 404. The default. Which means the exposed population is, in technical terms, everyone.

The tell that this is genuinely bad is not the CVSS score. It is that the WordPress maintainers forced the update. WordPress does not normally override an administrator who has disabled auto-updates. That is a sacred boundary, right up until it isn't. Here, they reached into your server and patched it for you. Read that sentence again. The people who ship WordPress decided the risk of leaving your decision alone was worse than the risk of overriding it. That is not routine housekeeping. That is a fire alarm.

The 'no public exploit' comfort blanket

As of writing, there is no public proof of concept. The researchers are holding back technical detail to give defenders a head start. This is the bit where the WordPress community exhales, tweets 'patch and move on,' and goes back to arguing about block themes.

Do not exhale. WordPress Core is open source. The fixed and unfixed releases both sit in public archives. Diffing two versions of an open-source project is a well-established path to reconstructing a bug — it is a Tuesday afternoon for anyone who has done this before, and 'anyone who has done this before' is a busy criminal industry with a mature supply chain of scanners, botnets, and Telegram channels.

Your head start is measured in days. Not weeks. Whatever calm you feel today evaporates the moment a working PoC lands on GitHub, at which point mass scanning starts within hours. This is not a hypothesis. This is the entire history of WordPress zero-days played back on a loop.

What you have to do, and what the platform makes hard

The advice is simple to write and painful to execute across an estate:

• →Update to 7.0.2, or 6.9.5 if you are on the 6.9 branch. Sites on 6.8 should move to 6.8.6, which addresses the separate SQLi in that branch. The 7.1 beta line also carries the fix.
• →Verify. Do not assume. Forced auto-updates help — until they silently fail on the site with the weird custom must-use plugin nobody remembers writing. Log into each internet-facing instance and confirm the version.
• →If you cannot patch immediately, block both /wp-json/batch/v1 and ?rest_route=/batch/v1 at a WAF. Both routes. A rule that only covers the path leaves the query-string route wide open — and yes, of course WordPress has two ways to hit the same endpoint, why wouldn't it.
• →If compromise is plausible, patching is not enough. It closes the route. It does not evict the attacker who was in your building yesterday. Preserve logs, review recently modified core files, themes, plugins, must-use plugins, scheduled tasks, and unexpected files in writable directories. Compare admin accounts against a known-good list. When in doubt, restore from a verified clean backup and rotate every credential the site touches.

That five-step list assumes you know where all your WordPress sites are. You don't. Nobody does. There is the client site you built in 2019, the staging box that was 'temporary,' the microsite marketing spun up for a campaign that ran for six weeks in 2022, and the multisite the intern set up before the intern became a project manager and stopped answering emails. Every one of those is currently a stock WordPress install with a batch endpoint enabled by default.

The pattern under the panic

wp2shell is not a novel category. It is this month's example of a familiar one. A critical flaw lands in software that runs everywhere. A patch ships the same day. A short, quiet window opens before exploitation begins. Then the internet catches fire, briefly, before moving on to the next thing.

What makes WordPress special is that this pattern is the platform's operating cadence, not an exception to it. The base install is enormous and old. The default surface area is huge — REST endpoints, XML-RPC vestiges, comment systems, media handlers, the wp-cron nightmare, an admin UI reachable from the public internet. The extension model is a museum of unpaid, unmaintained volunteer code with occasional bursts of private-equity acquisition. Every layer adds attack surface, and the culture treats 'just install a security plugin' as a mature response to that.

And so, twice a year, without fail, a headline like this one arrives. Different CVE. Same shape. Same panicked Slack channels. Same LinkedIn thought leaders explaining that this proves you need their managed WordPress hosting product, which is running the same core code with a slightly different auto-update policy.

The pivot memo, again

If you run one WordPress site for yourself, patch it and get on with your day. If you run WordPress as a business — client sites, an agency book, a hosting product, a maintenance retainer — this disclosure is another data point in a chart that has been pointing the same direction for years.

The base rate of critical, pre-auth, unauthenticated RCE in WordPress Core is not zero, and it is not decreasing. The base rate of critical vulnerabilities in the plugin ecosystem is a comedy. The base rate of your clients understanding the difference between 'I bought a WordPress site' and 'I bought a permanent commitment to a security operations centre' is also zero.

You are the security operations centre. You did not budget for it. You did not price for it. You certainly did not price this weekend into the retainer. Every wp2shell-shaped event is an unbilled fire drill, and the drills are getting closer together.

The bit the vendors will not say out loud

The 'ecosystem' response to wp2shell will be predictable. Wordfence will publish a firewall rule and a blog post. Managed hosts will send a reassuring email with the word 'proactive' in it. Elementor will not mention it. WP Engine will mention it exactly enough to imply you should have been on their plan. Automattic will thank the researchers, ship the patch, and move on.

Nobody in that supply chain is going to say the honest thing, which is: the default configuration of the platform you are running exposed an unauthenticated code-execution endpoint to the internet for approximately six years, and the fix is a version bump you have to chase across every install you have ever touched. In any other stack this would be a career-defining incident. Here it is a Thursday.

What to do this week

• →Today: patch every WordPress instance you own or manage. Verify the version. Screenshot it. Send the screenshot to whoever pays you.
• →This week: audit your estate. If you cannot list every WordPress site your business is responsible for, that is the real vulnerability. Fix it before the next disclosure.
• →This month: have the honest conversation with any client whose site is business-critical. Either they pay for real monitoring and rapid response, or they accept the risk in writing, or you stop being the person holding the pager.
• →This quarter: decide whether WordPress is still the right substrate for new builds. Not out of ideology. Out of arithmetic. Add up the unbilled hours you have spent on the last five 'critical patch now' events. Compare it to what you charged.

Closing autopsy

wp2shell will be patched and half-forgotten in three weeks. The name will fade. The CVE numbers will vanish into a spreadsheet. The pattern will not. A critical flaw in ubiquitous software with a short window before mass exploitation is the default weather now, and WordPress is the platform that ships the most of it.

The maintainers did their job. They shipped a fix and forced it into your install. The researchers did theirs. They found the chain, disclosed it responsibly, and gave you a head start. The only question left is whether you are going to do yours — patch every instance, verify every version, hunt for the ones you forgot, and then, quietly, start planning for the day you stop having to do this twice a year.

Because the day after that is the day you get your weekends back.