WordPress gehackt: der Notfall-Guide für die ersten 72 Stunden

Ein Kunde ruft an, weil deine Website bei ihm eine rote Warnseite zeigt. Oder Google meldet in der Search Console ein Sicherheitsproblem. Oder deine Startseite wirbt plötzlich für Dinge, die du nie verkauft hast. In diesem Moment zählt vor allem, was du in den nächsten Minuten nicht tust. Dieser Leitfaden führt dich durch die Stunden nach einem Hack: erst Schaden begrenzen, dann Zugänge sichern, dann die Ursache finden, erst danach aufräumen. In dieser Reihenfolge, denn die falsche Reihenfolge kostet dich den zweiten Versuch.

Die ersten 15 Minuten: Schaden begrenzen

Solange die Seite erreichbar ist, arbeitet der Schadcode weiter. Er verteilt Spam, leitet Besucher um oder greift Daten ab, und jeder Aufruf verschlechtert deine Lage bei Google. Nimm die Seite deshalb zuerst aus dem Verkehr, entweder über den Wartungsmodus deines Hosters oder indem du sie auf eine statische Hinweisseite umleitest.

Bevor du irgendetwas änderst, sichere den aktuellen Zustand vollständig, also Dateien und Datenbank. Das fühlt sich falsch an, weil du gerade Schadcode mitsicherst. Es ist trotzdem richtig. Dieses Abbild ist der einzige Ort, an dem die Spuren des Einbruchs noch vollständig vorhanden sind. Ohne diese Spuren findest du die Ursache später nicht, und ohne Ursache wiederholt sich der Vorfall.

Notiere parallel den Zeitpunkt und alles, was dir aufgefallen ist. Wann kam die erste Meldung, was genau war zu sehen, wer hat in den Tagen davor etwas installiert oder geändert. Diese Notizen brauchst du später für die Ursachensuche und gegebenenfalls für die Meldung.

Die erste Stunde: Zugänge sperren

Jetzt geht es darum, den Angreifer auszusperren. Alles andere ist ohne diesen Schritt vergebliche Arbeit.

• Passwörter aller Benutzer zurücksetzen: Nicht nur dein eigenes. Jeder Zugang mit Backend-Rechten gehört dazu, auch alte Redaktionskonten, an die niemand mehr denkt.
• Zugänge beim Hoster erneuern: FTP und SFTP, Datenbank-Passwort und das Hosting-Konto selbst. Wenn das Datenbank-Passwort wechselt, muss es auch in der Konfigurationsdatei angepasst werden.
• Sicherheitsschlüssel neu setzen: In der Datei wp-config.php stehen mehrere zufällige Schlüssel. Ersetzt du sie durch neue, werden alle aktiven Sitzungen sofort ungültig, auch die des Angreifers. Das ist der wirksamste einzelne Handgriff in dieser Phase.
• Benutzerliste prüfen: Sieh nach, ob Konten mit Administratorrechten existieren, die du nicht zuordnen kannst. Ein zusätzlicher Administrator ist eine der häufigsten Hintertüren. Prüfe auch, ob bei bestehenden Konten die hinterlegte E-Mail-Adresse verändert wurde.
• Zwei-Faktor-Anmeldung aktivieren: Spätestens jetzt, mindestens für alle Administratoren.

Die Ursache finden, bevor du aufräumst

Das ist der Schritt, den fast alle überspringen, und der Grund, warum dieselbe Seite oft zweimal innerhalb eines Monats betroffen ist. Löschen ohne Ursachenklärung bedeutet, dass die offene Tür offen bleibt.

In der Praxis führen vier Spuren fast immer zum Ziel. Erstens die Liste der installierten Erweiterungen mit ihren Versionsständen, abgeglichen mit bekannten Sicherheitslücken. Das ist der wahrscheinlichste Weg, denn 96 Prozent der 2024 gemeldeten WordPress-Lücken steckten in Plugins und nur 4 Prozent in Themes. Zweitens die Zugriffsprotokolle deines Hosters rund um den Zeitpunkt der ersten Auffälligkeit. Drittens die Änderungszeitpunkte der Dateien, denn fremde Dateien tragen meist ein Datum, das nicht zu deinem letzten Update passt. Viertens die Frage, ob dieselbe Kennung noch anderswo verwendet wird, etwa aus einem geleakten Passwort.

Häufige Fundstellen sind PHP-Dateien im Upload-Verzeichnis, in dem eigentlich nur Bilder und Dokumente liegen dürfen, kryptisch benannte Dateien im Hauptverzeichnis, fremde Weiterleitungsregeln in der .htaccess sowie eingeschleuster Code in wp-config.php oder functions.php. Alles, was du nicht selbst dort hingelegt hast, gehört auf den Prüfstand.

Aufräumen: zwei Wege, einer davon besser

Der bessere Weg ist die Wiederherstellung aus einem sauberen Backup. Wichtig ist das Wort sauber. Entscheidend ist nicht, wie aktuell das Backup ist, sondern ob es vor dem Einbruch entstanden ist. Weil viele Hacks wochenlang unbemerkt bleiben, ist der Stand von gestern häufig bereits infiziert. Der Ablauf: Installation und Datenbank vollständig entfernen, das saubere Backup einspielen, sofort erneut alle Passwörter und Schlüssel wechseln, alles aktualisieren und zum Schluss die gefundene Lücke schließen. Fehlt der letzte Punkt, war die ganze Arbeit umsonst.

Der aufwendigere Weg ist die manuelle Bereinigung, wenn kein sauberes Backup existiert. Dabei werden die Kernverzeichnisse durch eine frische Installation derselben Version ersetzt, Erweiterungen mit den Originalversionen verglichen und neu installiert statt repariert, verdächtige Dateien entfernt und die Datenbank auf eingeschleuste Inhalte, fremde Benutzer und veränderte Grundeinstellungen geprüft. Das ist Detailarbeit, bei der ein einziger übersehener Schnipsel genügt, damit alles von vorn beginnt. Wenn du an dieser Stelle unsicher bist, ist das der richtige Moment, jemanden dazuzuholen.

Wieder live gehen und bei Google aufräumen

Bevor die Seite zurück ans Netz geht, prüfe die Geldwege: Formular absenden, Terminbuchung durchspielen, Bestellung testen, Tracking kontrollieren. Ein bereinigter Auftritt, bei dem das Kontaktformular nicht mehr sendet, ist nur ein anderer Ausfall.

Danach kümmerst du dich um die Außenwirkung. In der Google Search Console findest du unter den Sicherheitsproblemen den Befund und kannst nach der Bereinigung eine erneute Überprüfung beantragen. Prüfe außerdem, ob im Index Seiten aufgetaucht sind, die es bei dir nie gab, und ob dein Hoster oder Browserhersteller noch eine Warnung führt. Diese Aufräumarbeit entscheidet darüber, wie schnell deine Sichtbarkeit zurückkommt.

Die rechtliche Seite: die 72 Stunden

Sobald bei einem Vorfall personenbezogene Daten betroffen sein können, ist das nicht nur ein technisches, sondern ein datenschutzrechtliches Ereignis. Artikel 33 DSGVO verlangt die Meldung an die zuständige Aufsichtsbehörde binnen 72 Stunden, nachdem der Vorfall bekannt wurde, sofern ein Risiko für die Betroffenen nicht unwahrscheinlich ist. Besteht ein hohes Risiko, müssen nach Artikel 34 zusätzlich die Betroffenen informiert werden.

Praktisch heißt das: Kläre früh, welche Daten in der Installation liegen. Bei einer reinen Broschüren-Website sind das oft nur Kontaktformular-Einträge, bei einem Shop dagegen Namen, Adressen und Bestellhistorien. Diese Einordnung gehört in die ersten Stunden, nicht in die letzte. Und sie ist ein weiteres Argument dafür, den kompromittierten Stand zu sichern, denn ohne ihn kannst du später nicht belegen, was passiert ist.

Damit es nicht wieder passiert

Nach dem Vorfall ist die Bereitschaft am größten, etwas zu ändern. Nutz das Zeitfenster für die Punkte, die Wiederholungen verhindern: Erweiterungen ausmisten und alles entfernen, was nicht gebraucht wird, denn jedes Plugin ist fremder Code mit vollen Rechten. Zugänge auf das nötige Maß reduzieren, also nicht jeder braucht Administratorrechte. Zwei-Faktor-Anmeldung verpflichtend machen. Backups an einen getrennten Ort legen und die Wiederherstellung einmal wirklich testen. Und einen festen Rhythmus für Updates samt Funktionsprüfung etablieren.

Das ist genau der Ablauf, den wir im Beitrag WordPress-Wartung: warum Updates allein nicht reichen beschrieben haben. Nach einem Hack liest er sich anders als vorher. Wenn die Seite nach der Bereinigung außerdem spürbar langsam ist, hilft der Beitrag WordPress-Seite langsam beim Sortieren der Ursachen.

Fazit

Ein Hack ist selten persönlich gemeint. Bots suchen automatisiert nach bekannten Lücken, und eine veraltete Erweiterung ist genau das, wonach sie suchen. Was du beeinflussen kannst, ist die Reaktion: erst sichern und begrenzen, dann aussperren, dann die Ursache finden, erst danach aufräumen und die Lücke schließen. Wer diese Reihenfolge einhält, ist nach zwei bis drei Tagen durch. Wer sofort löscht, macht die Arbeit meist zweimal.

• Patchstack: State of WordPress Security 2025 (Auswertung 2024: 96 Prozent der gemeldeten Lücken in Plugins, 4 Prozent in Themes)
• Wordfence: 2024 Annual WordPress Security Report (automatisierte Angriffe, durchschnittlich ein Angriff alle 34 Minuten je Website)
• Europäische Union: Datenschutz-Grundverordnung (Artikel 33: Meldung binnen 72 Stunden, Artikel 34: Benachrichtigung der Betroffenen)
• Google Search Central: Sicherheitsprobleme und erneute Überprüfung (Vorgehen nach einer Kompromittierung)