Threat Summary

On July 17, 2026, WordPress shipped emergency releases 6.9.5 and 7.0.2 to close a pre-authentication remote code execution chain in core — meaning no plugin is required, and the flaw exists in every affected WordPress site by default. Researchers at Searchlight Cyber's Assetnote team, who reported it through WordPress's HackerOne program, named the chain wp2shell.

The chain combines a REST API batch-route confusion bug with a SQL injection issue in core. Together, they let an anonymous, unauthenticated HTTP request manipulate a database query and ultimately execute arbitrary code on the server — no login, no plugin, and no unusual configuration required.

Who Is Affected?

Any WordPress site running a default install with a persistent object cache not in use (the default for most sites) is potentially exposed:

  • WordPress 6.9.0 through 6.9.4 — fixed in 6.9.5
  • WordPress 7.0.0 through 7.0.1 — fixed in 7.0.2
  • WordPress 7.1 beta2 — patched in the same release
  • WordPress 6.8.x — a separate fix (6.8.6) addresses the SQL injection component
  • Versions prior to 6.8 are not affected — the vulnerable code was introduced in 6.9, which shipped December 2, 2025

For CyberGuard's audience specifically: if you or a client runs a self-hosted WordPress site — which covers a large share of African SME websites — this is worth checking today, not next week.

Technical Description

The vulnerability touches three core files: wp-includes/rest-api/class-wp-rest-server.php, wp-includes/class-wp-query.php, and wp-includes/rest-api.php. WordPress's REST API batch endpoint — public since WordPress 5.6 in November 2020 — allows an anonymous request to be misrouted in a way that triggers a SQL injection in core query handling. Chained together, this gives an attacker a path from an anonymous HTTP request straight to code execution on the server.

Because both the vulnerable code and the patch are open source, the exact mechanism is reconstructable by anyone willing to diff the release. WordPress responded by enabling forced automatic updates for this release given the severity — but that only applies where auto-updates were left on. Check the version your site is actually running rather than assume the forced push reached it.

Indicators of Compromise (IOCs)

No confirmed public IOCs (hashes, IPs, or malware signatures) had been released as of this writing, and no mass exploitation had been publicly reported as of July 18, 2026. In the absence of confirmed IOCs, monitor your web server access logs for anonymous requests to the batch REST endpoint:

POST /wp-json/batch/v1/*
GET|POST /?rest_route=/batch/v1/*

Unexpected or high-volume anonymous traffic to either path is worth investigating immediately.

Attack Techniques (MITRE ATT&CK)

  • T1190 — Exploit Public-Facing Application (initial access via the REST API endpoint)
  • T1059 — Command and Scripting Interpreter (post-exploitation code execution)

Business Impact

A successful exploit hands an attacker full control of the web server — not just the WordPress site. For an SME, that typically means: complete site defacement or takedown, theft of customer data (including payment details if an e-commerce plugin is in use), installation of persistent backdoors or malware for future access, and the site being used to attack visitors or other infrastructure. Recovery from a full server compromise is materially more expensive and disruptive than patching would have been.

Recommended Mitigations

Primary fix: update to WordPress 6.9.5, 7.0.2, or 6.8.6 (matching your current version) immediately. Don't assume the forced auto-update already applied — verify your running version directly.

If you cannot update immediately, Searchlight Cyber's own guidance is that every stopgap comes down to keeping anonymous requests off the batch endpoint:

  • At your firewall/WAF, block both /wp-json/batch/v1 and ?rest_route=/batch/v1 — both paths must be blocked, not just one
  • Disable the WP REST API entirely if you don't rely on it for integrations
  • Use a drop-in plugin that rejects anonymous requests to the batch endpoint

These are stopgaps, not substitutes for patching. Cloudflare deployed WAF rules for this at the edge on July 17, and even they describe it as reducing exposure while you update — not a replacement for the update itself.

Official Sources