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.