php2shell
Menü

WordPress nach PHP2Shell gehackt? Das prüfen Sie jetzt

Checkliste bei Verdacht auf einen Einbruch: Anzeichen, Prüfungen mit WP-CLI, Eindämmung, Aufräumen in der richtigen Reihenfolge und wann Sie Fachleute holen.

Zuerst lesen

Sicherheitsanbieter wie Cloudflare, watchTowr und Patchstack melden Angriffsversuche auf die PHP2Shell-Lücken. CISA, BSI und CERT-EU haben eine Ausnutzung bisher nicht bestätigt, und die Lücke stand am 21. Oktober nicht im KEV-Katalog der CISA (Known Exploited Vulnerabilities). Ein Einbruch auf Ihrer Seite ist also möglich, aber nicht belegt. Diese Seite hilft Ihnen beim Nachsehen.

Ein Angriff auf ein verwundbares PHP kann passieren, bevor WordPress-Code läuft. Die Logs von WordPress und PHP zeigen dann womöglich nichts. Arbeiten Sie die Prüfungen unten ab und behalten Sie dabei eine Regel im Kopf.

Keine Funde heißt nicht sauber

Jede dieser Prüfungen kann etwas übersehen. Die Prüfsummen-Werkzeuge kennen nur Dateien von wordpress.org. Wer den nötigen Zugriff hat, kann Logs ändern, Dateien verstecken oder eine Hintertür in der Datenbank ablegen. Finden Sie nichts, haben aber weiter Grund zum Zweifel, behandeln Sie die Seite als kompromittiert, bis Fachleute etwas anderes sagen.

Falls PHP noch nicht aktualisiert ist, erledigen Sie das zuerst oder parallel. Wer eine Seite aufräumt, die weiter auf einem verwundbaren PHP läuft, lädt den nächsten Einbruch ein. Siehe PHP-Version prüfen und PHP-Version ändern.

Anzeichen eines Einbruchs

Benutzerkonten

  • Administratoren, die Sie nicht kennen, oder ein Konto, das am 21. Oktober oder später angelegt wurde.
  • Anwendungspasswörter, die Sie nicht angelegt haben. Im Dashboard unter Benutzer > Profil nach unten bis Anwendungspasswörter scrollen. Damit meldet sich ein Skript ohne Ihr Passwort an der REST-API an, und diese Passwörter bleiben auch nach einer Passwortänderung gültig.
  • Geänderte E-Mail-Adressen bei bestehenden Admin-Konten.
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
wp user application-password list <user-id>

Den zweiten Befehl führen Sie für jeden Benutzer aus, nicht nur für Admins.

Core- und Plugin-Dateien

wp core verify-checksums --include-root
wp plugin verify-checksums --all

Der erste Befehl vergleicht die Core-Dateien mit den offiziellen Prüfsummen. Mit --include-root warnt er auch vor Dateien im Hauptverzeichnis, die nicht zu WordPress gehören. Der zweite tut dasselbe für Plugins, allerdings nur für solche, die auf wordpress.org liegen. Premium-Plugins und Eigenentwicklungen lassen sich so nicht prüfen. Vergleichen Sie diese mit einem frischen Download vom Anbieter.

Eine Datei mit Abweichung ist ein Hinweis, dem Sie nachgehen. Manche Hoster und Cache-Werkzeuge legen absichtlich Dateien an, sehen Sie sich also jede einzeln an, bevor Sie urteilen.

PHP-Dateien, die dort nichts verloren haben

In uploads gehören Bilder, Dokumente und Medien. PHP gehört nicht dorthin.

find wp-content/uploads -type f \( -name '*.php' -o -name '*.phtml' -o -name '*.phar' \)
find . -type f -name '*.php' -mtime -7 -not -path './wp-content/cache/*'

Der zweite Befehl listet PHP-Dateien, die in den letzten sieben Tagen geändert wurden. Auch Updates erzeugen Treffer. Achten Sie deshalb auf Pfade und Namen, die Sie nicht erwarten.

Plugins, die Sie nicht installiert haben

ls -la wp-content/mu-plugins wp-content/object-cache.php wp-content/advanced-cache.php wp-content/db.php

Must-Use-Plugins in mu-plugins laden bei jeder Anfrage und fehlen in der normalen Plugin-Liste. Viele Seiten haben keine. Die anderen drei Dateien sind Drop-ins. Nutzen Sie weder Object Cache noch Seiten-Cache noch eine eigene Datenbankschicht, sollten sie nicht existieren.

Geplante Aufgaben

wp cron event list

Suchen Sie nach Hooks, die zu keinem Ihrer Plugins gehören, nach auffälligen Namen und nach Ereignissen, die jede Minute laufen.

PHP- und Server-Konfiguration

Angreifer mögen Einstellungen, die bei jeder Anfrage Code ausführen, ohne eine WordPress-Datei anzufassen.

find . -name .htaccess -o -name .user.ini | xargs ls -la
grep -rn 'auto_prepend_file\|auto_append_file' . --include=.htaccess --include=.user.ini

Eine Zeile mit auto_prepend_file oder auto_append_file, die Sie nicht selbst gesetzt haben, ist ein Alarmzeichen. Sehen Sie auch in den PHP-Einstellungen Ihres Hosting-Panels nach, denn dort lässt sich der Wert ebenfalls setzen.

Weitere Anzeichen

  • Besucher berichten von Weiterleitungen, Werbung oder Seiten, die Sie nie veröffentlicht haben.
  • In den Suchergebnissen tauchen Spam-Seiten unter Ihrer Domain auf.
  • Ihr Hoster schickt eine Missbrauchsmeldung oder sperrt die Seite.
  • Ihr Mailserver verschickt Massen-Mails, die Sie nicht ausgelöst haben.
  • Unerklärliche Spitzen bei CPU-Last, Traffic oder ausgehenden Verbindungen.

Was Sie bei einem Fund tun

Gehen Sie in dieser Reihenfolge vor.

  1. Eindämmen. Schalten Sie den Wartungsmodus ein oder nehmen Sie die Seite beim Hoster oder per DNS vom Netz. Verarbeitet die Seite Zahlungen oder personenbezogene Daten, ist das dringend.

  2. Beweise sichern. Kopieren Sie vor jedem Löschen die ganze Seite (Dateien und Datenbank) sowie die Server-Logs an einen Ort außerhalb des Servers. Ändern Sie die Kopie nicht. Ein Dienstleister für Incident Response, Ihre Versicherung oder eine Datenschutzbehörde kann sie verlangen.

  3. PHP aktualisieren. Wechseln Sie auf einen behobenen Build: 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 bzw. neuer. Wir empfehlen PHP 8.4.

  4. Alle Zugangsdaten ändern. Neue Passwörter für alle WordPress-Benutzer, den Datenbank-Benutzer (und DB_PASSWORD in der wp-config.php), das Hosting-Panel, SFTP- und SSH-Konten sowie alle API-Schlüssel, die in der Seite hinterlegt sind. Erledigen Sie das von einem Gerät, dem Sie vertrauen.

  5. Anwendungspasswörter widerrufen. Löschen Sie die, die Sie nicht erklären können, oder gleich alle:

    wp user application-password delete <user-id> --all

  6. Salts erneuern. Das meldet alle Sitzungen ab, auch die eines Angreifers.

    wp config shuffle-salts

  7. Aus sauberen Quellen neu installieren. Holen Sie Core und Plugins frisch von wordpress.org oder vom Anbieter. Verwenden Sie keine Dateien aus alten Backups:

    wp core download --force --skip-content
wp plugin install <plugin-slug> --force

    Die Neuinstallation ersetzt nur Dateien. Ihre Uploads, mu-plugins, Drop-ins, .htaccess, die Datenbank sowie die gefundenen Konten und Cron-Ereignisse bleiben unberührt. Diese entfernen Sie von Hand.

  8. Backups mit Vorsicht einspielen. Ein Backup ist nur sauber, wenn es vor dem Einbruch entstand, und den Zeitpunkt kennen Sie vielleicht nicht. Spielen Sie ein Backup ein, wiederholen Sie darauf alle Prüfungen.

  9. Weiter beobachten. Wiederholen Sie die Prüfungen nach einem Tag und nach einer Woche.

Wann Sie Fachleute für Incident Response holen

Holen Sie professionelle Hilfe, wenn einer dieser Punkte zutrifft:

  • Sie haben eine Hintertür, ein fremdes Admin-Konto oder eine unerwartete PHP-Datei gefunden.
  • Die Seite verarbeitet Zahlungen, Gesundheitsdaten oder andere personenbezogene Daten. Dann können Meldepflichten bei einer Datenpanne gelten, und die Regeln unterscheiden sich je nach Land.
  • Mehrere Seiten laufen im selben Konto oder auf demselben Server. Ein Einbruch kann die anderen erreichen.
  • Sie können nicht sicher sagen, wann die Seite zuletzt sauber war.
  • Die Prüfungen blieben ohne Ergebnis, aber etwas stimmt weiter nicht.

Wir machen keine Forensik und nennen bislang keinen bestimmten Dienstleister. Worauf Sie bei der Auswahl achten, steht unter Empfehlungen. Verlangen Sie einen schriftlichen Leistungsumfang, eine Liste der Ergebnisse, die Sie bekommen, und eine klare Aussage, wer die Beweise aufbewahrt.

Eine schnelle Einordnung Ihrer Lage bietet die Einschätzung. Was Ihr Server tatsächlich ausführt, zeigt die Versionsprüfung.

Zuletzt geprüft am 22. Oktober 2026.