
Proof-of-Concept-Exploit für CVE-2026-63030 (WordPress pre-auth RCE) mit SQL-Injection-Erkennung, Extraktion von Anmeldedaten und Bereitstellung von Webshells. Enthält einen 8-stufigen Exploit-Workflow und eine Behebungsanleitung.
📖 Lesen Sie zuerst die vollständige technische Analyse: CVE-2026-63030: WordPress Pre-Auth RCE Explained
Dieses Repository enthält den Proof-of-Concept-Exploit, auf den in diesem Artikel verwiesen wird. Beginnen Sie mit dem Blog, um die Schwachstelle, Einschränkungen und den Reproduktionsprozess zu verstehen.
| Aspekt | Details |
|---|---|
| Schwachstelle | CVE-2026-63030 (Routenkonfusion) + CVE-2026-60137 (SQL-Injection) |
| Typ | Pre-Authentifizierung Remote Code Execution |
| CVSS-Score | 9.8 (Kritisch) |
| Betroffene Versionen | WordPress 6.9.0–6.9.4, 7.0.0–7.0.1 |
| Behoben in | WordPress 6.9.5, 7.0.2+ |
| Auswirkungen | 500M+ WordPress-Websites potenziell betroffen |
| Voraussetzungen | Keine – funktioniert auf Standard-WordPress-Installationen |
Dieses Repository enthält:
wordpress-rest-exploit.py — Einzeldatei Python-Exploit-Tool (1.005 Zeilen, keine Abhängigkeiten)README.md — Diese Datei mit Einrichtung und VerwendungPOC.md — Ausführliche Schritt-für-Schritt-Reproduktionsanleitung mit echten BeispielenLICENSE — MIT-LizenzBevor Sie diesen Exploit verwenden, verstehen Sie die kritische Einschränkung, die diese Schwachstelle von dem unterscheidet, wie sie berichtet wurde:
Die Schwachstellenkette ist real und kritisch. Allerdings:
Warum? WordPress erlaubt benutzerdefinierte Datenbanktabellen-Präfixe. Standard ist wp_, aber die meisten sicherheitsgehärteten Seiten verwenden bw1w_, wordpress_ oder zufällige Zeichenfolgen. Ohne Kenntnis des Präfixes schlägt die Hashextraktion stillschweigend fehl.
Der Blog-Artikel erklärt:
./wordpress-rest-exploit.py
Das Tool führt Sie durch:
CVE-2026-63030: WordPress REST Batch Route-Confusion SQLi
------------------------------------------------------------
Target URL: https://example.com/
[*] Checking if target is vulnerable to CVE-2026-63030...
[+] WordPress 7.0 detected (AFFECTED VERSION)
[+] VULNERABLE - batch route-confusion behavior confirmed
What would you like to do?
1) Read database fingerprint
2) Extract WordPress user logins and password hashes
3) Execute custom SQL query
4) Deploy plugin webshell (requires admin credentials)
5) Confirm SQL injection with timing payload
6) Exit
Select option [1]:
Dies ist wichtig, um es vor der Verwendung des Exploits zu verstehen.
WordPress erlaubt benutzerdefinierte Datenbanktabellen-Präfixe zur Sicherheitshärtung. Das Exploit-Tool kann das Präfix nicht automatisch erkennen.
✅ Default prefix (wp_): Exploitation works
❌ Custom prefix (bw1w_, etc.): Exploitation fails silently
Wenn das Tool nach dem Tabellenpräfix fragt:
Option 1: Sie kennen das Präfix
Database table prefix [wp_]: bw1w_
[*] Querying bw1w_users...
[*] Found credentials!
Option 2: Häufige Präfixe erraten
wp_ (Standard)wordpress_bw1w_ (beliebte Härtung)wpdb_Option 3: Direkter Zugriff
Wenn Sie SSH-Zugriff haben oder wp-config.php lesen können:
$table_prefix = 'bw1w_'; // Gefunden!
Option 4: Brute-Force via SQLi Das Tool kann häufige Präfixe durch Blind-SQL-Injection versuchen (langsam aber möglich).
SLEEP(3)-Payloadwp_users-Tabelle abfragen (oder benutzerdefiniertes Präfix)Für eine detaillierte Reproduktion mit tatsächlicher Befehlsausgabe und Beispielen siehe:
👉 POC.md — Vollständige 8-Stufen-Anleitung
Diese Anleitung enthält:
Sofort aktualisieren (höchste Priorität):
# Auf gepatchte Versionen aktualisieren
WordPress 7.0.2 or 6.9.5
Wenn kein sofortiges Update möglich ist:
Batch-Endpunkt am WAF/Reverse-Proxy blockieren:
Block: /wp-json/batch/v1
Block: /?rest_route=/batch/v1
Oder REST-API vollständig deaktivieren (weniger ideal):
// Zu wp-config.php oder mu-plugins hinzufügen
add_filter('rest_endpoints_enabled', '__return_false');
Oder Authentifizierung erzwingen:
add_filter('rest_pre_dispatch', function($response) {
if (strpos($_SERVER['REQUEST_URI'], '/batch/v1') !== false) {
if (!is_user_logged_in()) {
return new WP_Error('rest_batch_unauthenticated', 'Forbidden', ['status' => 401]);
}
}
return $response;
}, 10, 1);
Nur für autorisierte Sicherheitstests. Ausschließlich gegen Systeme verwenden, die Sie besitzen oder für die Sie ausdrückliche schriftliche Erlaubnis zum Testen haben. Es wird keine Garantie übernommen und keine Haftung für Missbrauch akzeptiert.
Forschung & Entwicklung: Easin Arafat
GitHub: @mrx-arafat
Website: arafatops.com
Dieser Proof-of-Concept demonstriert die WordPress wp2shell-Schwachstellenkette mit praktischen Ausnutzungstechniken, Schwachstellenerkennung und Ergebnissen aus realen Tests. Beginnen Sie mit dem Blog-Artikel, um den vollständigen Kontext zu verstehen.
Zuletzt aktualisiert: Juli 2026
Lizenz: MIT
| Erkenntnis | Auswirkung |
|---|
| Schwachstellenerkennung funktioniert einwandfrei | Einfach betroffene Seiten zu identifizieren |
| SQL-Injection ist zuverlässig | Datenbankzugriff ist garantiert (wenn Präfix bekannt) |
| Tabellenpräfix ist der Engpass | 70 % der Produktionsseiten sind geschützt |
| Blind-SQLi ist langsam | 30+ Minuten für vollständige Extraktion |
| Post-Auth RCE funktioniert nahtlos | Vollständige Systemkompromittierung nach Authentifizierung |
| Pre-Auth RCE nicht offengelegt | Searchlight Cyber hat die Technik nicht veröffentlicht |