wp2shell: check your WordPress site today, patched or not
If your website, or a client's, runs on WordPress, this affects you whether you use plugins or not. Two vulnerabilities in WordPress core itself, tracked as CVE-2026-63030 and CVE-2026-60137 and codenamed wp2shell, chain together into unauthenticated remote code execution on a stock install with no plugins at all. Attackers are already scanning the internet for it at scale.
What changed
Security researchers at Searchlight Cyber found the flaw and disclosed it responsibly, withholding technical detail because of the severity. That did not slow attackers down for long. Once a public proof of concept appeared, watchTowr reported successful exploitation was "already well underway" within hours, and its own honeypots have since logged tens of thousands of exploitation attempts.
The first bug, CVE-2026-63030, is a route confusion issue in the WordPress REST API's batch endpoint that lets an attacker skip the normal permission check entirely. The second, CVE-2026-60137, is an SQL injection flaw present in WordPress core from version 6.8 onwards. Chained together, they let an anonymous attacker run code on the server with a single HTTP request, on any WordPress version released since December 2025.
Data from Google's Wiz found that 60% of organisations running WordPress had at least one vulnerable instance when the CVEs were published, and a quarter of those had it exposed directly to the internet. Once attackers are in, Wiz has observed them uploading a fake security plugin (disguised as one called CMSmap) that acts as a full attack platform: file management, database access, port scanning, and privilege escalation. Over a hundred backdoor administrator accounts have already been created this way.
What to do if WordPress runs your site
WordPress has supported automatic background security updates for years, and many hosts pushed protective rules ahead of the public disclosure. If your updates are switched on and your host was on the ball, you may already be covered. Confirm rather than assume:
- Is your WordPress core version 6.9 or later, or has the specific patch for CVE-2026-63030 and CVE-2026-60137 been applied?
- Are automatic background updates for security releases switched on?
- Has your host or agency confirmed they applied a web application firewall rule for this while you waited on the patch?
Whatever the answer, check for signs you were already touched before the fix went on. Attackers who got in ahead of your patch are still in unless you find them:
- Look for administrator accounts you do not recognise, especially ones created recently.
- Check your installed plugins for anything you did not add, particularly one that looks like a security or monitoring tool with a name you don't recognise.
- If your host runs object caching, be aware the RCE path specifically needs persistent object cache disabled to work; ask whether that setting was on during the exposure window.
Patching alone is not enough if you were already compromised. The advice from the researchers tracking this is blunt: check for indicators of compromise regardless of when you patched.
What to do if you manage sites for clients
If you are the technical person for a WordPress site, an agency, or several client sites, this is worth a proactive check-in even for sites nobody has flagged as a problem. A single message to each client asking "can you confirm your WordPress core is up to date" costs you five minutes and closes the most likely gap in your own liability if something surfaces later.
How Steelwise can help
Working out whether your WordPress site was patched in time, and checking it for signs of compromise if it wasn't, is exactly the kind of review we do for clients. Get in touch.