PoC-Detektor & sicherer Validator für die WP2Shell-WordPress-Schwachstellenkette: CVE-2026-63030 (REST batch-route confusion) + CVE-2026-60137 (author__not_in SQL injection). Nur für autorisierte Sicherheitstests.
CVE-Abdeckung: CVE-2026-63030 und CVE-2026-60137 Verwendungszweck: Autorisierte Sicherheitstests, defensive Validierung und nur temporäre lokale Labore
WP2Shell ist eine WordPress-Core-Verwundbarkeitskette, die einen Pre-Authentifizierung-REST-API-Batch-Route-Confusion-Bug (CVE-2026-63030) mit einer WP_Query-author__not_in-SQL-Injection-Primitive (CVE-2026-60137) kombiniert. Dieses Repository bietet einen Python-Proof-of-Concept-Scanner und sicheren Validator, damit Verteidiger betroffene WordPress-Installationen identifizieren, das verwundbare Verhalten in einem isolierten Labor bestätigen und die Abhilfe überprüfen können – ohne Daten extrahieren oder Code ausführen zu müssen.
Dieses Projekt identifiziert WordPress-Installationen und validiert die beiden Verwundbarkeitsprimitive der WP2Shell WordPress-Core-Verwundbarkeitskette:
WP_Query::author__not_in, die zu SQL-Injection führen kann, wenn angreiferkontrollierte Eingabe den Parameter erreicht.Wenn beide Bedingungen vorliegen, kann eine nicht authentifizierte Anfrage über den REST-API-Batch-Endpunkt die verwundbare SQL-Konstruktion erreichen. Öffentliche Advisories beschreiben die kombinierte Auswirkung als potenziell zur Remote-Code-Ausführung führend.
Dieses Repository sollte nur auf Systemen verwendet werden, die Ihnen gehören oder für die Sie ausdrücklich zur Prüfung autorisiert sind. Bevorzugen Sie ein isoliertes Docker- oder Virtual-Machine-Labor, das an 127.0.0.1 gebunden ist.
Die aktuelle Quelldatei enthält zustandsändernde Funktionalität, einschließlich Datenbank-Datenextraktionsversuche, Dateischreibversuche, Authentifizierungsabläufe, Administratorerstellung, Plugin-Upload und Befehlsausführung.
Betroffene WordPress-Versionen können die Ausrichtung zwischen internen Arrays verlieren, die zur Verfolgung von verwendet werden:
Wenn ein fehlerhaftes Batch-Mitglied in ein internes Array aufgenommen wird, aber nicht in ein anderes, können spätere Anfragen dem falschen Handler zugeordnet werden. Eine Anfrage kann daher als eine Route validiert, aber mit dem Callback einer anderen Route ausgeführt werden.
Sicherheitsauswirkungen:
author__not_in SQL-InjectionDie betroffene WP_Query-Implementierung normalisiert author__not_in nicht konsistent, bevor es zur Konstruktion einer SQL NOT IN (...)-Bedingung verwendet wird.
Der Parameter erwartet normalerweise eine Liste von Integer-Autor-IDs. Wenn ein skalarer String die verwundbare Abfragekonstruktion ohne die beabsichtigte REST-Schema-Validierung erreicht, kann unsichere SQL-Struktur in die Datenbankabfrage gelangen.
Sicherheitsauswirkungen:
| WordPress-Branch | Betroffen | Behobene Version |
|---|---|---|
| 6.8.x | CVE-2026-60137 nur: 6.8.0–6.8.5 | 6.8.6 |
| 6.9.x | Beide Probleme: 6.9.0–6.9.4 | 6.9.5 |
| 7.0.x | Beide Probleme: 7.0.0–7.0.1 | 7.0.2 |
| 7.1 Vorabversion | Beta 1 betroffen | Beta 2 |
| Älter als 6.8 | Nicht von diesen beiden CVEs betroffen | N/A |
WordPress veröffentlichte am 17. Juli 2026 Korrekturen und aktivierte erzwungene automatische Updates für betroffene Installationen aufgrund des Schweregrads.
Unauthenticated client | v WordPress REST batch endpoint | v Malformed batch member creates request/handler misalignment | v Later request is validated against one route but dispatched using another route's handler | v Scalar author_exclude reaches WP_Query as author__not_in | v Unsafe value reaches SQL NOT IN (...) construction | v Blind SQL timing or Boolean oracle | v Potential database compromise | v Potential application-level compromise and RCE
Der Detektor sollte nach der Bestätigung der Route-Confusion- und SQL-Injection-Primitive stoppen. Es muss keine Daten extrahieren oder Befehle ausführen, um festzustellen, dass eine betroffene Installation verwundbar ist.
---
## Erkennungsablauf
### Phase 1 — Ziel normalisieren
Das Tool:
1. Fügt ein standardmäßiges `http`- oder `https`-Schema hinzu, falls fehlend.
2. Normalisiert den WordPress-Installationspfad.
3. Lehnt nicht unterstützte URL-Schemata und eingebettete Anmeldedaten ab.
4. Wendet Weiterleitungs-, Proxy-, TLS- und Zeitüberschreitungsrichtlinien an.
### Phase 2 — WordPress identifizieren
Der Scanner prüft auf:
- `wp-content/`-Referenzen.
- `wp-includes/`-Referenzen.
- WordPress-Generator-Metadaten.
- REST-API-Erkennungslinks.
- WordPress-REST-Indexstruktur.
- Den `wp/v2`-Namespace.
- Optionale Feed- und `readme.html`-Fingerabdrücke.
### Phase 3 — Version ermitteln
Versionsnachweise können aus folgenden Quellen stammen:
- HTML-Generator-Metadaten.
- Feed-Generator-Metadaten.
- WordPress-Core-Asset-Abfragezeichenfolgen.
- HTTP-Generator-Header.
- `readme.html`.
- Eine lokale `wp-includes/version.php`-Datei.
Nachweise werden bewertet und abgeglichen. Widersprüchliche Remote-Versionsanzeigen senken die Vertrauenswürdigkeit.
### Phase 4 — Batch-Route-Exposition prüfen
Der Scanner versucht, `/batch/v1` zu entdecken durch:```text
/?rest_route=/
/wp-json/
Die Route kann entweder über folgende(n) Weg(e) adressiert werden:```text /?rest_route=/batch/v1 /wp-json/batch/v1
### Phase 5 — Sichere Route-Confusion-Sonde
Die sichere Sonde enthält:
1. Einen absichtlich fehlerhaften internen Pfad.
2. Eine Anfrage an eine ungültige Post-ID mit einer harmlosen verschachtelten öffentlichen `GET`-Anfrage.
3. Eine darauffolgende `/batch/v1`-Anfrage.
Ein anfälliger Server gibt eine äußere `207 Multi-Status`-Antwort zurück, in der die ungültige Post-Anfrage als eine verschachtelte Batch-Anfrage verarbeitet wird.
Der Detektor meldet:```text
route-confusion-observed
wenn es folgendes sieht:
parse_path_failed-Marker.207.responses-Array, das zeigt, dass die harmlose interne Anfrage ausgeführt wurde.