--- title: "WordPress nach einem Hack bereinigen: Vorgehen ohne Datenverlust" date: 2026-09-30T21:18:40+02:00 modified: 2026-11-08T22:33:49+01:00 category: wordpress type: how_to author: Marcel Schönfelder canonical: https://s-edv.com/anleitungen/wordpress-nach-hack-bereinigen-ohne-datenverlust keywords: - WordPress - Sicherheit - Malware - WP-CLI - Incident Response reading_time: 10 --- # 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. **Kurzfassung:** Sichern Sie zuerst den kompromittierten Zustand vollständig, bevor Sie etwas ändern, und notieren Sie Symptome und Zeitpunkte. Prüfen Sie mit `wp core verify-checksums` und `wp plugin verify-checksums --all`, welche Dateien von den Originalen abweichen, und suchen Sie PHP-Dateien im Upload-Ordner. Ersetzen Sie Core, Plugins und Themes durch frische Downloads statt einzelne Dateien zu flicken. Entfernen Sie fremde Administratoren, erneuern Sie Passwörter und die Sicherheitsschlüssel in der `wp-config.php` und schließen Sie die Lücke, meist ein veraltetes Plugin. ## Voraussetzungen - [ ] **WordPress:** jede Version, für die wordpress.org Prüfsummen bereitstellt. - [ ] **PHP:** die auf dem Server installierte Version. - [ ] **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. ```bash $ 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: ```bash $ wp maintenance-mode activate ``` Der eingebaute Wartungsmodus läuft nach zehn Minuten ab und isoliert Schadcode nicht zuverlässig. Lassen Sie den Hoster den öffentlichen Zugriff für die gesamte Bereinigung sperren, wenn Besucher gefährdet sind. Arbeiten Sie an einer gesicherten Kopie, sofern die kompromittierte Installation nicht vertrauenswürdig ausgeführt werden kann. 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. > **Prüfen:** 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. Das folgende Beispiel zeigt die Ausgabe, wenn eine fremde Datei in `wp-includes` liegt und in einem Plugin eine Zeile Schadcode eingeschleust wurde: ```bash $ wp core verify-checksums $ wp plugin verify-checksums --all ``` ```plaintext 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` meldet „Success“, obwohl eine fremde Datei in `wp-includes` liegt, wie die Ausgabe oben zeigt. 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: ```bash # PHP-Dateien haben im Upload-Ordner nichts zu suchen ``` ```bash $ find wp-content/uploads -type f -name "*.php" ``` ```bash # kürzlich geänderte PHP-Dateien ``` ```bash $ find . -name "*.php" -newermt "2026-09-20" | head -50 ``` ```bash # typische Verschleierung ``` ```bash $ grep -rlE "eval\(|base64_decode\(|gzinflate\(" wp-content --include=*.php ``` ```bash # Must-Use-Plugins laden ohne Aktivierung ``` ```bash $ wp plugin list --status=must-use ``` Diese Befehle finden zum Beispiel eine Webshell unter `wp-content/uploads/2026/cache.php` oder ein unbekanntes Must-Use-Plugin wie `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. > **Prüfen:** 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: ```bash $ wp core download --skip-content --force $ wp core verify-checksums ``` Der Befehl überschreibt vorhandene Core-Dateien, entfernt aber keine zusätzlichen Dateien. Eine zusätzliche Datei wie `wp-includes/class-wp-cache-helper.php` bleibt nach dem Download bestehen und wird 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. Danach ist die manipulierte Datei ersetzt und die Prüfung erfolgreich: ```bash $ wp plugin install akismet --force $ wp plugin verify-checksums --all ``` ```plaintext 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. > **Prüfen:** `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: ```bash $ wp user list --role=administrator --fields=ID,user_login,user_email,user_registered ``` Dort erscheint zum Beispiel der eingeschleuste Benutzer `wpsupport`, der wie ein Supportkonto klingt. Löschen Sie fremde Konten und übertragen Sie deren Inhalte auf ein echtes Konto: ```bash $ wp user delete 2 --reassign=1 ``` Kontrollieren Sie die Adressen der Website und suchen Sie in der Datenbank nach eingeschleusten Skripten oder fremden Domains: ```bash $ wp option get siteurl $ wp option get home $ wp db search ' **Prüfen:** 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: ```bash $ wp config shuffle-salts $ wp user session destroy admin --all $ wp user reset-password admin ``` WP-CLI meldet „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 [] [--all]`. Der Passwortwechsel verschickt eine Benachrichtigung, zeigt das neue Passwort aber nicht automatisch an. Nutzen Sie anschließend die Passwort-vergessen-Funktion mit einem kontrollierten E-Mail-Konto. Ersetzen Sie `admin` durch den tatsächlichen Benutzernamen. Ä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](https://s-edv.com/anleitungen/wordpress-brute-force-wp-login-xmlrpc-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](https://wordpressupdate.de/?utm_source=s-edv.com&utm_medium=artikel&utm_campaign=35) übernimmt Updates von WordPress, Plugins und Themes, wöchentliche Backups auf externen Speicher sowie Einrichtung und Wartung einer Firewall. > **Prüfen:** 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 die Ausgabe in Schritt 2 zeigt, 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](https://s-edv.com/anleitungen/wordpress-debug-modus-error-logs-fehler-beheben). ## 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](https://wordpressupdate.de/?utm_source=s-edv.com&utm_medium=fazit&utm_campaign=35) abgeben. ## Weiterführende Anleitungen und Quellen - [Brute-Force-Angriffe auf wp-login.php abwehren](https://s-edv.com/anleitungen/wordpress-brute-force-wp-login-xmlrpc-abwehren) - [UpdraftPlus einrichten: automatische WordPress-Backups auf externen Speicher](https://s-edv.com/anleitungen/wordpress-updraftplus-automatische-backups-externer-speicher) - [WordPress Debug-Modus aktivieren: Error-Logs analysieren und Fehler beheben](https://s-edv.com/anleitungen/wordpress-debug-modus-error-logs-fehler-beheben) - [WordPress-Dokumentation: FAQ My site was hacked](https://wordpress.org/documentation/article/faq-my-site-was-hacked/) - [WordPress Advanced Administration: Hardening WordPress](https://developer.wordpress.org/advanced-administration/security/hardening/) - [WP-CLI Handbuch: wp core verify-checksums](https://developer.wordpress.org/cli/commands/core/verify-checksums/) - [WP-CLI Handbuch: wp plugin verify-checksums](https://developer.wordpress.org/cli/commands/plugin/verify-checksums/) - [Verordnung (EU) 2016/679 (DSGVO), Art. 33](https://eur-lex.europa.eu/eli/reg/2016/679/oj)