The wp2shell WordPress core vulnerability explained: affected versions, security updates, immediate actions, compromise checks, and verified developments.
Topics Hardening & checklists
Updated Published
Attack telemetry and post-exploitation reporting refreshed
Wordfence published technical analysis and real attack data. Broader reporting confirms opportunistic webshell and malicious-plugin installs. Compromise checks and sources on this page were updated.
Advisory published
Initial advisory with affected versions, fixed releases, recommended checks, and primary sources.
Added to CISA Known Exploited Vulnerabilities Catalog
CISA added CVE-2026-63030 and CVE-2026-60137 to the KEV catalog based on evidence of active exploitation.
WordPress security releases published
WordPress 6.8.6, 6.9.5, and 7.0.2 were released with security fixes for the related core vulnerabilities.
WordPress core had a serious vulnerability (wp2shell). Updates are out. Confirm every site is on 6.8.6, 6.9.5, 7.0.2, or newer.
This is core, not a plugin. Auto-updates were forced for many installs, but still check the version yourself.
Exploitation moved quickly from probing to opportunistic takeovers. Security researchers have reported webshells and malicious plugins on compromised sites. CISA has listed both related CVEs in its Known Exploited Vulnerabilities Catalog.
Fixed versions
Confirm that every WordPress install is on 6.8.6, 6.9.5, 7.0.2, or newer. Updating closes the known holes, but it does not by itself prove a previously exposed site is clean.
| WordPress branch | Exposure | Fixed version |
|---|---|---|
| 7.0 through 7.0.1 | Both vulnerabilities and complete attack chain | 7.0.2 |
| 6.9 through 6.9.4 | Both vulnerabilities and complete attack chain | 6.9.5 |
| 6.8 through 6.8.5 | Related SQL-injection vulnerability only | 6.8.6 |
| Earlier than 6.8 | Not affected by these two vulnerabilities | Upgrade to a currently supported branch |
Older WordPress
Versions before 6.8 are not affected by these two vulnerabilities. That does not mean older or unsupported WordPress installs are generally safe. Unsupported branches still need a supported upgrade path.
WordPress 7.0.2 was released on July 17, 2026 and fixed one critical and one high-severity core issue. WordPress 6.9 is affected by both. WordPress 6.8 is affected only by the facilitated SQL-injection vulnerability. Because of the severity, WordPress enabled forced automatic updates for affected installations.
If you manage many sites, verify each install, not only the one you happen to have open.
/wp-json/batch/v1 or ?rest_route=/batch/v1), especially unusual Multi-Status (HTTP 207) responses.Changing passwords alone does not clean a compromised site. If you find clear signs of intrusion, treat credentials, files, and plugins as one problem, not separate chores.
Installing the update stops the known vulnerability from being used going forward. It does not undo anything an attacker may have done while the site was still vulnerable.
A fixed version in the dashboard is not the same as finishing a security check.
If you updated quickly and nothing looks wrong after a quick review, you may not need a full incident response. If you find suspicious accounts, files, plugins, redirects, or logs, dig deeper.
Rule of thumb
Update first. Then decide how deep to investigate based on what you find in users, plugins, files, and logs, not based on headlines alone.
wp2shell is the informal name used for this WordPress core vulnerability chain in security discussions and tooling. The complete chain combines a REST API batch route/handler confusion issue with an SQL-injection issue.
At a high level:
WP_Query.Wordfence recorded probing of WordPress REST API traffic on July 17, 2026, with a clear SQL-injection attempt minutes later. Later reporting from multiple vendors describes opportunistic campaigns that install webshells and malicious plugins after a successful chain. No exploit steps here on purpose.
Treat these as areas to investigate, not proof that a website has been compromised:
/wp-json/batch/v1 or ?rest_route=/batch/v1), especially HTTP 207 Multi-Status responseswp2shell or rezwp2shell (reported as tool signatures)wp-config.php, .htaccess, server configuration, or must-use pluginsIf you still have admin access, a malware scan and security tests can help surface suspicious files and configuration issues. For confirmed compromise, professional cleanup is often the safer path.
A web application firewall may block known attack patterns and reduce exposure while you update. Useful, but:
A security plugin does not replace applying the official WordPress security releases for this issue. WP Security Ninja can still help with monitoring and scanning after you update.
No. It is a WordPress core vulnerability chain. Plugins and themes are not the root cause of these two issues, though a compromised site may still show malicious plugins or file changes after exploitation.
WordPress 7.0 through 7.0.1 and 6.9 through 6.9.4 are affected by both issues in the chain. WordPress 6.8 through 6.8.5 is affected by the related SQL-injection vulnerability only. Fixed releases are 7.0.2, 6.9.5, and 6.8.6.
WordPress enabled forced automatic updates for affected installations because of the severity. You should still verify that every site reached a fixed version. Automatic updates can fail on some hosts, locked files, or heavily customized setups.
In wp-admin, open Dashboard → Updates, or check the version shown on the About WordPress screen / admin footer (depending on your setup). Hosting panels and WP-CLI (wp core version) also report it.
No. Updating closes the known vulnerabilities going forward. It does not undo earlier unauthorized changes. Investigate if you see suspicious accounts, files, plugins, redirects, or logs.
Disabling the REST API is not the recommended fix and can break legitimate features. Install the official security update for your WordPress branch instead. If you cannot update immediately, a temporary edge rule against anonymous batch REST access is a bridge, not a replacement for the core release.
No. Update WordPress first. Security plugins can help with detection, monitoring, and layered protection, but they do not replace applying the core security releases.
Treat it as a serious indicator. Do not only delete the user and move on. Investigate how it was created, review plugins and file changes, rotate credentials, and consider a full malware review or cleanup help.
They are not affected by these two specific vulnerabilities. That is not the same as being secure or supported. Unsupported versions still need upgrading to a currently maintained branch.
Watch the WordPress.org news post for 7.0.2, the CISA KEV catalog, and this advisory page. We update the Latest developments section when something material changes.
After you update
Keeping WordPress updated is the first line of defense. When you are ready for extra monitoring, WP Security Ninja can help review configuration, watch security events, and spot suspicious changes. Pricing and trials are there if you want Pro later.
Found this useful? Share it.