WordPress nach einem Hack bereinigen: Vorgehen ohne Datenverlust

Eine gehackte WordPress-Website zeigt sich unterschiedlich: Besucher werden auf fremde Seiten umgeleitet, Google warnt in den Suchergebnissen, der Hoster sperrt das Paket oder im Backend taucht ein Administrator auf, den niemand angelegt hat. In der ersten Aufregung werden oft Dateien gelöscht, Plugins wahllos entfernt oder ein altes Backup eingespielt, das die Lücke gleich wieder mitbringt. Dabei gehen Beweise und oft auch Bestellungen, Formulareingänge oder neue Inhalte verloren. Diese Anleitung beschreibt ein geordnetes Vorgehen: Zustand sichern, Ausmaß feststellen, Core, Plugins und Themes durch saubere Originale ersetzen, Datenbank und Konten prüfen, alle Zugangsdaten erneuern und die Ursache schließen. Die WP-CLI-Befehle und ihre Ausgaben stammen aus einem Test, in dem eine Laborinstanz gezielt mit typischen Spuren manipuliert wurde.

Voraussetzungen

• WordPress: jede Version, für die wordpress.org Prüfsummen bereitstellt. Getestet mit WordPress 7.1.2 auf Deutsch.
• PHP: die auf dem Server installierte Version, im Test PHP 8.4.
• Zugang: SSH mit WP-CLI ist für diese Anleitung sehr hilfreich. Ohne SSH brauchen Sie FTP- oder SFTP-Zugang, Zugriff auf die Datenbank über das Kundenmenü des Hosters und ein Konto mit der Rolle Administrator.
• Backup: ein älteres, sauberes Backup aus der Zeit vor dem Vorfall, falls vorhanden, und Speicherplatz für eine vollständige Kopie des aktuellen, kompromittierten Zustands.
• Sauberer Arbeitsrechner: Laut WordPress-Dokumentation beginnen manche Angriffe mit einem infizierten Rechner, auf dem Zugangsdaten mitgelesen werden. Prüfen Sie Ihren Rechner mit einem aktuellen Virenscanner, bevor Sie neue Passwörter eingeben.

Schritt 1: Zustand sichern und dokumentieren

Die WordPress-Dokumentation zur Frage „My site was hacked“ nennt Dokumentation als ersten praktischen Schritt: Was sehen Sie, seit wann, und was wurde zuletzt geändert, etwa ein neues Plugin oder ein Theme-Update. Diese Notizen helfen Ihnen, dem Hoster und gegebenenfalls einem Dienstleister.

Sichern Sie danach den aktuellen Zustand vollständig, auch wenn er infiziert ist. Er enthält Inhalte und Bestellungen seit dem letzten sauberen Backup und die Spuren des Angriffs. Legen Sie die Kopie getrennt von sauberen Backups ab und kennzeichnen Sie sie eindeutig.

mkdir -p ~/vorfall-$(date +%F)
wp db export ~/vorfall-$(date +%F)/db-kompromittiert.sql
tar -czf ~/vorfall-$(date +%F)/dateien-kompromittiert.tar.gz .

Informieren Sie Ihren Hoster. Er sieht Server-Logs, die Ihnen im Webhosting meist fehlen, und kann feststellen, ob andere Kunden oder der Mailversand betroffen sind. Setzen Sie die Website für die Dauer der Bereinigung in den Wartungsmodus, damit Besucher nicht weiter auf Schadseiten geleitet werden:

wp maintenance-mode activate

Können personenbezogene Daten betroffen sein, etwa Kundenkonten oder Formulareingänge, prüfen Sie die Meldepflicht nach Art. 33 DSGVO. Die Meldung an die Aufsichtsbehörde ist unverzüglich und möglichst binnen 72 Stunden nach Bekanntwerden fällig, es sei denn, die Verletzung führt voraussichtlich nicht zu einem Risiko für die Betroffenen. Beziehen Sie Ihren Datenschutzbeauftragten früh ein.

Verifizieren: Datenbank-Export und Dateiarchiv des kompromittierten Zustands liegen außerhalb des Servers, und Ihre Notizen enthalten Symptome, Zeitpunkte und letzte Änderungen.

Schritt 2: Veränderte Dateien finden

WP-CLI vergleicht Core-Dateien und Plugins aus dem offiziellen Verzeichnis mit den Prüfsummen von wordpress.org. Das ist der schnellste Weg, um veränderte oder zusätzliche Dateien zu finden. Im Test wurden eine fremde Datei in wp-includes und eine Zeile Schadcode in einem Plugin eingeschleust:

wp core verify-checksums
wp plugin verify-checksums --all

Success: WordPress installation verifies against checksums.
Warning: File should not exist: wp-includes/class-wp-cache-helper.php

plugin_name  file         message
akismet      akismet.php  Checksum does not match
Error: Only verified 1 of 2 plugins (1 failed).

Achtung beim Lesen: wp core verify-checksums meldete im Test „Success“, obwohl eine fremde Datei in wp-includes lag. Die zusätzliche Datei erscheint nur als Warnung. Lesen Sie deshalb jede Zeile, nicht nur das Ergebnis. Mit --include-root prüft der Befehl auch das Stammverzeichnis auf fremde Dateien.

Premium-Plugins und Themes lassen sich so nicht prüfen, weil wordpress.org keine Prüfsummen für sie hat. Suchen Sie zusätzlich nach typischen Spuren:

# PHP-Dateien haben im Upload-Ordner nichts zu suchen
find wp-content/uploads -type f -name "*.php"

# kürzlich geänderte PHP-Dateien
find . -name "*.php" -newermt "2026-09-20" | head -50

# typische Verschleierung
grep -rlE "eval\(|base64_decode\(|gzinflate\(" wp-content --include=*.php

# Must-Use-Plugins laden ohne Aktivierung
wp plugin list --status=must-use

Im Test fanden diese Befehle eine Webshell unter wp-content/uploads/2026/cache.php und das unbekannte Must-Use-Plugin health. Treffer bei base64_decode sind nicht automatisch Schadcode, auch seriöse Plugins nutzen die Funktion. Entscheidend ist der Zusammenhang, etwa eval(base64_decode(…)) in einer Datei, die es im Original nicht gibt. Ergänzend empfiehlt die WordPress-Dokumentation Scanner als Plugin und externe Prüfdienste, weil jede Methode andere Dinge findet.

Verifizieren: Sie haben eine Liste aller veränderten, zusätzlichen und verdächtigen Dateien mit Pfad. Diese Liste gehört zur Dokumentation aus Schritt 1.

Schritt 3: Core, Plugins und Themes ersetzen

Einzelne infizierte Dateien zu reparieren ist riskant, weil Angreifer oft mehrere Hintertüren hinterlassen. Sicherer ist es, alles durch Originale zu ersetzen, was sich ersetzen lässt. Ihre eigenen Daten stecken in wp-config.php, im Ordner wp-content/uploads und in der Datenbank. Alles andere kommt frisch aus dem Netz.

Den Core laden Sie ohne den Ordner wp-content neu:

wp core download --skip-content --force
wp core verify-checksums

Der Befehl überschreibt vorhandene Core-Dateien, entfernt aber keine zusätzlichen Dateien. Im Test blieb wp-includes/class-wp-cache-helper.php nach dem Download bestehen und wurde weiter als Warnung gemeldet. Löschen Sie jede so gemeldete Datei von Hand, nachdem Sie sie gesichert haben.

Plugins aus dem Verzeichnis installieren Sie mit --force neu. Im Test war die manipulierte Datei danach ersetzt und die Prüfung erfolgreich:

wp plugin install akismet --force
wp plugin verify-checksums --all

Success: Verified 2 of 2 plugins.

Premium-Plugins und -Themes laden Sie aus dem Kundenkonto des Herstellers und ersetzen die Ordner vollständig. Entfernen Sie Plugins und Themes, die Sie nicht nutzen. Deaktivierte Plugins liegen weiter auf dem Server und können angreifbar bleiben.

Löschen Sie zuletzt alle PHP-Dateien im Upload-Ordner und unbekannte Must-Use-Plugins. Prüfen Sie die wp-config.php und die .htaccess von Hand auf fremde Zeilen, zum Beispiel Weiterleitungen oder eingebundene Dateien.

Verifizieren: wp core verify-checksums und wp plugin verify-checksums --all zeigen keine Warnungen mehr außer bekannten Dateien Ihres Hosters, und find wp-content/uploads -name "*.php" liefert kein Ergebnis.

Schritt 4: Datenbank und Benutzerkonten prüfen

Schadcode steckt nicht nur in Dateien. Angreifer legen Administratoren an, ändern die Website-Adresse oder schreiben Skripte in Beiträge und Optionen. Beginnen Sie mit den Konten:

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

Im Test erschien dort der eingeschleuste Benutzer wpsupport, der wie ein Supportkonto klingt. Löschen Sie fremde Konten und übertragen Sie deren Inhalte auf ein echtes Konto:

wp user delete 2 --reassign=1

Kontrollieren Sie die Adressen der Website und suchen Sie in der Datenbank nach eingeschleusten Skripten oder fremden Domains:

wp option get siteurl
wp option get home
wp db search '<script' --all-tables
wp db search 'evil.example' --all-tables --stats

Im Test fand wp db search ein Skript in einem Beitrag und gab Tabelle, Spalte und Datensatz-ID aus. Entfernen Sie solche Stellen gezielt im Editor oder mit wp search-replace, zuerst mit --dry-run. Ersetzen Sie nie per SQL-Befehl in serialisierten Daten, das beschädigt Einstellungen. Prüfen Sie auch geplante Aufgaben mit wp cron event list, denn Angreifer nutzen WP-Cron, um Schadcode regelmäßig neu zu schreiben.

Verifizieren: Die Administratorliste enthält nur bekannte Personen, siteurl und home zeigen Ihre Domain, und die Datenbanksuche findet keine fremden Skripte mehr.

Schritt 5: Zugangsdaten erneuern und Lücke schließen

Gehen Sie davon aus, dass alle Zugangsdaten bekannt sind, die auf dem Server lagen oder dort eingegeben wurden. Erneuern Sie in dieser Reihenfolge: Hosting-Kundenkonto, FTP und SSH, Datenbankpasswort (danach in der wp-config.php eintragen), dann alle WordPress-Passwörter. Neue Sicherheitsschlüssel machen alle bestehenden Anmeldungen ungültig:

wp config shuffle-salts
wp user session destroy admin --all
wp user reset-password admin --skip-email

Im Test meldete WP-CLI „Success: Shuffled the salt keys.“ und „Success: Destroyed all sessions.“ Der Befehl wp user session destroy erwartet einen Benutzernamen. Ohne ihn erscheint nur die Hilfezeile usage: wp user session destroy <user> [<token>] [--all]. Ändern Sie Anwendungspasswörter und API-Schlüssel von Diensten, die mit der Website verbunden sind.

Danach schließen Sie die Lücke. Mögliche Ursachen sind ein Plugin mit bekannter Sicherheitslücke, ein nicht mehr gepflegtes Theme oder ein schwaches Passwort. Aktualisieren Sie alles auf den neuesten Stand und entfernen Sie Erweiterungen ohne Updates. Gegen erneute Anmeldeversuche helfen die Maßnahmen aus Brute-Force-Angriffe auf wp-login.php abwehren. Beenden Sie den Wartungsmodus mit wp maintenance-mode deactivate erst, wenn alle Schritte erledigt sind.

Ein Hack zeigt, dass Updates, Backups und Schutzmaßnahmen dauerhaft gepflegt werden müssen. Wer das künftig nicht selbst im Kalender halten möchte, kann es abgeben: Die WordPress-Wartung von wordpressupdate.de übernimmt Updates von WordPress, Plugins und Themes, wöchentliche Backups auf externen Speicher sowie Einrichtung und Wartung einer Firewall.

Verifizieren: Die alten Passwörter funktionieren nicht mehr, alle Sitzungen sind beendet, wp plugin list --update=available zeigt keine offenen Updates, und externe Prüfdienste melden die Website als unauffällig.

Typische Fehler

Altes Backup eingespielt, Hack kommt zurück. Ein Backup von vor dem Vorfall enthält meist dieselbe Lücke, etwa das veraltete Plugin. Nach dem Einspielen müssen Updates und neue Zugangsdaten folgen, sonst beginnt alles von vorn. Außerdem fehlen Inhalte seit dem Backup. Deshalb die Sicherung aus Schritt 1.

„Success“ trotz fremder Dateien. Wie im Test gezeigt, endet wp core verify-checksums auch bei zusätzlichen Dateien mit „Success“. Nur die Warnzeilen zeigen das Problem. Lesen Sie die vollständige Ausgabe.

Nur Symptome entfernt. Wer die sichtbare Weiterleitung löscht, aber die Webshell im Upload-Ordner übersieht, ist nach Tagen wieder betroffen. Arbeiten Sie alle Punkte aus Schritt 2 ab.

Google-Warnung bleibt bestehen. Nach der Bereinigung beantragen Sie eine erneute Prüfung bei der Suchmaschine, etwa über die Google Search Console. Die Warnung verschwindet nicht sofort von selbst.

Häufige Fragen

Kann ich die Website nicht einfach neu aufsetzen?

Das ist eine gute Option, wenn Sie Inhalte sauber exportieren können. Übernehmen Sie dabei nur Inhalte und Medien, keine PHP-Dateien aus dem alten wp-content. Die Datenbank prüfen Sie trotzdem wie in Schritt 4.

Wann sollte ich Hilfe holen?

Bei Shops, Mitgliederbereichen oder wenn personenbezogene Daten betroffen sein könnten. Dann zählen Beweissicherung und die Frist nach Art. 33 DSGVO, und ein erfahrener Dienstleister spart Zeit.

Reicht ein Sicherheits-Plugin zur Bereinigung?

Scanner finden viele, aber nicht alle Spuren. Die WordPress-Dokumentation empfiehlt, mehrere Verfahren zu kombinieren. Der Abgleich mit den Prüfsummen und das Ersetzen durch Originale bleiben die verlässlichste Grundlage.

Wie erkenne ich einen Hack früher?

Regelmäßige Prüfsummen-Checks, Benachrichtigungen bei neuen Administratoren und ein Blick in das Fehlerprotokoll helfen. Wie Sie Logs auswerten, zeigt WordPress Debug-Modus aktivieren.

Testumfang

Wir haben in einer Testinstanz mit WordPress 7.1.2 typische Einbruchsspuren nachgestellt, darunter eine Webshell im Upload-Ordner und einen zusätzlichen Administrator. Das Aufspüren per Prüfsummen und Dateisuche sowie das Bereinigen mit frischem Core, neuen Salts und beendeten Sitzungen haben wir Schritt für Schritt durchgespielt. Echte Schadsoftware, Scanner-Plugins und Premium-Erweiterungen waren nicht dabei, testen Sie das Vorgehen daher zuerst auf einer Kopie Ihrer Seite.

Fazit

Eine gehackte Website lässt sich in den meisten Fällen ohne Datenverlust bereinigen, wenn Sie nicht überstürzt löschen. Zuerst sichern und dokumentieren, dann mit Prüfsummen und gezielter Suche alle Spuren finden, ersetzen statt flicken, Konten und Datenbank prüfen, alle Zugangsdaten erneuern und die Ursache schließen. Damit es nicht wieder passiert, können Sie Updates, Backups und Firewall an eine WordPress-Wartung mit Firewall-Pflege abgeben.

Weiterführende Anleitungen und Quellen

• Brute-Force-Angriffe auf wp-login.php abwehren
• UpdraftPlus einrichten: automatische WordPress-Backups auf externen Speicher
• WordPress Debug-Modus aktivieren: Error-Logs analysieren und Fehler beheben
• WordPress-Dokumentation: FAQ My site was hacked
• WordPress Advanced Administration: Hardening WordPress
• WP-CLI Handbuch: wp core verify-checksums
• WP-CLI Handbuch: wp plugin verify-checksums
• Verordnung (EU) 2016/679 (DSGVO), Art. 33