wp2shell-scan

Erkennen und bereinigen Sie wp2shell (CVE‑2026‑63030) Kompromittierungen auf einer oder vielen WordPress-Sites.

wp2shell ist die Sicherheitslücke zur Remote-Codeausführung ohne Authentifizierung, die in WordPress 7.0.2 / 6.9.5 / 6.8.6 (2026‑07‑17) behoben wurde. Innerhalb eines Tages erschien ein öffentlicher PoC, und die Massenausnutzung folgte innerhalb von ~48 Stunden. Ein Patch schließt das Loch – aber eine Site, die vor dem Patchen ausgenutzt wurde, ist bereits kompromittiert, und ein Update entfernt die Persistenz des Angreifers nicht.

Dieses Tool findet und entfernt diese Persistenz. Es ist ein einzelnes, abhängigkeitsarmes Bash-Skript, das standardmäßig schreibgeschützt läuft und Tausende von Sites in einem Durchgang scannen kann.

⚠️ Dies ist defensive Werkzeugsoftware. Es enthält keinen Exploit-Code. Erstelle einen Snapshot einer Site, bevor du --clean ausführst.

Was das Tool erkennt

Nach der Ausnutzung hinterlässt wp2shell-Tooling typischerweise zwei Persistenz-Artefakte, die dieses Tool beide findet:

1. Einen Schatten-Administrator – mehrere Varianten wurden gesehen: user_login = wpsvc_<hex> / wp2_<hex> / w2s_<hex>, oder eine E-Mail auf einer Angreiferdomain (@wp2shell.*, @shellcode.*, @wordpress-svc.internal, @wordpress-noreply.net, @x.lol), mit der Rolle administrator. (Hinweis: @system.local ist eine legitime Platzhalter-Admin-E-Mail auf einigen verwalteten Hosts – sie wird bewusst nicht als IOC behandelt.)
2. Eine Webshell, die als Plugin getarnt ist – wp-content/plugins/<plausible-name>-<6hex>/<same>.php: eine winzige (~1,3 KB) PHP-Datei mit einem gefälschten Author: WordPress.org Community-Header, die hinter einem Token abgesichert ist und eine ?c=<command>-Schnittstelle bereitstellt.

Es erkennt auch den allgemeinen Fall: jede kleine PHP-Datei unter wp-content/, die $_GET['c'] in eine Befehls-/Eval-Senke leitet.

Installation

curl -fsSLO https://raw.githubusercontent.com/InstaWP/wp2shell-scan/main/wp2shell-scan.sh
chmod +x wp2shell-scan.sh

Erfordert bash, find, grep und einen mysql/mariadb-Client. WP‑CLI wird verwendet, falls vorhanden (sauberere Benutzerlöschung), ist aber nicht erforderlich – die Webshell-Erkennung benötigt überhaupt keine Datenbank.

Verwendung

# Scan ONE site (read-only)
./wp2shell-scan.sh --path /var/www/example.com

# Scan EVERY WordPress install under a base directory (bulk)
./wp2shell-scan.sh --base /var/www
./wp2shell-scan.sh --base /home            # shared hosting

# Auto-detect common layouts (/var/www/*, /home/*/public_html, ...)
./wp2shell-scan.sh

# Machine-readable
./wp2shell-scan.sh --base /var/www --json > report.json

# CLEAN — quarantine + remove backdoors, rotate wp-config salts (logs everyone out)
./wp2shell-scan.sh --base /var/www --clean --yes

# Vet a BACKUP / SNAPSHOT / TEMPLATE dump before restoring it (see warning below)
./wp2shell-scan.sh --sql /path/to/backup.sql

Entfernte Artefakte werden in ein Quarantäneverzeichnis verschoben (nicht endgültig gelöscht), damit du Beweise behältst. Der Exit-Code ist 1, wenn eine Kompromittierung gefunden (Scan) oder bereinigt (Clean) wurde, 0, wenn alles sauber ist – praktisch für Cron/CI.

Beispielausgabe

[COMPROMISED] /var/www/example.com  — 2 backdoor admin(s), 2 webshell(s)
      admin: ID=41 wpsvc_2e1487df8abb <[email protected]> (2026-07-19 06:41:48)
      webshell: .../wp-content/plugins/security-headers-manager-8d1d21/security-headers-manager-8d1d21.php
[clean] /var/www/other-site.com
----------------------------------------------------------------
scanned=812  clean=811  compromised=1  cleaned=0

⚠️ Vergiss deine Backups, Snapshots und Templates nicht

Das Bereinigen einer Live-Site bereinigt deine Backups NICHT. Ein Backup, Snapshot oder Staging-/Blueprint-Template, das während der Kompromittierung der Site erstellt wurde, enthält weiterhin das Admin-Konto des Angreifers – die Wiederherstellung (oder die Bereitstellung einer neuen Site daraus) infiziert sofort erneut. Das haben wir auf die harte Tour gelernt: Nachdem wir jede betroffene Live-Site bereinigt hatten, tauchten immer wieder brandneue Sites mit der Hintertür auf, weil sie aus einem vergifteten Template-Snapshot bereitgestellt wurden.

Prüfe einen Dump, bevor du ihn wiederherstellst:

./wp2shell-scan.sh --sql /path/to/backup.sql
./wp2shell-scan.sh --sql backup1.sql --sql backup2.sql.gz   # repeatable, .gz supported

Der Exit-Code ist 1, wenn ein Dump vergiftet ist. Falls das der Fall ist: Stelle ihn nicht wieder her – bereinige zuerst die Live-Site, erstelle dann ein frisches Backup und lösche/ersetze jeden Snapshot oder jedes Template, das während deines Gefährdungszeitraums erstellt wurde.

Nach der Bereinigung

--clean entfernt den Admin + die Webshell und rotiert die Salts. Du musst außerdem:

1. WordPress-Core auf 7.0.2 / 6.9.5 / 6.8.6 aktualisieren (der eigentliche Fix).
2. Alle Admin-Passwörter zurücksetzen und Core + Plugins neu installieren/verifizieren (wp core verify-checksums).
3. Alle Geheimnisse rotieren, die die Site lesen konnte – DB-Passwort, API-Keys, SMTP-Zugangsdaten – geh davon aus, dass sie geleakt sind.
4. Überprüfen, was die Shell ausgeführt hat – deine Access-Logs protokollieren die Werte der ?c=-Befehle.
5. Blockiere die Batch-Route an deinem Edge/Origin, bis jede Site gepatcht ist (/wp-json/batch/v1, ?rest_route=/batch/v1, einschließlich %2f-kodiert). Platziere die Regel am Origin, falls ein CDN den REST-Pfad durchwinken könnte.

Manuelle Prüfung (ohne Tool)

Schatten-Administratoren:

SELECT u.ID,u.user_login,u.user_email,u.user_registered
FROM wp_users u JOIN wp_usermeta m ON u.ID=m.user_id
WHERE m.meta_key='wp_capabilities' AND m.meta_value LIKE '%administrator%'
ORDER BY u.user_registered DESC;

Webshell-Plugins:

find wp-content/plugins -maxdepth 1 -type d -regextype posix-extended -regex '.*-[0-9a-f]{6}$'
grep -rl "\$_GET\['c'\]" wp-content/plugins/

Bevorzugst du einen KI-Agenten?

Siehe CLEANUP-WITH-CLAUDE.md für einen direkt einfügbaren Prompt, der Claude Code (oder jeden anderen leistungsfähigen Coding-Agenten) durch dieselbe Erkennung und Bereinigung auf einer einzelnen Site führt, mit menschlicher Bestätigung vor jedem destruktiven Schritt.

Lizenz

MIT – siehe LICENSE. Bereitgestellt wie besehen, ohne Gewährleistung. Entwickelt und in einem echten Incident praxiserprobt vom Team bei InstaWP.