Ein Angriff auf eine WordPress-Website meldet sich selten mit einem Banner „Hacked by …“. Meist fällt er auf, weil Google eine Warnung ausspielt, der Hoster den Mailversand sperrt oder ein Kunde von einer merkwürdigen Weiterleitung erzählt. Wer dann sofort Dateien löscht, vernichtet Spuren und übersieht die Hintertür, durch die der Angreifer zurückkommt. Dieser Beitrag beschreibt die Reihenfolge, die sich bewährt hat: sichern, Schaden aufnehmen, säubern, Lücke schließen, Warnungen abbauen, Meldepflichten prüfen.
1. Zuerst aufschreiben, was Sie sehen
Wenn Ihre WordPress-Seite kompromittiert wurde, brauchen Sie einen WordPress gehackt Notfallplan, und der erste Handgriff darin ist kein technischer. Die WordPress-Dokumentation nennt das Dokumentieren ausdrücklich den ersten wirksamen Schritt nach einer Kompromittierung und schlägt konkrete Fragen vor: Was sehen Sie, das Sie an einen Angriff denken lässt? Wann haben Sie es bemerkt, in welcher Zeitzone? Was wurde zuletzt geändert? Dieselbe Quelle empfiehlt, auch die Eckdaten der Hosting-Umgebung zu notieren.
Diese Notizen sind die Grundlage eines Vorfallberichts, unabhängig davon, ob Sie selbst aufräumen oder jemanden beauftragen.
2. Die erste Stunde: Zugriff begrenzen, nichts wegwerfen
Besucher sollen keinen Schaden nehmen, und die Spuren sollen erhalten bleiben. Google empfiehlt in seinem Beitrag zum Vorgehen bei gehackten Websites, umgehend den Hosting-Anbieter zu kontaktieren, die Website offline zu nehmen oder mit dem Statuscode 503 auszuliefern und den Schaden anhand veränderter Dateien und auffälliger Serveraktivität zu bewerten.
Ziehen Sie vor dem ersten Aufräumen eine vollständige Kopie des befallenen Zustands, Dateien und Datenbank. Wenn drei Tage später die Frage kommt, ob Kundendaten abgeflossen sein könnten, ist diese Kopie das Einzige, was antwortet.
Der Hoster ist in dieser Phase der wichtigste Gesprächspartner. Er sieht Zugriffs- und Fehlerlogs, Mailwarteschlangen und Prozesse, die Sie im WordPress-Backend nie zu Gesicht bekommen.
3. Zugänge entwerten statt nur Passwörter ändern
Ein neues Admin-Passwort nützt wenig, solange eine gestohlene Sitzung weiterläuft. WordPress signiert Login-Cookies mit Schlüsseln, die laut Entwicklerdokumentation zu wp_salt() in der wp-config.php und zusätzlich in der Datenbank liegen. Werden die Werte in der Datei ersetzt, sind alle bestehenden Anmeldungen ungültig. Der Schlüsseldienst unter api.wordpress.org/secret-key/1.1/salt/ erzeugt auf Abruf einen frischen Satz.
Danach folgen die Zugänge selbst: alle WordPress-Konten mit Redaktions- oder Administratorrechten, Datenbankbenutzer, SFTP-/SSH-/Panel-Zugänge und API-Schlüssel von Drittdiensten. Die WordPress-Dokumentation rät, die Passwörter nach abgeschlossener Säuberung ein zweites Mal zu wechseln.
4. Den Schaden aufnehmen: Dateien, Benutzer, Aufgaben
Für Kerndateien gibt es eine exakte Methode: wp core verify-checksums lädt die Prüfsummen der installierten WordPress-Version von WordPress.org und vergleicht sie mit den Dateien auf dem Server. Für Erweiterungen gibt es das Gegenstück: wp plugin verify-checksums --all. Beide Befehle vergleichen gegen das WordPress.org-Verzeichnis. Für Premium-Plugins, individuelle Themes und wp-content/uploads existiert keine Vergleichssumme. Genau dort liegt erfahrungsgemäß die eingeschleuste PHP-Datei.
Prüfen Sie zusätzlich die Benutzerliste auf unbekannte Konten, die geplanten Aufgaben (Cron) auf unerklärte Einträge und die .htaccess im Wurzelverzeichnis und in uploads.
5. Die Hintertür ist wichtiger als der Schadcode
Der sichtbare Teil eines Angriffs ist meist der harmloseste. Sucuri berichtet im Hacked Website Report für 2023, dass bei 49,21 Prozent der kompromittierten Websites mindestens eine Hintertür gefunden wurde. Das ist eine Herstellerzahl aus einem bestimmten Kundenkreis, keine Statistik über alle Websites weltweit, aber sie beschreibt die Größenordnung.
Eine gesäuberte Website ohne gefundenen Einstiegspunkt ist eine Website, die auf ihren zweiten Vorfall wartet.
6. Backup einspielen oder sauber neu aufbauen?
Ein Backup ist nur dann die schnelle Lösung, wenn Sie wissen, wann der Angriff begann, und einen Stand von davor haben. Fehlt eine der beiden Bedingungen, spielen Sie möglicherweise die Hintertür gleich mit ein.
Beim Neuaufbau werden WordPress, Theme und Plugins frisch installiert, laut WordPress-Dokumentation in exakt derselben Version. Übernommen werden nur Inhalte: Datenbank und Uploads nach Prüfung. Bei Shops mit laufenden Transaktionen ist der Neuaufbau mit geprüfter Datenübernahme meist der sicherere Weg, weil zwischen Backup-Zeitpunkt und Wiederherstellung echte Bestellungen liegen.
7. WordPress gehackt Notfallplan: Die Lücke finden, sonst war alles umsonst
Ohne geschlossene Einfallstür war die gesamte Bereinigung vergeblich. Patchstack schreibt im Whitepaper „State of WordPress Security in 2026″, dass 91 Prozent der neuen Schwachstellen in Plugins und 9 Prozent in Themes gefunden wurden, während im WordPress-Kern lediglich sechs Schwachstellen geringer Priorität gemeldet wurden. Dieselbe Quelle beziffert den Anteil ungepatchter Schwachstellen auf 33 Prozent. Für solche Lücken ohne verfügbaren Patch gilt: Prüfen Sie in der Patchstack- oder WPScan-Datenbank, ob die betroffene Erweiterung einen bekannten Eintrag hat. Existiert kein Patch, deaktivieren und entfernen Sie das Plugin sofort und ersetzen Sie es durch eine Alternative oder setzen Sie als Zwischenschutz eine Web Application Firewall (WAF) ein.
Gehen Sie die installierten Plugins mit einer Frage durch: Brauchen wir das noch? Jedes Plugin, das bleibt, braucht jemanden, der seine Updates einspielt. Wie ein geordneter Update-Prozess aussieht, haben wir im Beitrag WordPress sicher aktualisieren beschrieben; warum das keine Kür ist, steht im Beitrag zur WordPress-Wartung.
8. Warnungen bei Google und im Browser abbauen
Solange Google Ihre Website als gehackt führt, hilft die beste Bereinigung nichts. Der Bericht „Sicherheitsprobleme“ in der Search Console zeigt Googles Befunde. Ist das Problem behoben, beantragen Sie dort die Überprüfung. Die Anleitung zum Review-Antrag hält fest, dass die Seiten für den Googlebot erreichbar sein müssen und dass ein Antrag bei noch bestehendem Problem die Warnung nur verlängert. Wichtig: Nehmen Sie die 503-Sperre aus Abschnitt 2 zurück, bevor Sie die Überprüfung beantragen.
9. Meldepflichten prüfen, bevor die Frist läuft
Sobald personenbezogene Daten betroffen sein könnten, ist der Vorfall nicht mehr nur technisch. Artikel 33 DSGVO verlangt, eine Verletzung des Schutzes personenbezogener Daten unverzüglich und möglichst binnen 72 Stunden nach Bekanntwerden der zuständigen Aufsichtsbehörde zu melden.
Die 72 Stunden laufen ab Kenntnis, nicht ab abgeschlossener Analyse. Deshalb gehört die Frage „sind personenbezogene Daten im Spiel?“ in die erste Stunde. Enthält Ihre WordPress-Datenbank Bestelldaten, Kontaktformular-Einträge oder Mitgliederdaten, gehen Sie von einem meldepflichtigen Vorfall aus und lassen Sie die Einschätzung durch den Datenschutzbeauftragten bestätigen oder entkräften, bevor die Frist abläuft.
10. Der Notfallplan: eine Seite, die vor dem Vorfall entsteht
Alles bisher Beschriebene wird deutlich einfacher, wenn vier Informationen schon bereitliegen, auf einem Blatt, das nicht auf dem betroffenen Server liegt:
- Wer entscheidet. Eine Person, die die Website vom Netz nehmen darf, ohne Rücksprache. Mit Handynummer.
- Wo die Zugänge liegen. Hoster, Domain, Datenbank, Search Console. In einem Passwortmanager, auf den mehr als eine Person Zugriff hat.
- Welches Backup wohin zurückgespielt wird. Inklusive des Datums, an dem die Wiederherstellung zuletzt wirklich getestet wurde.
- Wen Sie anrufen. Hoster-Support, Agentur, Datenschutzbeauftragte. Nummern, keine Kontaktformulare.
Sobald Sie die Hintertür nicht lokalisieren können, die Logs nicht lesen können oder personenbezogene Daten betroffen sein könnten, beauftragen Sie einen spezialisierten Dienstleister. Was davor an Schutzmaßnahmen sinnvoll ist, haben wir im Beitrag So schützen Sie WordPress gegen Hacker-Angriffe zusammengestellt.
11. Fazit
Der Unterschied zwischen einer teuren und einer beherrschbaren Bereinigung liegt in der Reihenfolge. Wer zuerst dokumentiert, dann sichert, dann die Sitzungen entwertet und erst danach säubert, verliert eine Stunde und gewinnt die Antwort auf die Frage, was überhaupt passiert ist. Wer sofort löscht, ist schneller fertig und weiß am Ende nichts.
Setzen Sie sich nach dem Wiederanlauf einen Termin in drei Wochen: Prüfsummen erneut vergleichen, Benutzerliste durchgehen, Search Console ansehen. Kommt nichts zurück, war die Lücke wirklich geschlossen.