deadexpl0it/wp2shell-pocwp2shell — WordPress Core Pre-Auth RCE Chain poc for CVE-2026-63030 and CVE-2026-60137
If you appreciate my work, consider supporting the project via USDT (TRC20): TQBA72kakjCZLnJt8fJYcD7dyQCEpzNtVN
wp2shell is a security research Proof-of-Concept demonstrating a pre-authentication vulnerability chain in WordPress Core combining:
WP_Query SQL injectionThe chain demonstrates how these vulnerabilities can be combined to move from an unauthenticated REST API request to SQL injection, privilege escalation, administrator account creation, and ultimately authenticated remote code execution.
[!WARNING]
Authorized Security Research Only
This project is intended for:
- Vulnerability research
- Defensive validation
- Authorized penetration testing
- Security laboratories
- CTFs and educational environments
Only test systems that you own or have explicit written authorization to assess.
Do not use this project against third-party infrastructure without authorization.
wp2shell is a unified WordPress Core security research tool for
investigating the interaction between two vulnerabilities:
CVE-2026-63030
|
v
REST API Batch Route Confusion
|
v
Validation / Dispatch Confusion
|
v
CVE-2026-60137
|
v
WP_Query SQL Injection
|
v
Blind SQL Access
|
v
Application / Object-State Manipulation
|
v
Privilege Escalation
|
v
Administrator Account Creation
|
v
Authenticated Code Execution
The PoC is implemented as a Python research tool and uses the Python standard library without requiring third-party Python packages.
The project combines two WordPress Core vulnerabilities.
Unauthenticated Request
|
v
+----------------------+
| CVE-2026-63030 |
| REST Batch Route |
| Confusion |
+----------+-----------+
|
v
Validation Confusion
|
v
+----------------------+
| CVE-2026-60137 |
| WP_Query SQLi |
+----------+-----------+
|
v
Blind SQLi
|
v
Application-State Abuse
|
v
Privilege Escalation
|
v
Administrator Access
|
v
Authenticated RCE
The important security property is the interaction between the two vulnerabilities rather than either vulnerability in isolation.
The first vulnerability affects processing of requests through the WordPress REST API Batch endpoint.
The batch implementation maintains request matching and validation information in parallel structures indexed by request position.
A malformed sub-request can cause those structures to become desynchronized.
This creates an off-by-one dispatch condition where a later request can be processed using a handler or validation context associated with another request.
Conceptually:
Request A
|
+-- validation entry
+-- matching entry
|
v
Malformed request
|
+-- internal state becomes desynchronized
|
v
Request B
|
+-- unexpected handler / validation context
The PoC performs behavioral checks to determine whether the route confusion is actually reachable.
The second vulnerability affects a WP_Query SQL processing path.
Once the route-confusion primitive is established, attacker-controlled input can reach the vulnerable query path.
The PoC demonstrates the resulting SQL injection through blind differential testing.
The research functionality includes:
An unauthenticated request reaches the WordPress REST Batch endpoint.
A malformed batch sub-request causes the internal request matching and validation state to become desynchronized.
A later request can consequently be processed using an unintended context.
The route-confusion primitive provides the path needed for the second vulnerability.
An attacker-controlled value can reach the vulnerable WP_Query
processing path.
This creates a blind SQL injection primitive.
The SQL injection can be used as a boolean-blind extraction channel.
The PoC contains functionality for researching database information and supported WordPress user information.
The chain uses database-controlled results to influence WordPress application objects and subsequent processing.
This provides the primitives needed by the privilege-escalation stage.
The chain uses WordPress changeset processing to establish an administrator execution context.
A fabricated customize_changeset object can participate in the
privilege-escalation sequence.
The chain re-enters WordPress request processing through the application request lifecycle.
This allows subsequent API processing to occur under the elevated context.
The research PoC implements a pre-authentication administrator creation stage.
This is the key reason Mode 3 is useful for security validation: it demonstrates the privilege-escalation impact without continuing into the webshell/RCE stage.
Mode 4 extends the research chain beyond administrator creation into the authenticated code-execution stage.
This stage should only be used in an isolated laboratory or an explicitly authorized assessment.
| WordPress Version | Status |
|---|---|
| 6.9.0 – 6.9.4 | Vulnerable |
| 7.0.0 – 7.0.1 | Vulnerable |
| 6.9.5 | Fixed |
| 7.0.2+ |
The PoC identifies 6.9.0–6.9.4 and 7.0.0–7.0.1 as the documented
full-chain vulnerable versions.
The SQL injection component has a different fixed-version boundary from the complete chain.
The research implementation identifies 6.8.6 as the SQL injection fix.
The complete unauthenticated chain additionally depends on the vulnerable REST Batch behavior.
Always verify affected and fixed versions against the relevant official security advisory before making production decisions.
The PoC documents these conditions for the complete chain:
Other deployment components may affect reproducibility:
A WordPress installation matching the version range does not automatically mean that the complete chain will work in every environment.
wp2shell provides an interactive menu containing the following
research functions:
[1] Fingerprint + confirm vulnerability (non-destructive)
[2] Blind SQL extraction (fingerprint / dump users)
[3] Pre-Auth Admin creation
[4] Full RCE chain → admin creation + webshell
[5] Facilitated sink SQLi (WordPress 6.8.x / custom)
[6] Threaded scan over URL list
[7] Transport settings (proxy, TLS, timeout, delay)
[8] Change target URL
[0] Quit
The main menu is designed to support both:
The workflow can therefore be used for both individual research targets and larger authorized assessment datasets.
For vulnerability research, Mode 3 is the recommended mode when the goal is to demonstrate the security impact without deploying a webshell.
Mode 3 is:
Pre-Auth Admin Creation
The PoC describes this stage as:
Unauthenticated UNION SQLi → new WordPress administrator
and explicitly distinguishes it from the full webshell/RCE stage:
No password cracking.
No webshell.
Non-destructive admin only.
This makes Mode 3 particularly useful when you want to prove that the vulnerability chain reaches administrator-level compromise while avoiding the additional code-execution stage.
Selecting Mode 3 opens:
────────────────────────────────────────────────────────────
CREATE ADMIN — Pre-Auth Admin RCE Chain
────────────────────────────────────────────────────────────
⚠ Unauthenticated UNION SQLi → new WordPress administrator.
⚠ No password cracking. No webshell. Non-destructive admin only.
The PoC then asks for several environment and output options.
→ Target uses SQLite? (WP-SQLite plugin) (y/N) [n]:
Set this to y when the authorized target uses a WordPress SQLite
configuration supported by the PoC.
For normal MySQL/MariaDB WordPress installations, the default is:
n
The PoC can optionally verify the generated credentials by attempting an authenticated login:
→ Verify the generated credentials by logging in? (Y/n) [y]:
The default is:
y
This is useful when you want the result to include confirmation that the generated administrator credentials actually authenticate.
Mode 3 can save results to a local file:
→ Output file (blank = skip, e.g. result.txt):
For example:
logs.txt
Leaving the field blank skips file output.
The output option is useful when performing authorized research across multiple targets and wanting to retain the results for later analysis.
The PoC provides two carrier variants:
→ Confusion carrier variant (posts/categories) [posts]:
Available choices:
posts
categories
The default is:
posts
The posts variant is the primary documented path.
Mode 1 is:
[1] Fingerprint + confirm vulnerability (non-destructive)
This is the safest starting point for vulnerability validation.
It focuses on determining whether the target exhibits the behavioral conditions associated with the vulnerability chain.
The check stage can include:
Use Mode 1 when the goal is primarily:
"Is this target potentially vulnerable?"
rather than demonstrating administrator impact.
Mode 2 is:
[2] Blind SQL extraction (fingerprint / dump users)
This mode demonstrates the SQL injection primitive through blind extraction.
Research functionality includes:
Use this mode only in an authorized environment because it demonstrates data-access impact rather than merely detecting the vulnerability.
Mode 3 is:
[3] Pre-Auth Admin creation
This mode demonstrates the privilege-escalation impact of the chain.
The important distinction is:
Mode 3
|
+-- Pre-authentication chain
+-- Administrator creation
+-- Optional login verification
+-- No password cracking
+-- No webshell
For security researchers who need to prove the vulnerability's administrator-level impact without deploying a webshell, this is the preferred mode.
Mode 4 is:
[4] Full RCE chain → admin creation + webshell
This extends the chain beyond administrator creation into authenticated code execution.
Conceptually:
Unauthenticated
↓
Route Confusion
↓
SQL Injection
↓
Privilege Escalation
↓
Administrator Creation
↓
Administrator Authentication
↓
Webshell
↓
Code Execution
This mode should be restricted to isolated laboratories and explicitly authorized penetration tests.
For ordinary vulnerability validation, Mode 3 is preferable because it demonstrates the administrator-impact boundary without deploying a webshell.
Mode 5 is:
[5] Facilitated sink SQLi (WordPress 6.8.x / custom)
This mode is intended for research involving the SQL injection sink outside the complete pre-authentication chain.
It is useful for researchers investigating:
Mode 6 is:
[6] Threaded scan over URL list
This mode is intended for authorized assessments involving multiple WordPress targets.
Instead of manually testing one URL at a time, the tool can process a URL list using worker threads.
Conceptually:
urls.txt
|
+-- URL 1
+-- URL 2
+-- URL 3
+-- URL 4
+-- ...
|
v
Threaded vulnerability checks
|
v
Results
The scan functionality can use options such as:
Use this only with URL lists for which you have explicit authorization.
wp2shell can be used in two general ways.
Use a single target when researching one installation.
Typical use cases:
The target should be a WordPress base URL.
For multiple authorized targets, Mode 6 can process a URL list.
Example conceptual file:
https://wordpress-lab-01.example
https://wordpress-lab-02.example
https://wordpress-lab-03.example
https://wordpress-lab-04.example
The threaded scanner can then process the list and record the results.
The scan implementation also supports an output/report option for retaining findings.
For most security assessments:
Mode 1
↓
Confirm vulnerability
↓
Mode 3
↓
Demonstrate administrator impact
Only continue to Mode 4 when full code-execution validation is explicitly required and authorized.
Mode 7 is:
[7] Transport settings (proxy, TLS, timeout, delay)
This section controls the HTTP transport behavior used by the tool.
Supported research settings include:
These options are useful when testing WordPress installations behind:
Mode 8 is:
[8] Change target URL
This allows the currently selected target to be changed without restarting the entire interactive workflow.
It is useful when moving between authorized laboratory installations.
The PoC uses behavioral checks instead of relying exclusively on a WordPress version string.
The tool verifies that the REST Batch endpoint is reachable.
The tool can use:
The structural approach checks whether a request intended for one REST collection is processed as another collection.
The tool can perform a boolean-blind differential.
A time-based channel can additionally be used as corroboration.
The complete research chain can be summarized as:
1. REST API reachable
|
v
2. Batch route confusion
|
v
3. Validation / dispatch confusion
|
v
4. SQL injection reaches WP_Query
|
v
5. Blind SQL channel
|
v
6. Application-state manipulation
|
v
7. Changeset privilege escalation
|
v
8. Administrator context
|
v
9. Administrator account creation
|
v
10. Authenticated code execution
The PoC supports two confusion-carrier variants:
posts
categories
The default is:
posts
The posts variant is the primary documented end-to-end carrier.
The categories variant provides an alternative route-confusion path
for research.
The PoC contains SQLite compatibility support for environments using a WordPress SQLite configuration.
Mode 3 exposes this option as:
Target uses SQLite? (WP-SQLite plugin)
Default:
n
Use:
y
when the authorized target uses the supported SQLite configuration.
The PoC uses Python's standard library.
No third-party Python packages are required.
Required environment:
Python 3.x
Clone the repository and run the research tool inside an isolated or explicitly authorized environment.
A recommended repository structure is:
wp2shell/
│
├── wp2shell.py
├── README.md
├── LICENSE
└── screenshots/
The main research implementation is:
wp2shell.py
A successful exploitation chain can potentially result in:
The complete chain therefore has significantly greater impact than the individual vulnerabilities considered independently.
Administrators should investigate suspicious activity involving:
customize_changeset activityReview:
Web server logs
+
WordPress logs
+
Database audit logs
+
File integrity monitoring
especially around the time of suspected exploitation.
The primary mitigation is upgrading WordPress to a fixed release.
Affected installations should also:
For a normal authorized assessment, the recommended progression is:
START
|
v
┌─────────────────┐
│ MODE 1 │
│ Detect / Confirm│
└────────┬────────┘
|
Vulnerable?
/ \
No Yes
| |
STOP v
┌───────────────┐
│ MODE 3 │
│ Admin Impact │
└───────┬───────┘
|
Need full RCE?
/ \
No Yes
| |
STOP v
┌───────────────┐
│ MODE 4 │
│ Full RCE Lab │
└───────────────┘
Mode 3 is generally the preferred impact-demonstration point because it establishes administrator-level compromise without deploying the webshell stage.
This project is intended for controlled security research.
Do not treat the tool as a general-purpose Internet scanner.
For production environments:
Vulnerability research / discovery:
Adam Kues Assetnote / Searchlight Cyber
Project:
wp2shell
The research implementation identifies the vulnerability chain as:
CVE-2026-63030
+
CVE-2026-60137
WP_QueryThis repository contains security research demonstrating a vulnerability chain affecting WordPress Core.
The software and documentation are provided for:
The authors are not responsible for unauthorized or malicious use of this material.
Only test systems you own or systems for which you have explicit authorization.
wp2shell
WordPress
WordPress Core
WordPress Security
WordPress Vulnerability
WordPress RCE
Pre-Auth RCE
Pre-Authentication RCE
CVE-2026-63030
CVE-2026-60137
REST API
REST Batch
REST API Batch
Route Confusion
WP_Query
SQL Injection
SQLi
Blind SQL Injection
Privilege Escalation
Administrator Creation
Remote Code Execution
RCE
Proof of Concept
PoC
Security Research
Penetration Testing
Recommended GitHub repository topics:
wp2shell
wordpress
wordpress-core
wordpress-security
wordpress-vulnerability
wordpress-rce
cve
cve-2026-63030
cve-2026-60137
poc
proof-of-concept
rce
sql-injection
sqli
blind-sqli
rest-api
security-research
penetration-testing
privilege-escalation
wp2shell is a WordPress Core pre-authentication vulnerability-chain PoC
combining CVE-2026-63030 (REST API Batch route confusion) and
CVE-2026-60137 (WP_Query SQL injection), demonstrating the progression
from unauthenticated access to SQL injection, privilege escalation,
administrator creation, and authenticated code execution.
disclaimer: this project is for educational purposes only
| Fixed |
| Goal | Recommended Mode |
|---|
| Check whether a target is vulnerable | Mode 1 |
| Demonstrate SQL injection | Mode 2 |
| Demonstrate administrator-level impact | Mode 3 |
| Demonstrate complete RCE chain | Mode 4 |
| Research the SQLi sink independently | Mode 5 |
| Test an authorized URL list | Mode 6 |
| Configure proxy/TLS/timeout/delay | Mode 7 |
| Change the current target | Mode 8 |