Wp2shell Attack

On Friday 17 July 2026 the WordPress core team shipped an emergency security release, and then did something it very rarely does: it forced that update onto sites with automatic updates enabled. The reason was a vulnerability chain nicknamed wp2shell, which lets a complete stranger with no account, no password and no vulnerable plugin take full control of a stock WordPress installation.

Within five days the technical details and working exploit code were public, both underlying bugs were on the United States CISA Known Exploited Vulnerabilities catalogue, and attackers were dropping persistent webshells on sites that had not updated. If you run a WordPress site and you have not confirmed its version since July, this is worth ten minutes of your time.

What wp2shell Actually Is

wp2shell is not a single bug. It is two flaws in WordPress core that become far more dangerous when chained together:

CVE-2026-63030 - a logic flaw in the REST API batch processor at /wp-json/batch/v1. Rapid7 describes it as a desynchronisation between the validation array and the dispatch array, meaning the request that passes the permission check is not necessarily the request that gets executed.
CVE-2026-60137 - a SQL injection in the posts endpoint, where the author parameter is interpolated directly into raw SQL when it is supplied as a scalar string instead of an array.
Individually, each flaw is serious. Chained, they hand an unauthenticated attacker enough control to create an administrator account and install a plugin of their choosing — which in practice means a webshell. That is complete site takeover, and depending on how your hosting is configured, potentially a foothold into every other site sharing the account.

Searchlight Cyber, the firm that discovered the chain, stressed the detail that should concern every site owner: the attack has no preconditions. A stock WordPress install with no plugins at all is exploitable by an anonymous visitor.

Which Versions Are Affected

• WordPress 6.9.0 through 6.9.4 — vulnerable
• WordPress 7.0.0 through 7.0.1 — vulnerable
• WordPress earlier than 6.9 — not affected
• Fixed in 6.9.5 and 7.0.2, both released on 17 July 2026

You can check your version under Dashboard, Updates, or in the bottom right of any admin screen. If you are anywhere in the affected range, stop reading and update now.

The Timeline That Matters

• 17 July 2026 - WordPress 6.9.5 and 7.0.2 released, security advisory published, forced auto-updates enabled for affected sites.
• 21 July 2026 - CISA adds both CVEs to its Known Exploited Vulnerabilities catalogue, confirming active exploitation in the wild.
• 22 July 2026 - full technical analysis and public proof-of-concept exploit code released.
  Five days from patch availability to weaponised public exploit. That is the realistic window a business now has to respond to a critical vulnerability in internet-facing software, and it is precisely why Microsoft has started telling its own customers to patch within three days.

Patching Is Not the Same as Recovering

This is the part that gets missed. If your site was reachable from the internet and running an affected version at any point after 17 July, updating closes the door - but it does not evict anyone who already walked through it. A webshell or a rogue administrator account planted before the patch survives the update quite happily.

If you were exposed, check for the following:

• Unexpected administrator accounts. Review Users - All Users, and confirm against the wp_users table directly - a capable attacker can hide an account from the dashboard.
• Plugins you did not install, or legitimate plugins whose files have been modified recently.
  PHP files in places they do not belong, particularly anything executable beneath wp-content/uploads.
  Unfamiliar scheduled tasks in WP-Cron.
• Web server logs. Look for POST requests to /wp-json/batch/v1 and unusual traffic to the posts endpoint from mid-July onwards.
• If you find anything, treat it as a full compromise. Restore from a known-good backup taken before 17 July, rotate the salts and keys in wp-config.php, force a password reset for every user, and change the database credentials and any API keys the site holds.

If You Genuinely Cannot Patch Yet

Blocking /wp-json/batch/v1 at your web application firewall or web server, and restricting anonymous REST API access, will frustrate the published exploit path. Treat both as a stopgap for the hours it takes to schedule the update, not as a substitute for it. Public exploit code evolves quickly and endpoint-specific blocks age badly.

The Broader Point

wp2shell was not found by an attacker. It was found by researchers, responsibly disclosed, and patched before exploitation began - the system worked. What has changed is the speed of the second half of that cycle. The gap between a patch shipping and reliable exploit code circulating is now measured in days, and increasingly that gap is closed with the help of automated analysis.

For most Australian small and medium businesses the practical answer is unglamorous: know what software you run, keep automatic updates switched on for anything facing the internet, and make sure somebody is responsible for noticing when an emergency release lands on a Friday afternoon.

References

1. WordPress.org, Version 6.9.5 - release documentation, 17 July 2026.
2. Rapid7, CVE-2026-63030: wp2shell, a Critical Remote Code Execution Vulnerability in WordPress Core.
3. SecurityWeek, wp2shell WordPress Vulnerabilities Exploited in the Wild.
   Wiz, Exploitation in the Wild of wp2shell.
4. The Hacker News, New wp2shell WordPress Core Flaw Lets Unauthenticated Attackers Run Code.
   Bitdefender, Technical Advisory: wp2shell — Unauthenticated Remote Code Execution and Full Site Takeover in WordPress Core.
5. Elastic Security Labs, wp2shell: detecting WordPress pre-auth RCE end-to-end.
6. Canadian Centre for Cyber Security, WordPress security advisory AV26-723.
7. CISA, Known Exploited Vulnerabilities Catalog.