deadexpl0it/wp2shell-pocwp2shell — PoC für die Pre-Auth-RCE-Chain im WordPress Core (CVE-2026-63030 und CVE-2026-60137)
Wenn Sie meine Arbeit schätzen, erwägen Sie bitte, das Projekt über USDT (TRC20): TQBA72kakjCZLnJt8fJYcD7dyQCEpzNtVN zu unterstützen
wp2shell ist ein Proof-of-Concept für Sicherheitsforschung, das eine Pre-Authentication-Schwachstellenkette im WordPress Core demonstriert, die Folgendes kombiniert:
WP_Query SQL-InjectionDie Kette demonstriert, wie diese Schwachstellen kombiniert werden können, um von einer nicht authentifizierten REST-API-Anfrage zu SQL-Injection, Privilegieneskalation, Erstellung eines Administratorkontos und letztendlich zu authentifizierter Remote-Codeausführung zu gelangen.
[!WARNING]
Nur autorisierte Sicherheitsforschung
Dieses Projekt ist vorgesehen für:
- Schwachstellenforschung
- Defensive Validierung
- Autorisierte Penetrationstests
- Sicherheitslabore
- CTFs und Bildungsumgebungen
Testen Sie nur Systeme, die Ihnen gehören oder für die Sie eine ausdrückliche schriftliche Genehmigung zur Bewertung haben.
Verwenden Sie dieses Projekt nicht gegen die Infrastruktur Dritter ohne Autorisierung.
wp2shell ist ein einheitliches Sicherheitsforschungstool für WordPress Core
zur Untersuchung der Interaktion zwischen zwei Schwachstellen:```text
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
Der PoC ist als Python-Forschungswerkzeug implementiert und nutzt die Python
Standardbibliothek, ohne dass Python-Pakete von Drittanbietern erforderlich sind.
---
# Schwachstellenkette
Das Projekt kombiniert zwei Sicherheitslücken im WordPress-Core.```text
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.
---
# CVE-2026-63030
## REST-API-Batch-Routenverwirrung
Die erste Schwachstelle betrifft die Verarbeitung von Anfragen über den
WordPress-REST-API-Batch-Endpunkt.
Die Batch-Implementierung hält Anfrageabgleich- und Validierungsinformationen
in parallelen Strukturen vor, die nach der Anfrageposition indiziert sind.
Eine fehlerhafte Unteranfrage kann dazu führen, dass diese Strukturen
desynchronisiert werden.
Dies erzeugt eine Off-by-one-Dispatch-Bedingung, bei der eine spätere Anfrage
mit einem Handler oder Validierungskontext verarbeitet werden kann, der einer
anderen Anfrage zugeordnet ist.
Konzeptionell:```text
Request A
|
+-- validation entry
+-- matching entry
|
v
Malformed request
|
+-- internal state becomes desynchronized
|
v
Request B
|
+-- unexpected handler / validation context
```
Der PoC führt Verhaltensprüfungen durch, um festzustellen, ob die
Route-Confusion tatsächlich erreichbar ist.
---
# CVE-2026-60137
## WP_Query SQL-Injection
Die zweite Schwachstelle betrifft einen `WP_Query`-SQL-Verarbeitungspfad.
Sobald das Route-Confusion-Primitive etabliert ist, kann
angreiferkontrollierte Eingabe den anfälligen Abfragepfad erreichen.
Der PoC demonstriert die resultierende SQL-Injection durch blinde
Differentialtests.
Die Forschungsfunktionen umfassen:
* Boolesch-blinde Bestätigung
* Optionale zeitbasierte Bestätigung
* Datenbank-Fingerprinting
* Unterstützte Skalar-Extraktion
* WordPress-Benutzerdaten-Analyse
---
# So funktioniert die Angriffskette
## 1. REST-Batch-Route-Confusion
Eine nicht authentifizierte Anfrage erreicht den WordPress-REST-Batch-Endpunkt.
Eine fehlerhaft formatierte Batch-Teilanfrage führt dazu, dass der interne
Request-Matching- und Validierungszustand desynchronisiert wird.
Eine spätere Anfrage kann folglich in einem unbeabsichtigten Kontext
verarbeitet werden.
---
## 2. SQL-Injection
Das Route-Confusion-Primitive stellt den Pfad bereit, der für die zweite
Schwachstelle benötigt wird.
Ein angreiferkontrollierter Wert kann den anfälligen `WP_Query`-
Verarbeitungspfad erreichen.
Dadurch entsteht ein Blind-SQL-Injection-Primitive.
---
## 3. Blinde SQL-Extraktion
Die SQL-Injection kann als boolesch-blinder Extraktionskanal genutzt werden.
Der PoC enthält Funktionen zur Untersuchung von Datenbankinformationen und
unterstützten WordPress-Benutzerinformationen.
---
## 4. Manipulation des Anwendungszustands
Die Kette nutzt datenbankgesteuerte Ergebnisse, um WordPress-Anwendungsobjekte
und die nachfolgende Verarbeitung zu beeinflussen.
Dies stellt die Primitive bereit, die für die Privilege-Escalation-Stufe
benötigt werden.
---
## 5. Changeset-Eskalation
Die Kette nutzt die WordPress-Changeset-Verarbeitung, um einen
Administrator-Ausführungskontext herzustellen.
Ein fabriziertes `customize_changeset`-Objekt kann an der
Privilege-Escalation-Sequenz teilnehmen.
---
## 6. Hook-Wiedereintritt
Die Kette tritt über den Anwendungs-Request-Lebenszyklus erneut in die
WordPress-Request-Verarbeitung ein.
Dadurch kann die nachfolgende API-Verarbeitung unter dem erweiterten Kontext
erfolgen.
---
## 7. Erstellung von Administratorkonten
Der Forschungs-PoC implementiert eine Pre-Authentication-Stufe zur
Administratorerstellung.
Dies ist der Hauptgrund, warum Modus 3 für die Sicherheitsvalidierung
nützlich ist: Er demonstriert die Auswirkungen der Privilege-Escalation,
ohne bis zur Webshell-/RCE-Stufe fortzufahren.
---
## 8. Authentifizierte Code-Ausführung
Modus 4 erweitert die Forschungskette über die Administratorerstellung hinaus
bis zur Stufe der authentifizierten Code-Ausführung.
Diese Stufe sollte nur in einem isolierten Labor oder im Rahmen einer
ausdrücklich autorisierten Prüfung verwendet werden.
---
# Betroffene Versionen
## Vollständige Pre-Authentication-Kette
| WordPress Version | Status |
| ----------------- | -------------- |
| 6.9.0 – 6.9.4 | **Verwundbar** |
| 7.0.0 – 7.0.1 | **Verwundbar** |
| 6.9.5 | **Behoben** |
| 7.0.2+ | **Behoben** |
Der PoC identifiziert `6.9.0–6.9.4` und `7.0.0–7.0.1` als die dokumentierten,
für die vollständige Kette anfälligen Versionen.
## SQL-Injection
Die SQL-Injection-Komponente hat eine andere Grenze für behobene Versionen
als die vollständige Kette.
Die Forschungsimplementierung identifiziert `6.8.6` als den Fix für die
SQL-Injection.
Die vollständige unauthentifizierte Kette hängt zusätzlich vom anfälligen
REST-Batch-Verhalten ab.
Überprüfen Sie betroffene und behobene Versionen stets anhand des
entsprechenden offiziellen Sicherheitshinweises, bevor Sie Entscheidungen für
die Produktion treffen.
---
# Voraussetzungen
Der PoC dokumentiert für die vollständige Kette folgende Bedingungen:
* WordPress-REST-API ist erreichbar
* Kein Redis-/Memcached-Objektcache
* Mindestens ein veröffentlichter Beitrag
Weitere Bereitstellungskomponenten können die Reproduzierbarkeit beeinflussen:
* Reverse-Proxys
* Web-Application-Firewalls
* REST-API-Einschränkungen
* Sicherheits-Plugins
* Objekt-Caching
* HTTP-Filterung
* Hosting-Konfiguration
Eine WordPress-Installation, die der Versionsspanne entspricht, bedeutet
nicht automatisch, dass die vollständige Kette in jeder Umgebung
funktioniert.
---
# Funktionen
`wp2shell` stellt ein interaktives Menü mit den folgenden
Forschungsfunktionen bereit:```text
[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
```
---
# Interaktives Menü
Das Hauptmenü ist dafür ausgelegt, beides zu unterstützen:
* Testen einer einzelnen autorisierten WordPress-Installation
* Testen einer autorisierten Liste von WordPress-URLs
Der Workflow kann daher sowohl für einzelne Forschungsziele
als auch für größere autorisierte Bewertungsdatensätze verwendet werden.
---
# Empfohlener Modus — Modus 3
## Warum Modus 3?
Für die Schwachstellenforschung ist **Modus 3 der empfohlene Modus, wenn das
Ziel darin besteht, die Sicherheitsauswirkung ohne Bereitstellung einer
webshell zu demonstrieren**.
Modus 3 ist:
---```text
Pre-Auth Admin Creation
```
Der PoC beschreibt diese Phase wie folgt:```text
Unauthenticated UNION SQLi → new WordPress administrator
```
und unterscheidet es ausdrücklich von der vollständigen Webshell/RCE-Stufe:```text
No password cracking.
No webshell.
Non-destructive admin only.
```
Dies macht Mode 3 besonders nützlich, wenn Sie nachweisen möchten, dass die
Schwachstellenkette eine Kompromittierung auf Administratorebene erreicht,
während die zusätzliche Phase der Codeausführung vermieden wird.
---
# Mode 3 — Pre-Auth-Admin-Erstellung
Bei Auswahl von Mode 3 öffnet sich:```text
────────────────────────────────────────────────────────────
CREATE ADMIN — Pre-Auth Admin RCE Chain
────────────────────────────────────────────────────────────
⚠ Unauthenticated UNION SQLi → new WordPress administrator.
⚠ No password cracking. No webshell. Non-destructive admin only.
```
Der PoC fragt dann nach verschiedenen Umgebungs- und Ausgabeoptionen.
## SQLite```text
→ Target uses SQLite? (WP-SQLite plugin) (y/N) [n]:
```
Setzen Sie dies auf `y`, wenn das autorisierte Ziel eine WordPress-SQLite-Konfiguration verwendet, die vom PoC unterstützt wird.
Für normale MySQL/MariaDB-WordPress-Installationen lautet der Standardwert:```text
n
```
## Überprüfung der Zugangsdaten
Der PoC kann die generierten Zugangsdaten optional verifizieren, indem er eine authentifizierte Anmeldung versucht:```text
→ Verify the generated credentials by logging in? (Y/n) [y]:
```
Der Standard ist:```text
y
```
Dies ist nützlich, wenn das Ergebnis eine Bestätigung enthalten soll, dass
sich die generierten Administrator-Anmeldedaten tatsächlich authentifizieren lassen.
---
## Ausgabedatei
Modus 3 kann Ergebnisse in einer lokalen Datei speichern:```text
→ Output file (blank = skip, e.g. result.txt):
```
Zum Beispiel:```text
logs.txt
```
Wenn das Feld leer gelassen wird, wird die Dateiausgabe übersprungen.
Die Ausgabeoption ist nützlich, wenn autorisierte Forschung über
mehrere Ziele hinweg durchgeführt wird und die Ergebnisse für eine spätere Analyse aufbewahrt werden sollen.
---
## Confusion Carrier
Das PoC bietet zwei Carrier-Varianten:```text
→ Confusion carrier variant (posts/categories) [posts]:
```
Verfügbare Optionen:```text
posts
categories
```
Der Standard ist:```text
posts
```
Die Variante `posts` ist der primär dokumentierte Pfad.
---
# Modus 1 — Fingerabdruck und Bestätigen
Modus 1 ist:```text
[1] Fingerprint + confirm vulnerability (non-destructive)
```
Dies ist der sicherste Ausgangspunkt für die Schwachstellenvalidierung.
Der Fokus liegt darauf festzustellen, ob das Ziel die verhaltensbezogenen
Bedingungen aufweist, die mit der Schwachstellenkette verbunden sind.
Die Prüfphase kann Folgendes umfassen:
* WordPress-Fingerprinting
* REST-Batch-Endpunkt-Prüfungen
* Bestätigung der Route-Confusion
* Bestätigung der SQL-Injection
* Boolean-Blind-Differential-Tests
* Optionale zeitbasierte Bestätigung
Verwenden Sie Modus 1, wenn das Ziel hauptsächlich darin besteht:```text
"Is this target potentially vulnerable?"
```
anstatt Administrator-Auswirkungen zu demonstrieren.
---
# Mode 2 — Blinde SQL-Extraktion
Mode 2 ist:```text
[2] Blind SQL extraction (fingerprint / dump users)
```
Dieser Modus demonstriert die SQL-Injection-Primitive durch blinde
Extraktion.
Die Recherchefunktionen umfassen:
* Datenbank-Fingerprinting
* Datenbankversion
* Datenbankbenutzer
* Datenbankname
* Unterstützte skalare SQL-Ausdrücke
* WordPress-Benutzerinformationen
Verwenden Sie diesen Modus nur in einer autorisierten Umgebung, da er die
Auswirkungen des Datenzugriffs demonstriert und nicht nur die Schwachstelle erkennt.
---
# Mode 3 — Admin-Erstellung ohne Authentifizierung
Mode 3 ist:```text
[3] Pre-Auth Admin creation
```
Dieser Modus demonstriert die Auswirkung der Kette auf die Privilegieneskalation.
Der wichtige Unterschied ist:```text
Mode 3
|
+-- Pre-authentication chain
+-- Administrator creation
+-- Optional login verification
+-- No password cracking
+-- No webshell
```
Für Sicherheitsforscher, die die Auswirkungen der Schwachstelle auf Administratorebene nachweisen müssen, ohne eine Webshell einzusetzen, ist dies der bevorzugte Modus.
---
# Mode 4 — Full RCE Chain
Mode 4 ist:```text
[4] Full RCE chain → admin creation + webshell
```
Dies erweitert die Kette über die Erstellung von Administratoren hinaus zu authentifizierter Codeausführung.
Konzeptionell:```text
Unauthenticated
↓
Route Confusion
↓
SQL Injection
↓
Privilege Escalation
↓
Administrator Creation
↓
Administrator Authentication
↓
Webshell
↓
Code Execution
```
Dieser Modus sollte auf isolierte Labore und ausdrücklich
autorisierte Penetrationstests beschränkt bleiben.
Für die übliche Schwachstellenvalidierung ist Modus 3 vorzuziehen, da er
die Grenze der Auswirkung auf den Administrator demonstriert, ohne eine
Webshell einzusetzen.
---
# Modus 5 — Erleichterte Sink-SQLi
Modus 5 ist:```text
[5] Facilitated sink SQLi (WordPress 6.8.x / custom)
```
Dieser Modus ist für Forschung vorgesehen, die den SQL-Injection-Sink außerhalb der vollständigen Pre-Authentifizierungskette betrifft.
Er ist nützlich für Forscher, die Folgendes untersuchen:
* WordPress-6.8.x-Umgebungen
* Benutzerdefinierte Konfigurationen
* Die SQL-Injection-Primitive unabhängig
* Reproduktion von Schwachstellen
* Defensive Validierung
---
# Mode 6 — Threaded URL Scan
Mode 6 ist:```text
[6] Threaded scan over URL list
```
Dieser Modus ist für autorisierte Bewertungen gedacht, die mehrere
WordPress-Ziele umfassen.
Anstatt eine URL nach der anderen manuell zu testen, kann das Tool eine
URL-Liste mithilfe von Worker-Threads verarbeiten.
Konzeptionell:```text
urls.txt
|
+-- URL 1
+-- URL 2
+-- URL 3
+-- URL 4
+-- ...
|
v
Threaded vulnerability checks
|
v
Results
```
Die Scan-Funktionalität kann Optionen wie die folgenden verwenden:
* Worker-Thread-Anzahl
* Bestätigungsverzögerung
* Optionaler Versionsnachweis
* JSON-Berichtsausgabe
* Confusion-Carrier-Variante
Verwenden Sie dies nur mit URL-Listen, für die Sie eine ausdrückliche Genehmigung haben.
---
# Einzelnes Ziel vs. URL-Liste
`wp2shell` kann auf zwei allgemeine Arten verwendet werden.
## Einzelnes WordPress-Ziel
Verwenden Sie ein einzelnes Ziel, wenn Sie eine Installation untersuchen.
Typische Anwendungsfälle:
* Lokales Labor
* Staging-Umgebung
* Vom Kunden genehmigter Penetrationstest
* Reproduktion von Schwachstellen
* CVE-Überprüfung
Das Ziel sollte eine WordPress-Basis-URL sein.
---
## URL-Liste
Für mehrere autorisierte Ziele kann Mode 6 eine URL-Liste verarbeiten.
Beispiel für eine konzeptionelle Datei:```text
https://wordpress-lab-01.example
https://wordpress-lab-02.example
https://wordpress-lab-03.example
https://wordpress-lab-04.example
```
Der threadbasierte Scanner kann dann die Liste verarbeiten und die Ergebnisse aufzeichnen.
Die Scan-Implementierung unterstützt außerdem eine Ausgabe-/Berichtsoption zum
Speichern der Befunde.
---
# Leitfaden zur Modusauswahl
| Ziel | Empfohlener Modus |
| -------------------------------------- | ---------------- |
| Prüfen, ob ein Ziel verwundbar ist | **Mode 1** |
| SQL-Injection demonstrieren | **Mode 2** |
| Auswirkungen auf Administratorebene demonstrieren | **Mode 3** |
| Vollständige RCE-Kette demonstrieren | **Mode 4** |
| Den SQLi-Sink unabhängig untersuchen | **Mode 5** |
| Eine autorisierte URL-Liste testen | **Mode 6** |
| Proxy/TLS/Timeout/Verzögerung konfigurieren | **Mode 7** |
| Das aktuelle Ziel ändern | **Mode 8** |
### Empfohlener Forschungs-Workflow
Für die meisten Sicherheitsbewertungen:```text
Mode 1
↓
Confirm vulnerability
↓
Mode 3
↓
Demonstrate administrator impact
```
Fahren Sie nur mit Mode 4 fort, wenn eine vollständige Code-Ausführungsvalidierung ausdrücklich
erforderlich und autorisiert ist.
---
# Mode 7 — Transporteinstellungen
Mode 7 ist:```text
[7] Transport settings (proxy, TLS, timeout, delay)
```
Dieser Abschnitt steuert das HTTP-Transportverhalten, das vom Tool verwendet wird.
Unterstützte Forschungseinstellungen umfassen:
* Proxy-Konfiguration
* TLS-Verhalten
* Request-Timeout
* Request-Verzögerung
* Verbindungs-/Wiederholungsverhalten
Diese Optionen sind nützlich, wenn WordPress-Installationen hinter folgenden Umgebungen getestet werden:
* Proxys
* TLS-Konfigurationen
* Langsamen Verbindungen
* Rate-Limiting-Infrastruktur
* Kontrollierten Laborumgebungen
---
# Modus 8 — Ziel-URL ändern
Modus 8 ist:```text
[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.
---
# Detection Logic
The PoC uses behavioral checks instead of relying exclusively on a
WordPress version string.
## REST Batch Detection
The tool verifies that the REST Batch endpoint is reachable.
## Route Confusion Detection
The tool can use:
* Response markers
* Structural response behavior
The structural approach checks whether a request intended for one REST
collection is processed as another collection.
## SQL Injection Detection
The tool can perform a boolean-blind differential.
A time-based channel can additionally be used as corroboration.
---
# Technical Chain
The complete research chain can be summarized as:```text
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
```
---
# Routenvarianten
Der PoC unterstützt zwei Confusion-Carrier-Varianten:```text
posts
categories
```
Der Standard ist:```text
posts
```
Der `posts`-Variant ist der primäre, dokumentierte End-to-End-Träger.
Der `categories`-Variant bietet einen alternativen Route-Confusion-Pfad
für Forschung.
---
# SQLite-Unterstützung
Der PoC enthält SQLite-Kompatibilitätsunterstützung für Umgebungen, die eine
WordPress-SQLite-Konfiguration verwenden.
Modus 3 legt diese Option offen als:```text
Target uses SQLite? (WP-SQLite plugin)
```
Standard:```text
n
```
Verwendung:```text
y
```
wenn das autorisierte Ziel die unterstützte SQLite-Konfiguration verwendet.
---
# Installation
Der PoC verwendet die Standardbibliothek von Python.
Es sind keine Drittanbieter-Pakete für Python erforderlich.
Erforderliche Umgebung:```text
Python 3.x
```
Klonen Sie das Repository und führen Sie das Research-Tool in einer isolierten oder
ausdrücklich autorisierten Umgebung aus.
---
# Projektstruktur
Eine empfohlene Repository-Struktur ist:```text
wp2shell/
│
├── wp2shell.py
├── README.md
├── LICENSE
└── screenshots/
```
Die Hauptforschungsimplementierung ist:```text
wp2shell.py
```
---
# Sicherheitsauswirkungen
Eine erfolgreiche Angriffskette kann potenziell zu Folgendem führen:
* Nicht authentifizierte SQL-Injection
* Offenlegung von Datenbankinformationen
* Offenlegung von WordPress-Benutzerinformationen
* Privilegienausweitung
* Erstellung von Administrator-Konten
* Voller administrativer Zugriff auf WordPress
* Authentifizierte Ausführung beliebigen Codes
* Potenzielle Kompromittierung auf Betriebssystemebene je nach Hosting-
Umgebung
Die vollständige Kette hat daher eine deutlich größere Auswirkung als die
einzeln betrachteten Schwachstellen.
---
# Defensive Erkennung
Administratoren sollten verdächtige Aktivitäten untersuchen, die Folgendes betreffen:
* WordPress-REST-Batch-Endpunkte
* Ungewöhnliche verschachtelte Batch-Anfragen
* Fehlerhafte Pfade von Batch-Anfragen
* Verdächtige Query-Parameter
* Unerwartete Erstellung von Administrator-Konten
* Unerwartete `customize_changeset`-Aktivität
* Unerwartete Plugin-Installationen
* Unerwartete PHP-Dateien
* Verdächtige Plugin-Modifikationen
* Webshell-ähnliches Verhalten
Überprüfung:```text
Web server logs
+
WordPress logs
+
Database audit logs
+
File integrity monitoring
```
especially around the time of suspected exploitation.
---
# Gegenmaßnahmen
Betroffene Installationen sollten außerdem:
1. Alle Administratorkonten überprüfen.
2. Nicht autorisierte Administratorkonten entfernen.
3. Kürzlich installierte oder geänderte Plugins überprüfen.
4. WordPress-REST-API-Protokolle überprüfen.
5. Webserver-Zugriffsprotokolle überprüfen.
6. Nach unerwarteten PHP-Dateien suchen.
7. Plugin-Verzeichnisse auf nicht autorisierte Änderungen prüfen.
8. Zugangsdaten rotieren, falls eine Kompromittierung vermutet wird.
9. Datenbankintegrität überprüfen.
10. Persistenzmechanismen entfernen.
11. Kompromittierte WordPress-Komponenten bei Bedarf aus vertrauenswürdigen Quellen neu installieren.
---
# Verantwortungsvoller Forschungsablauf
Für eine normale autorisierte Bewertung ist die empfohlene Vorgehensweise:```text
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 ist im Allgemeinen der bevorzugte Punkt zur Demonstration der Auswirkung, da er eine Kompromittierung auf Administratorebene herstellt, ohne die Webshell-Stufe einzusetzen.
---
# Forschung vs. Produktion
Dieses Projekt ist für kontrollierte Sicherheitsforschung gedacht.
Behandeln Sie das Tool nicht als allgemeinen Internetscanner.
Für Produktionsumgebungen:
* Schriftliche Genehmigung einholen.
* Den Zielumfang festlegen.
* Zulässige Aktionen festlegen.
* Nicht-destruktive Verifikation bevorzugen.
* Nach ausreichender Beweiserhebung stoppen.
* Protokolle und Beweise aufbewahren.
* Den geltenden Prozess zur Offenlegung von Schwachstellen befolgen.
---
# Danksagungen
Schwachstellenforschung / -entdeckung:
**Adam Kues**
Assetnote / Searchlight Cyber
Projekt:
**wp2shell**
Die Forschungsimplementierung identifiziert die Schwachstellenkette wie folgt:```text
CVE-2026-63030
+
CVE-2026-60137
```
---
# Referenzen
* CVE-2026-63030
* CVE-2026-60137
* GHSA-ff9f-jf42-662q
* GHSA-fpp7-x2x2-2mjf
* WordPress Core
* WordPress REST API
* WordPress `WP_Query`
---
# Haftungsausschluss
Dieses Repository enthält Sicherheitsforschung, die eine Schwachstellenkette
demonstriert, die den WordPress Core betrifft.
Die Software und die Dokumentation werden bereitgestellt für:
* Bildungszwecke
* Sicherheitsforschung
* Überprüfung von Schwachstellen
* Defensive Tests
* Autorisierte Penetrationstests
Die Autoren sind nicht verantwortlich für unbefugte oder böswillige Nutzung
dieses Materials.
**Testen Sie nur Systeme, die Ihnen gehören oder für die Sie eine
ausdrückliche Genehmigung haben.**
---
# Schlüsselwörter```text
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
```
## Repository-Themen
Empfohlene GitHub-Repository-Themen:```text
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
```
---
## Projektzusammenfassung```text
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.
```
Es wurde kein Eingabetext bereitgestellt. Bitte den Inhalt von Chunk 93 erneut senden.```
disclaimer: this project is for educational purposes only
```