wp2shell: WordPress force-updates the web over a pre-auth RCE in core

On July 17, WordPress shipped versions 6.9.5 and 7.0.2 and did something it reserves for genuine emergencies: it enabled forced automatic updates for the fix. The reason is a vulnerability chain the researchers call wp2shell — a pre-authentication remote code execution in WordPress core. Not a plugin, not a theme: a default install with zero plugins is exploitable by an anonymous HTTP request.

How the chain works

wp2shell is two bugs that are individually awkward and jointly severe. The first (CVE-2026-63030) is a route-confusion flaw in the REST API's batch endpoint, /wp-json/batch/v1, which lets an unauthenticated request reach query paths that were assumed to be privileged. The second (CVE-2026-60137) is a SQL injection in the author__not_in parameter handling of WP_Query. Chained, the batch endpoint delivers the injection, and the injection escalates to code execution on the server. Affected versions run from 6.9.0 through 6.9.4 and 7.0.0 through 7.0.1.

As of the initial disclosure there was no public proof-of-concept and no confirmed in-the-wild exploitation — but the technical details are now public, and for a target surface measured in hundreds of millions of sites, the interval between "details public" and "mass exploitation" is historically measured in days. If you run WordPress anywhere — including the forgotten marketing microsite from 2023 — verify it's on 6.9.5/7.0.2 today, and don't assume auto-update reached it: hosts with disabled auto-updates, version-pinned containers, and heavily customized installs are exactly where forced updates fail silently.

Why "in core, pre-auth" changes the math

The WordPress ecosystem's usual security story is "core is solid, plugins are the risk". That heuristic shapes real decisions — teams audit plugins and treat core as furniture. A pre-auth core RCE inverts it: every install is in scope regardless of hygiene, and attackers can scan for it generically instead of fingerprinting plugin combinations. The last flaws of this class in core are years in the past, which is precisely why patch urgency is high — muscle memory says WordPress core can wait. This one can't.

Meanwhile, at the perimeter: the SonicWall story escalated

The SMA1000 zero-days we covered this week found their operator: researchers now report the INC Ransom operation exploiting the two SonicWall flaws in tandem, gaining root on the mobile-access appliances that sit in front of corporate networks. That completes a familiar arc — zero-day, credential harvest, then ransomware crews industrializing the access. If you patched but didn't rotate the credentials and MFA seeds those boxes held, the patch closed the door after the keys left.

And the week's leak-site churn continued across regions — claims posted against a Dutch food supplier, a Hungarian building-materials maker, a UK microfinance firm and a Japanese industrial manufacturer, by groups including Play, Gunra and INC. Individually small stories; collectively the base rate that never makes headlines.

The takeaway

Two deadlines this weekend, then. Patch WordPress before the exploit writes itself — forced updates are on, but verify, don't trust. And if you own a SonicWall SMA appliance, treat it as post-compromise: patch, then rotate everything it stored, because ransomware operators demonstrably already have the playbook. Both stories reduce to the same rule that keeps recurring this month: the fix isn't finished when the software is current — it's finished when the secrets the attacker could have taken stop working.

A note on sourcing: details above come from the WordPress security release, the researchers' published analysis, and incident reporting from established security press; the INC Ransom attribution reflects current public reporting and may be refined as investigations continue.