WordPress WP2Shell Vulnerabilities: CVE-2026-63030 and CVE-2026-60137 Explained
WordPress 7.0.2 fixes two core flaws that can be chained for unauthenticated remote code execution. This analysis covers affected versions, technical causes, updates, temporary mitigations, and investigation steps.
The WordPress wp2shell vulnerability is a chain of two flaws in WordPress core, tracked as CVE-2026-63030 and CVE-2026-60137. On affected WordPress 6.9 and 7.0 installations, an anonymous attacker can combine a REST API route confusion flaw with an SQL injection flaw and reach remote code execution.
This is a WordPress core issue, not a vulnerable plugin or theme. The WordPress security release fixes the chain in WordPress 6.9.5 and 7.0.2, while WordPress 6.8.6 fixes the separate SQL injection weakness that affects the 6.8 branch.
Key Takeaways
- CVE-2026-63030 and CVE-2026-60137 affect WordPress core rather than a specific plugin or theme.
- WordPress 6.9.0 through 6.9.4 and 7.0.0 through 7.0.1 are vulnerable to the full unauthenticated remote code execution chain.
- Administrators should update to WordPress 6.9.5 or 7.0.2, or to 6.8.6 if they remain on the 6.8 branch.
- A temporary block on anonymous REST batch requests may reduce exposure, but it can disrupt legitimate features and does not replace the core update.
WordPress WP2Shell Is a Core Vulnerability Chain
WordPress security reporting often concerns a plugin or theme, which can lead administrators to check an extension list and miss a core update. That approach is wrong for wp2shell. Both CVE records name WordPress itself as the affected product, and the official fixes ship as WordPress core releases.
The chain combines two failures at different layers. CVE-2026-63030 lets a REST API batch request become associated with the wrong handler, while CVE-2026-60137 permits unsafe data to enter an SQL clause through WP_Query.
The official GitHub advisory for CVE-2026-63030 says the attack can reach remote code execution when combined with the SQL injection issue. Searchlight Cyber researcher Adam Kues, who reported the route confusion flaw, states that the full chain works against a stock WordPress installation without plugins and does not require authentication.
CVE-2026-60137 has a narrower meaning when considered alone. The NVD record for CVE-2026-60137 says exploitation can occur when a plugin or theme passes untrusted input into author__not_in. On WordPress 6.9 and later, CVE-2026-63030 supplies a core path that can carry unvalidated input to that query variable.
Which WordPress Versions Are Affected
The branch matters because the REST flaw entered WordPress later than the query flaw. WordPress 6.8 contains CVE-2026-60137 but does not contain the route confusion issue needed for the stock-install wp2shell chain. WordPress versions before 6.8 are not affected by either issue, according to the WordPress release notice.
| WordPress branch | Vulnerability exposure | Fixed version |
|---|---|---|
| Before 6.8 | Neither issue affects these branches | No wp2shell update required |
| 6.8.0 through 6.8.5 | CVE-2026-60137 only | 6.8.6 |
| 6.9.0 through 6.9.4 | Full CVE-2026-63030 and CVE-2026-60137 chain | 6.9.5 |
| 7.0.0 through 7.0.1 | Full CVE-2026-63030 and CVE-2026-60137 chain | 7.0.2 |
| 7.1 beta 1 | Both issues in a prerelease build | 7.1 beta 2 |
The WordPress team enabled forced automatic updates because of the severity. Filesystem permissions, disabled background updates, hosting controls, or failed maintenance jobs can still leave an installation behind. Administrators need to check the running version.
How CVE-2026-60137 Creates the SQL Injection Primitive
WP_Query converts request parameters into database queries for posts and other WordPress objects. The vulnerable code handled the author__not_in query variable safely only when PHP presented the value as an array. It applied integer conversion to array elements, but a string value skipped that branch.
Patchstack’s technical analysis of the WordPress 7.0.2 fixes shows what happened next. The code cast the unsanitized string to an array, joined the result, and concatenated it into the SQL WHERE clause. The patched code passes the value through wp_parse_id_list(), which produces a list of integer identifiers regardless of the input’s original type.
This flaw is described as facilitated SQL injection because ordinary WordPress REST processing validates the related author_exclude parameter as an array of integers. A vulnerable plugin or theme could still pass hostile input directly to author__not_in on WordPress 6.8. In WordPress 6.9 and 7.0, the batch route confusion flaw creates a path around the expected REST validation.
How CVE-2026-63030 Breaks REST Handler Binding
The WordPress REST batch endpoint accepts several subrequests in one request. The server parses each subrequest, finds a matching route, validates the input, checks permission, and dispatches the selected callback. Those steps are safe only if every result remains bound to the same subrequest and handler.
Patchstack found that the vulnerable implementation stored parsed requests and handler matches in separate arrays. When a malformed path produced an error, the request remained at its original position but the code did not add a matching entry at the same position. Later code looked up a handler by the request’s original index, so the two arrays no longer referred to the same subrequest.
That index shift could cause WordPress to validate a subrequest against one route and execute it through another route’s callback. A nested batch request could repeat the mismatch and carry a scalar author_exclude value to the unauthenticated posts collection callback. The value then reached the vulnerable author__not_in processing in WP_Query.
The WordPress fix keeps the request and match arrays aligned when parsing fails. It also adds a guard against starting a fresh top-level REST processing cycle while another dispatch is running. Internal subrequests must use the existing dispatch path, which closes the nested processing route used by the chain.
Why SQL Injection Can End in Remote Code Execution
SQL injection and remote code execution describe different outcomes. SQL injection lets an attacker alter a database query, while remote code execution means attacker-controlled instructions run on the server. The WordPress advisory states that the two core flaws combine to produce remote code execution on the affected 6.9 and 7.0 branches.
Administrators do not need to reproduce the full chain before treating it as urgent. Searchlight Cyber withheld exploit details at disclosure to give sites time to update. Testing an exploit on a production site could alter data and erase evidence.
An anonymous network request can reach an SQL injection path on vulnerable versions, and the vendor classifies the combined result as critical remote code execution. That supports emergency patching without publishing a copyable payload.
Severity Ratings Differ Across Public Records
The public scores look inconsistent because they assess different pieces and use different producers. WordPress calls its release a fix for one critical and one high severity issue. The WordPress GitHub advisories label CVE-2026-63030 critical and CVE-2026-60137 moderate.
The NVD pages had not published an NVD assessment at the time of this review. They displayed WPScan scores of 9.8 for CVE-2026-63030 and 5.9 for CVE-2026-60137. Wordfence scored the issues at 9.8 and 7.5.
Administrators should not let the lower standalone SQL injection score weaken the response to the chain. The affected WordPress version determines whether the REST flaw can turn the query weakness into an anonymous core attack. Version and reachability answer the immediate remediation question more directly than comparing scores from separate records.
How WordPress Administrators Should Respond
First, identify every WordPress installation, including staging sites and instances managed by a hosting provider. Check the Updates screen or run wp core version with WP-CLI. Record the current version before changing it.
Update each 6.9 site to at least 6.9.5 and each 7.0 site to at least 7.0.2. A site that must remain on WordPress 6.8 should run at least 6.8.6. Back up the database and files under the site’s normal change procedure, apply the core update, and confirm that the reported version changed.
Test publishing, authentication, forms, ecommerce, and integrations that use the REST API. The patch removes the vulnerable code, while a web application firewall or security plugin remains a supporting measure. Verify each site separately.
Temporary REST API mitigation
Searchlight Cyber recommends blocking anonymous access to the REST batch endpoint if an immediate update is impossible. The relevant paths are /wp-json/batch/v1 and the query-style equivalent that uses rest_route=/batch/v1. A host or web application firewall can deny those requests until the core update is installed.
This block can break legitimate clients that use batch requests, and blocking the complete REST API would have a wider effect. Document the temporary rule, test the site after applying it, and remove the rule only after confirming the patched core version. Do not treat a generic SQL injection rule as proof that the full chain is unreachable.
How to Investigate Possible WP2Shell Exposure
Preserve web server, CDN, firewall, WordPress, PHP, and database logs before retention jobs remove them. Search HTTP records for nested batch activity, malformed subrequest paths, and requests that carry author_exclude. One matching request does not prove successful code execution.
Review WordPress administrator accounts for entries the site owner does not recognize, as Patchstack recommends. Check account creation and password-change times where logs permit, then inspect recent changes to active themes, plugins, must-use plugins, uploads, scheduled tasks, and files under the web root. Compare core files with a known release rather than relying only on modification times.
Database review should cover new users, altered capabilities, unexpected options, injected posts, and scheduled events. If evidence suggests compromise, isolate the site, preserve a copy, rotate WordPress and hosting credentials, replace core files from a trusted package, and start incident response. An update does not remove access that an attacker may already have established.
Public reporting on exploitation status can change quickly. Patchstack reported observing attempts against the flaws, while the CISA-provided SSVC data shown by NVD recorded “none” for exploitation on July 17. Treat those statements as time-bound signals from different sources, not as proof about any individual site.
What WordPress Developers Should Learn from the Chain
The query flaw shows why sanitization cannot depend on the input arriving with the expected PHP type. Code that accepts IDs should convert every accepted representation into a known integer list before constructing a query. Parameterized database operations remain preferable whenever the API permits them.
The REST flaw shows that validation, permission checks, and execution must refer to the same immutable handler decision. Parallel arrays indexed through different error paths make that guarantee fragile. Tests should include malformed elements before valid batch entries, nested dispatch, mixed methods, and rejected routes.
Extension developers should audit any code that sends untrusted values into WP_Query, even after the core update. The patch closes the known author__not_in path, but the broader lesson applies to custom query variables and direct database calls. The OWASP Open Source Software Top 10 guide explains why a CVE scan is only one part of dependency and component risk review.
Frequently Asked Questions
Is wp2shell a WordPress plugin vulnerability?
No, wp2shell is a vulnerability chain in WordPress core. CVE-2026-63030 affects REST batch request handling, while CVE-2026-60137 affects WP_Query input handling. Plugins or themes matter to the standalone SQL injection scenario on WordPress 6.8, but the full chain reaches a stock installation on affected 6.9 and 7.0 versions.
Which WordPress version fixes CVE-2026-63030?
WordPress 6.9.5 and 7.0.2 fix CVE-2026-63030. WordPress 6.8 does not contain this REST route confusion flaw. Administrators should still install 6.8.6 because that release fixes CVE-2026-60137.
Does the WordPress automatic update remove the risk?
The update removes the vulnerable core code if it completed successfully. Administrators still need to verify the running version because background updates can be disabled or fail. A successful update also does not determine whether a previously exposed site was compromised.
Can a firewall replace the WordPress core update?
No, a firewall rule is a temporary risk reduction measure. Blocking anonymous batch endpoints can affect legitimate site behavior and may miss another path to the same vulnerable code. Install the patched WordPress release and use firewall controls as an extra layer.