tcyph3r/wp2shell-cve-2026-63030-root-causeUnabhängige Root-Cause-Analyse und Proof-of-Concept für nicht authentifizierte SQL-Injection zu RCE in WordPress (CVE-2026-63030 + CVE-2026-60137), mit Docker-Labor und detaillierter Exploit-Chain-Dokumentation.
WordPress Core hat wp2shell am 2026-07-17 als kritische, nicht authentifizierte RCE gemeldet, die Standardinstallationen betrifft (WordPress 6.9.0-6.9.4, 7.0.0-7.0.1, keine Plugins erforderlich). Der ursprüngliche Entdecker (Searchlight Cyber) hat zum Zeitpunkt der Offenlegung technische Details zurückgehalten. Dieses Repository dokumentiert eine unabhängige Ursachenanalyse, die ausschließlich aus dem Vergleich des WordPress-Core-Quellcodes zwischen der anfälligen (6.9.4) und der gepatchten (6.9.5) Version sowie aus Live-Verifikation in einem lokalen Labor stammt.
Hinweis: Die hier gezeigte Reproduktion folgt der Anfrageform von sergiointel/wp2shell-poc, byteweise bestätigt und mit dem tatsächlichen Patch-Diff gegengeprüft.
root_cause_analysis.md - ausführlicher Bericht: die zwei verketteten Fehler, exakter anfälliger Code, der Patch-Diff, die Exploit-Kette und Live-Verifikation vor/nach gegen eine echte WP 6.9.4-Instanz.poc_upstream.py - unveränderte Kopie des ursprünglichen PoC von sergiointel (nur SQLi).poc_upstream_rce.py - sergiointels PoC, aktualisiert etwa 22 Stunden nach Offenlegung, mit nicht authentifizierter Privilegienausweitung und RCE ohne Knacken von Anmeldedaten. Siehe Abschnitt 7 von root_cause_analysis.md.poc_extract.py / poc_extract2.py - eine optimierte Variante (größeres SLEEP(), höherer Zeitmessschwellwert, längere Zeichensuche-Obergrenze), die nötig ist, um ein zuverlässiges Signal in einem Dockerisierten/Proxy-Labor zu erhalten, wo das standardmäßige SLEEP(0.15) des Upstream-Skripts durch Netzwerk-Jitter verloren ging.docker-compose.yml - startet das gleiche WordPress 6.9.4 + MariaDB-Labor, das für die Verifikation verwendet wurde.payload.json, response.json, response_patched.json - eine handgefertigte Anfrage, die die Struktur des PoC und die rohen Serverantworten nachbildet, vor und nach dem Anwenden der 6.9.5-Patch-Dateien.Ein zweiter, unabhängig geschriebener PoC (github.com/Icex0/wp2shell-poc) wurde vollständig überprüft und beschreibt unabhängig denselben Ursachenmechanismus, was die folgende Analyse bestätigt. Mit seiner inhaltsbasierten (booleschen, nicht zeitbasierten) blinden SQLi-Extraktion wurde der Admin-Anmelde-Hash dieses Labors mit 100% Genauigkeit wiederhergestellt. Mit diesem bekannten Anmeldedatum wurde eine vollständige SQLi-zu-RCE-Kette live demonstriert: SQL-Injection → Anmeldeextraktion → authentifizierter Plugin-Upload-Webshell → Codeausführung als www-data. Siehe Abschnitt 6 von root_cause_analysis.md.
Dieser Pfad zum Knacken von Anmeldedaten ist real, aber nicht der einzige. sergiointels PoC wurde anschließend aktualisiert, um nicht authentifizierte RCE ohne jegliches Knacken von Anmeldedaten zu erreichen, indem UNION SELECT verwendet wird, um gefälschte Datenbankzeilen zu erzeugen, denen der eigene Customizer/nav-menu/oEmbed-Cache-Code von WordPress genügend vertraut, um eine nicht authentifizierte Benutzererstellungsanfrage erfolgreich auszuführen. Siehe Abschnitt 7 von root_cause_analysis.md. Die nicht authentifizierte SQL-Injection allein reicht für vollständige RCE auf einer Standardinstallation aus.
CVE-2026-63030 (REST-Batch-Routen-Verwechslung, CWE-436):
WP_REST_Server::serve_batch_request_v1() fügt Einträge per einfachem Push in ein $matches[]-Array ein, überspringt jedoch das Hinzufügen, wenn der Pfad einer Unteranfrage nicht geparst werden kann (z. B. ein absichtlich fehlerhafter Eintrag "http://:"). Diese einzelne Überspringung desynchronisiert $matches[] von $requests[] um einen Index für jeden nachfolgenden Eintrag. Zum Zeitpunkt der Ausführung entspricht $matches[$i] nicht mehr $requests[$i], sodass der Code die Daten einer Anfrage unter einem anderen Routenhandler ausführt als dem, gegen den sie tatsächlich validiert wurde.
CVE-2026-60137 (SQL-Injection):
WP_Query::get_posts() führte die absint()-Bereinigung nur innerhalb eines is_array()-Zweigs auf author__not_in aus. Ein skalarer Zeichenfolgenwert übersprang die Bereinigung vollständig und wurde direkt in ... post_author NOT IN ($value) eingefügt.
Verkettet:
Der Routen-Verwechslungsfehler erlaubt es einem Angreifer, eine Anfrage, die gegen /wp/v2/categories deklariert ist (welches author_exclude nicht erkennt, also nie bereinigt wird), tatsächlich durch den posts-Controller ausführen zu lassen (der author_exclude liest und an WP_Query weiterleitet). Keine Authentifizierung erforderlich.
Zur RCE-Behauptung:
Live bestätigt, dass nicht authentifizierte blinde SQL-Injection funktioniert und beliebige Datenbankinhalte exfiltrieren kann, einschließlich wp_users.user_pass. Ein einzelner zeitbasierter Extraktionsdurchlauf in einem virtualisierten Labor wies erhebliches Bitfehlerrauschen auf (~94% Zeichengenauigkeit in Tests hier); ein inhaltsbasierter (boolescher) Orakel wies diesen Fehlermodus nicht auf und stellte dasselbe Feld mit 100% Genauigkeit wieder her. RCE wurde über zwei verschiedene Pfade bestätigt: Knacken eines wiederhergestellten Passwort-Hashs (abhängig von der Passwortstärke) und eine nicht authentifizierte Privilegienausweitungs-Gadget-Kette unter Verwendung von UNION-gefälschten Datenbankzeilen, denen der eigene Customizer/nav-menu/oEmbed-Cache-Code von WordPress vertraut (bedingungslos, keine Kompromittierung von Anmeldedaten erforderlich). Siehe Abschnitt 7 von root_cause_analysis.md.
docker compose up -d
# wait for WordPress install wizard to be reachable on :8890, then complete setup
HTTP_PROXY=http://127.0.0.1:8080 HTTPS_PROXY=http://127.0.0.1:8080 \
python3 poc_extract2.py http://localhost:8890 "SELECT DATABASE()"
Siehe root_cause_analysis.md für die vollständige technische Dokumentation.
WordPress hat offizielle Korrekturen veröffentlicht: 6.9.5 und 7.0.2 (7.1 Beta 2 für den Beta-Zweig), veröffentlicht am 17.07.2026. Aktualisieren Sie sofort, wenn Sie eine betroffene Version ausführen. Dieses Repository wird zu Verteidigungs- und Bildungszwecken veröffentlicht, nachdem der Patch bereits öffentlich war. Führen Sie den Code hier nur gegen Systeme aus, die Ihnen gehören oder für die Sie ausdrücklich autorisiert sind, Tests durchzuführen.