WordPress site owners running versions 6.9.0 through 6.9.4 or 7.0.0 through 7.0.1 should update immediately. The WordPress security team has patched CVE-2026-63030, also called wp2shell, a critical pre-authentication remote code execution flaw in WordPress Core. An anonymous attacker can reach the vulnerable path on a stock installation; no plugin or valid account is required.[1]
The fixed releases are WordPress 6.9.5 and 7.0.2. WordPress has enabled forced automatic updates for affected sites, but administrators should verify the version that actually installed instead of assuming the background update completed.[2]
Which WordPress versions are affected?
| Installed version | Risk and action |
|---|---|
| 6.9.0–6.9.4 | Affected by wp2shell. Update to 6.9.5 or a later supported release. |
| 7.0.0–7.0.1 | Affected by wp2shell. Update to 7.0.2 or later. |
| 6.8.5 or earlier | Not affected by CVE-2026-63030. Other security fixes may still apply, so use a currently supported branch. |
| 7.1 beta | Use 7.1 Beta 2 or later if the site is intentionally testing the beta branch. |
The affected-range distinction matters. The same July security release also fixes a separate SQL injection issue in older branches, but the wp2shell chain itself was introduced in WordPress 6.9. Do not label every older WordPress site as vulnerable to this specific CVE.
What wp2shell can do
WordPress describes the issue as REST API batch-route confusion combined with SQL injection that leads to remote code execution. The critical advisory identifies the affected package and versions but does not publish exploit code.[1] Searchlight Cyber, whose researcher Adam Kues reported the flaw, says the attack has no preconditions and works against a default WordPress installation without plugins.[3]
Remote code execution means a successful attacker could run server-side code with the permissions available to the web process. The practical consequences can include altered pages, injected redirects, stolen configuration secrets, a new administrator, or a persistent backdoor. Those are possible outcomes of RCE, not published indicators for wp2shell. At publication time, the primary disclosures had withheld technical details and did not report confirmed exploitation in the wild.
How to verify the installed version
- Open Dashboard → Updates and read the installed WordPress version. If the site still shows 6.9.0–6.9.4 or 7.0.0–7.0.1, run the core update now.
- On hosts with WP-CLI, run
wp core versionfrom the WordPress root and confirm the result is 6.9.5, 7.0.2, or later. - Check every production, staging, forgotten subdomain, and client instance separately. A successful update on one site does not prove the others updated.
- After the update, load the site and admin area, test critical forms or checkout paths, and confirm that no maintenance-mode file or PHP error remains.
If an immediate update is impossible, Searchlight Cyber recommends temporarily blocking anonymous access to /wp-json/batch/v1 and ?rest_route=/batch/v1 at the WAF. Treat that only as an emergency bridge: blocking the batch API can break legitimate integrations, and it does not replace the core patch.[3]
What to check if the site may already be compromised
There are no public wp2shell-specific indicators in the primary disclosure, so do not invent a filename or IP blocklist. Preserve web, WAF, hosting, and authentication logs before cleanup, then review changes made since the vulnerable release was installed.
- Compare WordPress administrators and application passwords with an approved inventory.
- Review recently modified core files, active themes, plugins,
mu-plugins, scheduled tasks, and unexpected PHP files under writable directories. - Look for unexplained redirects, injected JavaScript, unfamiliar outbound connections, or changes to
wp-config.phpand server rules. - If compromise is plausible, restore from a verified clean backup, rotate database/hosting/admin credentials and WordPress salts, revoke sessions, and patch before returning the site to service.
A core update closes the vulnerable route but does not remove a backdoor planted before the patch. Our WordPress backdoor investigation guide explains why responders should inspect themes, plugins, uploads, and persistence rather than only delete a visible administrator.
What site owners should do now
- Back up the database and files using the normal verified backup workflow.
- Update WordPress Core to 6.9.5, 7.0.2, or a later supported release.
- Verify the version on every instance and confirm the public site still works.
- Remove any temporary WAF block only after the patched version is confirmed and required integrations have been tested.
- Escalate to incident response if logs, users, files, or redirects suggest the site changed before the patch.
References
- WordPress. “REST API batch-route confusion and SQL injection issue leading to Remote Code Execution.” GitHub Security Advisory GHSA-ff9f-jf42-662q, published July 17, 2026, accessed July 17, 2026. https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-ff9f-jf42-662q
- WordPress.org. “Version 7.0.2.” WordPress Documentation, published and updated July 17, 2026, accessed July 17, 2026. https://wordpress.org/documentation/wordpress-version/version-7-0-2/
- Adam Kues. “wp2shell: Pre Authentication RCE in WordPress Core.” Searchlight Cyber, published July 17, 2026, accessed July 17, 2026. https://slcyber.io/research-center/wp2shell-pre-authentication-rce-in-wordpress-core/
