WordPress shipped an emergency fix for wp2shell on July 17, 2026. It is a pre-authentication remote code execution (RCE) flaw in WordPress core. No plugins, no login, and no special setup are required to attack a vulnerable site. WordPress force-pushed the patch, but “the update pushed itself” is not the same as “you’re safe.”
We’ll show you how to check your actual WordPress version, confirm whether your site was exposed, and look for signs of compromise in this guide. We’ll also explain how to protect your website in just 20 minutes, so stick by.
What this wp2shell (CVE-2026-63030) is all about?
There are two bugs, and they only became dangerous when chained together:
- CVE-2026-63030: REST API “batch route” confusion flaw in /wp-json/batch/v1. This is the piece that lets an anonymous request slip past WordPress’s normal checks.
- CVE-2026-60137: SQL injection in the author_not_in parameter of WP_Query, the class behind nearly every database query WordPress runs.
Chained, an anonymous HTTP request can run code on your server the worst outcome a web app can hand an attacker. Because the flaw lives in core, a clean install with zero plugins is exploitable.
So WordPress enabled forced automatic updates for security that covered a lot of sites automatically. But it did not cover every site, and it does nothing for a site that was at risk before the patch landed. That gap is the whole point of this post.
Am I affected?
The two bugs reach different versions, which is why there are three separate patched releases. Find your version in the table below:
| Your WordPress Version | What You’re Exposed To | Update To |
| 6.8.0–6.8.5 | SQL injection only (not the full RCE chain) | 6.8.6 |
| 6.9.0–6.9.4 | Full pre-auth RCE chain | 6.9.5 |
| 7.0.0–7.0.1 | Full pre-auth RCE chain | 7.0.2 |
| 6.9.5 / 7.0.2 / 6.8.6 or later | Patched | On the fixed line, still verify and check for compromise |
A few things worth knowing:
- The RCE chain only exists from 6.9 onward (6.9 shipped in December 2025). So every site exposed and code execution is running a release less than eight months old.
- Sites on 6.8.x are not exploitable for RCE through this chain, but they still need 6.8.6 for the standalone SQL injection.
- The code execution path only works when the site is not running a persistent object cache (Redis or Memcached). A default install has no such cache, so default install exposure stands. If you happen to run one, then you may be off the RCE path. Treat that as luck, not a fix, and note it does nothing for the SQL injection.
Didn’t WordPress Auto-Update Me? Why Do I Need To Do Anything?
Yes, WordPress does auto-update, but it’s not as simple as it seems. Here are the three reasons why you need to handle it:
- Forced Updates That Reach Most Sites But Not All: WordPress has not confirmed that the forced push reaches installs where auto updates were turned off. So it doesn’t help sites on custom or Git based deployment pipelines, locked-down managed environments, or long-forgotten subdomains and staging copies.
- Patch Does Not Confirm Safety: If your site was on a vulnerable version and reachable from the internet during the window before the patch applied. Then a core update does not remove a backdoor, a rogue admin account, or an injected redirect that was planted first. Patching and compromise hunting are two separate jobs.
- Don’t Get Anchored On A Single Severity Number: Public scoring for these CVEs has been inconsistent. WordPress rates the RCE chain as Critical, while some databases have shown a lower rating of 7.5 (High) for CVE-2026-63030 and 9.1+/Critical for the SQL injection. So it’s not about which number is “right”; it’s that a single score shouldn’t drive your response. Treat this as critical and move.
How to Detect Your Exposure to wp2shell
Here are a few steps to help you detect if you are exposed or affected:
1. Two-Minute Version Check
- Log into wp-admin, open Dashboard, and then go to Updates. Read the installed version at the top.
- If it shows 6.9.0–6.9.4 or 7.0.0–7.0.1 (or 6.8.0–6.8.5), then you are not yet patched.
- Repeat for every site from your own to every client project. Because a successful update on one site tells you nothing about the others.
You can also use the public checker at wp2shell.com to test whether an instance is vulnerable.
2. Command line
If you have SSH + WP-CLI, then check the real version from the WordPress root:
wp core version
Confirm the result is 6.9.5, 7.0.2, 6.8.6, or later. To sweep many sites at once, loop it across your install paths (adjust to your directory layout):
for dir in /var/www/*/public_html; do
printf “%s: ” “$dir”
wp –path=”$dir” core version 2>/dev/null || echo “not a WP install / cannot read”
done
3. Look For Attack Attempts and Compromise
The earliest signals of attempts are requests to the batch endpoint and malformed author parameters. Grep your web server access logs (adjust paths):
# Requests hitting the batch endpoint (both route styles)
grep -E “batch/v1|rest_route=/batch/v1” /var/log/nginx/access.log
# Suspicious author__not_in values (a string where an array is expected)
grep -E “author__not_in” /var/log/nginx/access.log
Then look for signs of a successful compromise. These are the normal consequences of RCE, so treat any of them as a reason to investigate hard:
- New or unfamiliar administrator accounts
- Modified core, theme, or plugin files, or unknown .php files in wp-content/uploads
- Injected redirects, spam pages, or altered content
- Unexpected scheduled tasks (wp cron event list) or outbound connections
- Stolen configuration secrets (anything in wp-config.php)
A public proof-of-concept already demonstrates reading the database, including admin password hashes. So if you were exposed, assume credentials may be known and rotate them.
How to FIX your wp2shell Compromised WordPress Site
Here are ways to fix it if you are exposed to wp2shell:
1. Update
- Dashboard: Dashboard → Updates → Update Now, or use one-click update at your host.
- WP-CLI: wp core update && wp core version and confirm you land on 6.9.5 / 7.0.2 / 6.8.6+.
- Managed hosting: Confirm with your host that the fixed version is live
Update every instance and then re-run your version check to prove it.
2. Stopgaps Only In Case of Rush
These buy time and can break legitimate integrations. They are not a substitute for patching as soon as you can, then remove them.
- At your WAF, block both /wp-json/batch/v1 and rest_route=/batch/v1. You must block both; a rule covering only the /wp-json path leaves the query-string route wide open.
- Disable the REST API with a maintained plugin (this kills unauthenticated REST access wholesale, so expect some breakage).
- Use drop-in mitigation: a small must-use plugin that rejects anonymous calls to the batch route. Save this as wp-content/mu-plugins/wp2shell-stopgap.php:
<?php
/
Plugin Name: wp2shell Stopgap – Block Anonymous Batch Requests
Description: TEMPORARY mitigation for wp2shell (CVE-2026-63030 / CVE-2026-60137).
Rejects unauthenticated calls to the REST API batch endpoint.
This is a stopgap ONLY. Update to 6.9.5 / 7.0.2 (or 6.8.6) and delete this file.
/
add_filter( ‘rest_pre_dispatch’, function ( $result, $server, $request ) {
$route = $request->get_route();
if ( preg_match( ‘#^/batch/v1#’, $route ) && ! is_user_logged_in() ) {
return new WP_Error(
‘rest_forbidden’,
‘Batch requests are temporarily restricted to authenticated users.’,
array( ‘status’ => 403 )
);
}
return $result;
}, 10, 3 );
If you’re behind Cloudflare or running Wordfence, their managed WAF rules for this chain went live on July 17. Useful as a layer, still not a replacement for updating.
3. Things to Do after Compromise
If a site was on a vulnerable version and internet-facing before it was patched, assume it may have been reached and work it as an incident:
- Isolate the site (maintenance mode or take it offline).
- Restore from a known-clean backup taken before the exposure window, if you have one.
- Rotate every secret: database password, hosting/panel logins, all admin passwords, and any API keys stored in the site.
- Regenerate your WordPress salts/keys in wp-config.php and force log out all sessions.
- Then patch before the site goes back online.
- If you can’t confidently confirm the site is clean, bring in professional incident response.
How can you Restore you WordPress Site after an attack?
Here are the tips and tricks that may help you to restore your site if your site is at risk:
- Remove the existing Index.php file & create a new Index.php file
- Delete all recently created files in File Manager
- Check a few files if they’re recently edited, such as:
.htaccess
wp-config.php
Rogue admin accounts in WordPress
- Change all website passwords.
- Change WP website passwords from hosting.
- Change Hosting & Domain website passwords
- Restore last updated WP backup
Check suspicious files on your hosting website
- Access your Bluehost dashboard
- Navigate to the security section and look for SiteLock or any available malware scanning tool.
- Initiate a full site scan to detect any malware or suspicious files.
- Review the scan results carefully.
Follow the recommended steps to remove any detected malware. If you don’t have SiteLock, consider installing a WordPress security plugin like MalCare or Wordfence to scan your site. Keep your plugins, themes, and WordPress core updated to prevent future infections.
Conclusion
wp2shell is a good reminder that the sites that came through this best weren’t the ones that patched fastest, and they were the ones with layers that bought them time and reduced blast radius while they patched.
A persistent object cache accidentally took some sites off the RCE path. A WAF in front of WordPress blocked the chain for others. Neither is the fix, but both are the difference between “we have a rough weekend” and “we experience a breach.”
If you’re running more than a couple of WordPress sites or you’re not sure whether every instance you own is at risk and clean, then we can help. IT Butler e Services gets you onto a fixed, hardened,d and monitored setup so the next core flaw is a non-event.
FAQ
1. Is wp2shell being actively exploited?
As of July 2026, a public proof-of-concept exists, and security firms have reported early exploitation attempts. But it had not yet appeared on CISA’s Known Exploited Vulnerabilities catalog. Given the unauthenticated attack path and how quickly WordPress flaws are weaponized, treat mass scanning as imminent and patch now.
2. I have no plugins installed. Am I safe?
No. The flaw is in WordPress core, so a stock install with zero plugins is exploitable if it’s on an affected version.
3. Do I need to do anything if I’m on 6.8?
Yes, you’re not exposed to the RCE chain, but you should still update to 6.8.6 for the standalone SQL injection.
4. Does having Redis/Memcached protect me?
It may take you off the specific RCE path, but that’s a side effect, not a fix, and it does nothing for the SQL injection. Update anyway.
5. How do I confirm the auto-update actually applied?
Don’t trust the toggle but check the real version in Dashboard and Updates. Or run wp core version. Confirm it reports 6.9.5 / 7.0.2 / 6.8.6 or later.
6. Is a WAF rule enough on its own?
No. WAF rules (Cloudflare, Wordfence, and others) are a valuable layer and a good stopgap, but the vendors themselves say they’re not a substitute for patching.
