wp2shell — Pre-Auth RCE in WordPress Core

Nicht authentifizierte WordPress Core RCE PoC, die CVE-2026-63030 + CVE-2026-60137 verkettet. Nur für autorisierte Tests.

wp2shell.py ist ein Proof-of-Concept, bestehend aus einer einzigen Datei, das ausschließlich die Standardbibliothek nutzt und zwei WordPress-Core-Sicherheitslücken zu einer nicht authentifizierten Remote-Code-Ausführung verkettet:

Keiner der beiden Fehler allein führt zu RCE. Der Desync ist die Zustellung (er schmuggelt eine Angreiferzeichenfolge in eine Abfrage, die sie nie erreichen sollte); die Injection ist die Grundlage. Zusammen ergeben sie für einen nicht authentifizierten Angreifer ein vollständiges SQL-Lese-/Schreib-Orakel und daraus eine funktionierende Shell.

⚠️ Nur für autorisierte Tests. Dieses Tool nutzt Live-WordPress-Installationen aus. Verwenden Sie es nur gegen Systeme, die Sie besitzen oder für die Sie eine explizite schriftliche Genehmigung zum Testen haben.

Betroffene Versionen

Verwundbar: 6.8.0–6.8.5, 6.9.0–6.9.4, 7.0.0–7.0.1 Gepatched: 6.8.6, 6.9.5, 7.0.2 (und später) Gemeldet von Adam Kues (Assetnote / Searchlight Cyber); SQLi auch TF1T, dtro, haongo zugeschrieben.

Nur 6.9.0–7.0.1 sind RCE-fähig. In der 6.8.x-Reihe tritt der Desync immer noch auf, aber der Zweig, der den Handler verschieben würde, trifft auf einen WP_Error::get_method()-Fatal – daher ist 6.8.x ein Denial-of-Service/Absturz, keine Shell. Das Tool erkennt dies und gibt an, welche Grundlage verfügbar ist.

Wie die Kette funktioniert

Der Exploit ist schichtweise aufgebaut; jede Schicht ist eine Brücke zur nächsten.

1. Desync (CVE-2026-63030). Ein Batch-Request verschachtelt einen zweiten Batch. Ein Sub-Request trägt einen absichtlich fehlerhaften Pfad (http://:, den wp_parse_url() ablehnt). Ab 6.9.0+ führt der fehlgeschlagene Parse dazu, dass die Handler- und Validierungstabellen um einen Eintrag abweichen, sodass der nächste Sub-Request unter einem Handler läuft, für den er nie validiert wurde – der öffentliche Beitragssammlung.

2. Injection (CVE-2026-60137). Dieser fehlgeleitete Aufruf erreicht WP_Query mit einem vom Angreifer kontrollierten author__not_in. Ein UNION ALL SELECT dort liest keine Zeilen – es erfindet sie, sodass wir beliebige Beiträge im Abfrageergebnis fälschen können.

3. SQL → Schreibbrücke. Die gefälschten Beiträge enthalten [embed]-Markup. WordPress löst diese getreulich auf und speichert sie als echte oembed_cache-Beitrags-Meta-Zeilen zwischen – eine schreibgeschützte Injection wird so zu einer beliebigen Schreib-Grundlage.

4. Rechteerweiterung. Mit dieser Schreibbrücke fälschen wir (a) ein Customizer-Changeset, das als echter Administrator verfasst ist, und (b) einen selbstreferenziellen request-Beitrag. Zusammen zwingen sie WordPress, seine eigene Request-Pipeline als dieser Admin erneut auszuführen – ein Fenster, das gerade lang genug ist, damit ein in die Warteschlange gestellter -Aufruf einen neuen Administrator erstellt.

Extraktions-Orakel

Für die Lese-Seite (--dump, Prefix-Auflösung, gecachte IDs) wählt das Tool automatisch das schnellste Orakel aus, das funktioniert, und hält beim ersten Treffer an:

1. union – In-Band-UNION: Der post_title des gefälschten Beitrags enthält |||HEX(wert)|||, was unverändert im /wp/v2/posts-Antwortkörper zurückgespiegelt wird. Liest einen gesamten Wert (beliebige Länge) in einer Anfrage. Wenn UNION reflektiert, werden die booleschen Orakel nie getestet.
2. bool – Boolesches X-WP-Total-Orakel: Der X-WP-Total-Header der verwirrten Sub-Antwort ist count>0 für true / 0 für false. Ein Bit pro Request (Bisektion).
3. time – Zeitbasiertes SLEEP(): Der Fallback, wenn der Körper entfernt und die Antwort ein 500 ist (z. B. ein Post-Dispatch-Fatal von einem Caching-mu-Plugin). Funktioniert auch bei Zielen, die bei jedem REST-Aufruf abstürzen.

--dump verwendet GROUP_CONCAT, um den gesamten Berechtigungssatz auf einmal zu ziehen, wenn UNION verfügbar ist.

Installation

Keine. Nur Python 3.7+ Standardbibliothek – kein pip install.

chmod +x wp2shell.py

Verwendung

# 1. Ist es verwundbar? (keine Injection, keine Schreibvorgänge, kein Konto erstellt)
./wp2shell.py http://ziel --check

# 2. Schreibgeschützter Credential-Dump – ERSTER Administrator + Options-Geheimnisse
./wp2shell.py http://ziel --dump

#    …jeder Administrator
./wp2shell.py http://ziel --dump all

# 3. Vollständiges RCE – temporären Admin erstellen, Befehl ausführen, bereinigen
./wp2shell.py http://ziel --exec "id; uname -a"

Schreibgeschützte Reconnaissance (keine Admin-Erstellung, umgeht 2FA)

./wp2shell.py http://ziel --user-list          # vollständige Benutzertabelle (Logins/E-Mails/Rollen)
./wp2shell.py http://ziel --content            # jeden Beitragstyp bei status=any (privat/entwurf)
./wp2shell.py http://ziel --content full        #   …einschließlich des rohen Texts jedes Elements

Viele Hosts scannen

./wp2shell.py -f ziele.txt --check --target-threads 8

Optionen

WAF/Härtungs-Umgehung

Hinweise zur Ausgabe

• Passwort-Hashes ($wp$2y$… / $P$… / $2y$…) direkt an hashcat (-m 3200 für phpass oder den WP-bcrypt-Modus). WordPress 6.8+ verwendet $wp$… bcrypt.
• --dump standardmäßig nur den ersten Administrator. Verwenden Sie --dump all für die vollständige Admin-Liste.
• 500-Fehler/Absturz-Ziele: Wenn ein Post-Dispatch-Fatal (z. B. ein Pantheon-artiges Cache-mu-Plugin) jede REST-Antwort in einen 500 verwandelt, funktioniert die Admin-Erstellung nicht, aber Lesevorgänge funktionieren trotzdem – wechseln Sie zu --oracle time --dump, um Hashes wiederherzustellen.

Warum die Bereinigung wichtig ist

Der --exec-Pfad ist so konzipiert, dass er nichts zurücklässt: Der temporäre Administrator, seine Usermeta, die fabrizierten oembed_cache-Zeilen und die hochgeladene Webshell werden alle entfernt, bevor das Tool beendet wird. Es gibt kein --keep-Flag – ein Operator sollte niemals ein lebendiges, von einem Angreifer erstelltes Admin-Konto auf dem System eines Kunden hinterlassen.

Dateien

• wp2shell.py – der Exploit (eine Datei, nur Standardbibliothek).

Danksagungen

Die Entdeckung der Sicherheitslücken, die Offenlegung und die ursprüngliche „wp2shell“-Veröffentlichung gehen auf das Searchlight Cyber / Assetnote-Forschungsteam zurück:

• CVE-2026-63030 – REST /batch/v1 Route-Confusion Desync
• CVE-2026-60137 – WP_Query author__not_in SQL-Injection

Dieses Repository ist eine unabhängige Proof-of-Concept-Implementierung der Exploit-Kette, die sie offengelegt haben; es beansprucht nicht die Entdeckung der zugrunde liegenden Sicherheitslücken. Falls eine Zuordnung unvollständig oder falsch ist, eröffnen Sie bitte ein Issue, und es wird korrigiert.

Referenzen

• Searchlight Cyber / Assetnote — wp2shell: Pre-Authentication RCE in WordPress core https://slcyber.io/research-center/wp2shell-pre-authentication-rce-in-wordpress-core/
• WordPress 7.0.2 Veröffentlichung (Fix) — https://wordpress.org/news/2026/07/wordpress-7-0-2-release/
• Advisories — GHSA-ff9f-jf42-662q, GHSA-fpp7-x2x2-2mjf

Haftungsausschluss

Dies ist ein Proof-of-Concept für Sicherheitsforschung, der für autorisierte Penetrationstests und defensive Validierung bestimmt ist. Der Einsatz gegen Systeme, die Sie nicht besitzen oder für die Sie keine schriftliche Genehmigung zum Testen haben, ist illegal. Der Autor übernimmt keine Haftung für Missbrauch.