Critical wp2shell WordPress flaws exploited to install webshells

# WordPress's REST API Just Became a Master Key — And Attackers Found It in 13 Minutes

The first probe hit at 23:29 UTC on July 17. Thirteen minutes later, attackers were already attempting SQL injection. That's the timeline for wp2shell — a pair of critical vulnerabilities in WordPress Core (CVE-2026-63030 and CVE-2026-60137) that have turned the platform's own REST API into an unauthenticated remote code execution engine.

As of today, nearly one in five WordPress sites in a live sample remains unpatched. WordPress powers somewhere north of 43% of the internet. Do that math.

## The Attack Chain Is Elegant and Ugly

The wp2shell exploit abuses the WordPress REST API's batch-processing feature — a convenience mechanism that lets multiple API requests be bundled into a single call. Attackers found that this batching layer could be weaponized to achieve remote code execution without credentials. No login required. No brute force. Just a well-formed request aimed at a feature that was never designed to be a security boundary.

What Wiz observed in the wild is a textbook persistence playbook, executed at scale:

SANS researcher Johannes Ullrich dissected a particularly crafty variation: webshells planted in /wp-content/cache/ under randomized filenames, with that same random string serving as the password via a URL parameter. Direct access without the magic string returns a convincing fake 404. Security teams skimming access logs won't see anything scream "backdoor" — they'll see what looks like a broken cache file request.

The shell itself was written defensively: it probed for whichever PHP execution function the server permitted — system(), passthru(), exec(), shell_exec(), popen(), or the backtick operator — cycling through options until something worked. Whoever wrote this understood that hardened PHP configurations disable some of these, and they planned for it.

## The Patch Window That Wasn't

WordPress pushed fixes in versions 7.0.2, 6.9.5, and 6.8.6, with automatic security updates enabled for supported installs. That should have been a clean win. WordPress's auto-update mechanism exists precisely for moments like this.

Except Macnica researcher Yutaka Sejiyama is tracking the patch rate live, and the current figure across 124,580 evaluated sites sits at 81.6%. Nearly 19% haven't received the fix — whether due to disabled auto-updates, managed hosting that queues updates on a delay, or sites that simply haven't been touched in months.

On a platform that runs tens of millions of active sites, 18% isn't a rounding error. It's an ocean of persistent attack surface, and threat actors are actively scanning it.

Defiant's timeline makes the urgency concrete: the first exploitation-relevant probe arrived within hours of public disclosure. PoC code began circulating over the weekend after SearchLight Cyber's disclosure. Security disclosures and weaponizable proof-of-concept code now move in near-lockstep — the era of a 30-day exploitation grace period is long gone.

## What Defenders Need to Check Right Now

If you're running WordPress — or managing WordPress infrastructure for clients — the update to 7.0.2, 6.9.5, or 6.8.6 is not optional. Do it before reading further.

Beyond patching, the post-exploitation indicators to hunt:

Filesystem:

Users:

Logs:

Wiz reports no observed lateral movement or data exfiltration yet, but "yet" is doing real work in that sentence. Webshells are staging infrastructure. They sit dormant until someone decides to use them.

---

## HackWire Analysis

The detail that's getting underplayed in other coverage: SearchLight Cyber researcher Adam Kues disclosed that developing the wp2shell exploit chain involved AI tooling. That's not a throwaway line.

We're watching the commoditization of vulnerability research play out in real time. The traditional gap between "security researcher finds complex bug" and "criminal group weaponizes it" used to be measured in weeks or months, partly because exploit development required deep technical skill. AI-assisted analysis is compressing that timeline — and the wp2shell case suggests we're reaching a point where the PoC-to-exploitation interval is measured in hours, not days.

This also fits a pattern that should concern anyone running PHP-based CMS infrastructure. WordPress's REST API has been an exploitation vector before — the 2017 REST API content injection vulnerability (CVE-2017-1001000) followed a similar arc: REST endpoint, unauthenticated access, mass exploitation. The platform keeps expanding its REST API surface area because developers want the flexibility, and attackers keep finding ways to abuse the trust model that flexibility requires.

The 81.6% patch rate also deserves scrutiny as a systemic number, not a success metric. In absolute terms, even being conservative about total WordPress deployments, we're talking about hundreds of thousands of installations sitting exposed right now with a fully weaponized exploit chain in circulation. The auto-update mechanism is doing its job — the problem is the installs where it's been disabled, often by agencies or developers who want control over update timing. That tradeoff has a cost, and wp2shell is what paying it looks like.

For defenders managing WordPress estates at scale: this is the case for centralized update monitoring. Not a nice-to-have. If you can't confirm patch status across your WordPress inventory within 24 hours of a critical disclosure, your vulnerability management program has a gap that attackers will find before you do.

— HackWire Editorial

---

## Related Coverage