The heart of WordPress, run by someone who never logged in: the WP2Shell chain

Why this touches almost everyone

This is not an attack on one niche product: it is a flaw in the core of the platform that runs a huge share of the public web — a large slice of small-business sites, local news outlets, professional practices, e-commerce and smaller institutional portals. When the defect sits in the core rather than a third-party plugin, the exposed surface is not a list of companies: it is "anyone who publishes on WordPress and hasn't updated yet."

On 17 July 2026, two WordPress Core vulnerabilities were disclosed. Serious on their own; chained, they become a skeleton key that opens remote code execution with no login at all. Researchers named the chain WP2Shell.

1. 17 July 2026
   Disclosure

   CVE-2026-60137 and CVE-2026-63030 made public, with patches.

2. Within days
   exploitation: active

   In-the-wild exploitation confirmed by multiple vendors; public PoCs circulating.

3. 21 July 2026
   KEV catalog

   CISA adds CVE-2026-60137 to the Known Exploited Vulnerabilities catalog.

The two flaws, and why together they are worse

The first, CVE-2026-60137, is a SQL injection at the heart of WordPress's query engine, WP_Query, caused by improper sanitization of the author__not_in parameter. On its own, on WordPress 6.8.0 through 6.8.5, it lets an attacker manipulate database queries — reading data that shouldn't be reachable and, in some configurations, altering it.

The second, CVE-2026-63030, is a batch-route confusion in the REST API: a crafted request is interpreted differently from how the access-control logic assumed. It is the kind of defect that looks theoretical on its own; used as leverage on another, it becomes the missing piece.

Lined up, the two turn an unauthorized database read into code execution on a default WordPress install — and they do it without authentication. That is what pushes the chain to top priority: no account, no token, just the ability to reach the site over the network.

1. 01
   Unauthenticated HTTP request

   the attacker reaches the site, no credentials
2. 02
   CVE-2026-60137

   SQL injection in WP_Query via author__not_in
3. 03
   CVE-2026-63030

   REST API batch-route confusion
4. 04
   WP2Shell

   remote code execution on a default install

What is confirmed, and what is not

Confirmed: the CVEs, their presence in the core, the patched versions, and CVE-2026-60137's entry into the CISA KEV catalog on 21 July. Also confirmed: multiple security firms observed active exploitation within days of disclosure, with public proof-of-concept code already circulating — the window between "patch available" and "mass exploitation" was very short.

To be stated as uncertain: there is no single attributed group. The scenario consistent with the data is opportunistic mass exploitation — automated scanners hitting everything that answers, typical once a PoC for a ubiquitous platform goes public — not a campaign aimed at one target. Exact figures on compromised sites, at this stage, are not verifiable: treat them as estimates, not counts.

What to do, now

The patches exist: WordPress 6.8.6, 6.9.5 and 7.0.2. Given the severity, WordPress did something it rarely does — force-push the automatic update to all supported installs. That covers most sites transparently, but not all: anyone who disabled auto-updates, runs a fork or an out-of-support version, or sits on a "frozen" install where the host doesn't apply core updates, stays exposed.

The action is single and cannot wait: check your WordPress version and, if it is not among the patched ones, update immediately. Then confirm the auto-update actually went through — don't assume it — and, on sites that may have been reached before the patch, look for signs of compromise: unrecognized admin users, unexpected files under the web root, anomalous REST API activity in the logs. With a pre-auth chain already exploited and public PoCs, the question is not whether someone will try, but whether they already have.