What happened

Quick heads-up: a nasty WordPress core bug — labeled “wp2shell” by the researcher — lets an anonymous HTTP request execute code on a default install. In plain human: someone on the internet can knock on your site and potentially run commands without logging in. This is a pre-auth RCE, and yes, that’s as bad as it sounds.

The vulnerability was discovered by Adam Kues of Assetnote (Searchlight) and reported responsibly via the project’s bug‑bounty channel. WordPress pushed fixes on July 17, 2026 and activated auto-update behavior for those fixes, but don’t assume your site updated itself — check the version running on your server.

Quick breakdown of affected releases and fixes:

  • 6.9.0 through 6.9.4 — fixed in 6.9.5
  • 7.0.0 through 7.0.1 — fixed in 7.0.2

Other notes: 7.1 beta2 contains the same fix. Sites still on 6.8 are not affected by this exact bug, but there was a separate SQL injection fix released for 6.8.x. The problematic code path was introduced in 6.9 (released December 2, 2025), so only relatively recent installs are in scope.

WordPress describes the root cause as a REST API “batch-route confusion” paired with an SQL injection that leads to remote code execution. The update touched three core files related to the REST and query systems. As of July 18 there was no CVE number or CVSS score public, so standard CVE-based scanners may not flag this yet.

What to do right now

If you run WordPress, treat this like a hot potato: update or at least slam the oven mitt on it. If you can update immediately, upgrade to the fixed versions (6.9.5, 7.0.2 or newer).

If you can’t update right away, here are temporary mitigations that reduce risk — they are stopgaps and may break some integrations that rely on unauthenticated REST calls:

  • WAF rule: block both paths targeting the batch endpoint (the JSON path and the query-string route). Blocking only one leaves the other open, so you need rules for both.
  • Disable the REST API for unauthenticated requests. This is blunt force: it stops the attack surface but can disable legitimate headless or API integrations.
  • Install a lightweight drop-in that rejects anonymous calls to the batch endpoint early (for example, at rest_pre_dispatch). This preserves more functionality but still blocks anonymous abuse.

Also do these housekeeping things:

  • Check your WordPress version — don’t assume auto-updates did their job.
  • Scan logs and monitor for unexpected traffic to the batch endpoint; that activity will light up if attackers start scanning.
  • Keep backups handy and ensure your incident response plan is ready — always useful advice, rarely followed until it’s urgent.

No confirmed mass exploitation had been reported by July 18, but remember: once a patch is public, the diffs are too. Open-source fixes are a double-edged sword — they protect users who update quickly and give attackers a roadmap if sites lag behind. So update, or at least block that batch endpoint until you can.

Short version: check your version, update if possible, and if you can’t, block anonymous access to the batch endpoint until you can patch.