Website gehackt: der Notfall-Fahrplan

„Gehackt" ist ein Wort, das viel behauptet und wenig erklärt. Genau das schreibt auch WordPress.org in der eigenen Dokumentation zum Thema: Ein Hack sei „ein sehr mehrdeutiger Begriff", der für sich genommen kaum verrät, was tatsächlich passiert ist. Bevor du irgendetwas unternimmst, brauchst du deshalb einen konkreten Befund statt eines diffusen Gefühls – etwas, das du benennen und später auch wieder überprüfen kannst.

Vier Befunde, die wirklich zählen

WordPress.org listet in der eigenen Anleitung eine Reihe von Anzeichen auf, die als eindeutige Indizien für eine Kompromittierung gelten. Zusammengefasst lassen sie sich vier Gruppen zuordnen. Erstens Warnungen von außen: Deine Website erscheint bei Google oder Bing auf einer Sperrliste, dein Hosting-Anbieter hat den Zugriff deaktiviert, oder Besucher melden dir, dass ihr Virenschutz beim Aufruf deiner Seite anschlägt. Zweitens sichtbare Veränderungen: fremde Inhalte, Weiterleitungen auf unbekannte Domains oder ganze Seiten, die plötzlich anders aussehen als du sie verlassen hast. Drittens unautorisierte Aktivität im Adminbereich: neue Benutzerkonten, die du nicht angelegt hast, oder Änderungen, an die sich niemand aus deinem Team erinnert. Viertens Meldungen, dass deine Website selbst zum Angreifer wird – etwa der Hinweis, dass von deinem Server aus andere Websites attackiert werden.

Jedes dieser vier Anzeichen ist für sich genommen bereits belastbar – du brauchst nicht alle vier gleichzeitig, um von einem echten Befund statt einer Vermutung zu sprechen. Genau diese Eindeutigkeit unterscheidet einen dokumentierten Hack von einer bloßen Unregelmäßigkeit.

Was kein Beleg ist

Nicht jede Auffälligkeit gehört in diese Liste. Eine einzelne Fehlermeldung im Browser, eine kurzzeitig nicht erreichbare Seite oder ein Darstellungsfehler nach einem Update haben oft ganz andere, harmlosere Ursachen – Server-Wartung, ein fehlerhaftes Plugin-Update, ein simpler Konfigurationsfehler. Solche Symptome für sich genommen sind kein Beleg für einen Hack, auch wenn sie beunruhigend wirken. Wer bei jeder Unregelmäßigkeit sofort „gehackt" ruft, verliert Zeit, die in der echten ersten Stunde fehlt – und genau die beginnt im nächsten Abschnitt.

Warum die Unterscheidung so wichtig ist

Der Unterschied zwischen Befund und Vermutung entscheidet auch darüber, wie du die nächsten Schritte angehst. Ein bestätigter Befund verlangt sofortiges Handeln nach der Reihenfolge aus Abschnitt 02 – Zugänge sperren, dokumentieren, sichern. Eine bloße Vermutung dagegen verdient zunächst eine ruhige Prüfung: einen Blick in die Fehlerprotokolle des Hosting-Anbieters, einen Abgleich mit dem letzten bekannten sauberen Zustand, ein kurzes Gespräch mit allen, die zuletzt Zugriff auf die Website hatten. Wer diese Reihenfolge vertauscht und bei jeder Vermutung sofort in den Notfallmodus wechselt, riskiert unnötige Ausfallzeiten und verliert die Ruhe, die für eine saubere Bereinigung nötig ist, sobald tatsächlich einmal ein echter Fall eintritt.

WordPress.org bringt den ersten Schritt auf den Punkt, auch wenn er banal klingt: „Stay calm." Ruhig bleiben ist keine Floskel, sondern eine Anweisung mit Konsequenz – wer in Panik alles Mögliche gleichzeitig ausprobiert, verwischt genau die Spuren, die für die spätere Bereinigung wichtig sind. Die ersten sechzig Minuten entscheiden nicht darüber, ob du den Hack komplett behebst, aber darüber, ob du danach noch weißt, was passiert ist.

Zugänge sperren, bevor du etwas anderes tust

Der erste konkrete Handgriff: alle Zugänge zurücksetzen, nicht nur das eine Passwort, das dir verdächtig vorkommt. WordPress.org empfiehlt ausdrücklich, einen globalen Passwort-Reset für alle Benutzer auszulösen, insbesondere für Administratoren, und zusätzlich die Sicherheitsschlüssel in der Datei wp-config.php neu zu erzeugen. Diese Schlüssel bestimmen, welche Sitzungen als angemeldet gelten – werden sie ausgetauscht, wird jede bestehende Sitzung ungültig, auch die eines Angreifers, der sich bereits eingeloggt hat. Das betrifft nicht nur WordPress selbst, sondern jeden Zugang zu deiner Umgebung: FTP beziehungsweise SFTP, das Hosting-Kontrollpanel und die Datenbank.

Dokumentieren, bevor du aufräumst

Direkt danach kommt, was WordPress.org als eigenen Schritt nennt: Dokumentation. Halte fest, was genau dich stutzig gemacht hat, wann du es zum ersten Mal bemerkt hast, in welcher Zeitzone, und welche Änderungen zuletzt an der Website vorgenommen wurden – ein neues Plugin, ein Theme-Update, eine Anpassung am Code. Dieses Protokoll ist die Grundlage für alles Weitere: Ob du selbst weiterarbeitest oder eine Agentur hinzuziehst, ohne diese Notizen fängt jede Analyse bei null an.

Ein Abbild sichern, bevor du löschst

Auch wenn der Impuls groß ist, sofort alles Verdächtige zu entfernen: Sichere zuerst ein vollständiges Abbild der Website in ihrem aktuellen, infizierten Zustand. WordPress.org nennt das ausdrücklich einen Zwischenschritt vor der eigentlichen Bereinigung – selbst eine kompromittierte Kopie ist wertvoll, weil sie später zeigt, was genau verändert wurde. Und weil ein Hack laut WordPress.org häufig seinen Ursprung nicht auf dem Server, sondern auf dem eigenen Rechner hat – Schadsoftware, die FTP- oder wp-admin-Zugangsdaten lokal mitliest –, gehört ein vollständiger Virenscan des eigenen Computers ebenfalls in diese erste Stunde, nicht erst später.

Wer in dieser Stunde informiert werden muss

Neben den technischen Schritten gehört eine kurze, klare interne Kommunikation in diese erste Stunde. Jeder im Team, der Zugriff auf die Website hat, sollte wissen, dass gerade alle Zugänge zurückgesetzt werden, damit niemand versehentlich mit einem alten Passwort arbeitet oder eine eigene, unabgestimmte Reparatur startet, die die spätere Analyse verkompliziert. Bei einer Website mit Kundenkonten oder einem Bestellprozess gehört an dieser Stelle auch die Frage auf den Tisch, ob der Shop oder das Formular vorübergehend abgeschaltet werden sollte, bis der Umfang aus Abschnitt 03 geklärt ist – lieber eine Stunde offline als tagelang unbemerkt kompromittiert.

Nachdem der erste Zugriffsstopp steht, folgt die Frage, die über den weiteren Aufwand entscheidet: Wie weit reicht der Schaden wirklich? Ein Hack, der nur eine einzelne Seite mit fremdem Text überschreibt, ist etwas anderes als einer, der sich in der Datenbank, in gespeicherten Kundendaten oder im Versand von Spam-Mails über deinen Server festgesetzt hat. Diese Einordnung entscheidet, ob die folgenden Abschnitte für dich als Selbsthilfe reichen oder ob du direkt zu Abschnitt 10 springen solltest.

Mehr als nur die eine Website

Ein Punkt, der besonders bei geteiltem Hosting unterschätzt wird: Laut WordPress.org kann ein Hack mehr betreffen als nur die eine Website, vor allem wenn mehrere Domains dieselbe Serverumgebung teilen. Deshalb lohnt sich frühzeitig ein Anruf beim Hosting-Anbieter – er kann einordnen, ob es sich um einen isolierten Vorfall handelt oder ob weitere Kunden auf demselben Server betroffen sind, und ob bereits serverseitige Gegenmaßnahmen laufen. Eine besonders unterschätzte Folge nennt WordPress.org ebenfalls ausdrücklich: Server, die zum Versand von Spam-Mails missbraucht werden, landen auf E-Mail-Sperrlisten – mit der Folge, dass danach auch reguläre Mails von deiner Domain nicht mehr zuverlässig ankommen, unabhängig vom eigentlichen Hack.

Zwei Arten, den technischen Umfang zu prüfen

Um den tatsächlichen Umfang zu bestimmen, unterscheidet WordPress.org in der eigenen Dokumentation zwei Kategorien von Scannern: Werkzeuge, die als Plugin direkt in deiner WordPress-Installation laufen und Dateien von innen prüfen, und externe Dienste, die deine Website wie ein gewöhnlicher Besucher von außen abrufen und auf verdächtigen Code untersuchen. Keine der beiden Varianten liefert für sich allein ein vollständiges Bild – zusammen zeigen sie aber deutlich mehr als eine reine Sichtprüfung im Browser.

Server-Protokolle als dritte Quelle

Eine dritte Quelle wird oft übersehen, obwohl sie meistens ohnehin schon vorhanden ist: die Zugriffsprotokolle deines Hosting-Anbieters. Sie zeigen, wann und von wo aus zuletzt auf den Adminbereich oder per FTP auf den Server zugegriffen wurde – auffällige Zugriffszeiten außerhalb deiner üblichen Arbeitszeiten oder von ungewöhnlichen Standorten aus liefern oft den ersten konkreten Hinweis darauf, wann der eigentliche Einbruch stattgefunden hat, nicht nur, wann er auffiel. Diese zeitliche Einordnung hilft dir später auch bei der Wahl des richtigen Backups in Abschnitt 06.

Die Frage, die zu Abschnitt 08 führt

Neben der technischen Reichweite gehört eine zweite Frage in diese Bestandsaufnahme, auch wenn die Antwort erst später gebraucht wird: Waren an irgendeiner Stelle personenbezogene Daten im Spiel – Kontaktformulare, Kundenkonten, gespeicherte Adressen oder Zahlungsdaten? Diese Frage kannst du an dieser Stelle oft noch nicht abschließend beantworten, solltest sie aber jetzt schon offen mitdenken, denn sie entscheidet, ob Abschnitt 08 für dich relevant wird oder nicht.

Die Bereinigung ist nur die halbe Arbeit, wenn du nicht auch verstehst, wie die Angreifer überhaupt hereingekommen sind – sonst stopfst du ein Loch und lässt das eigentliche Fenster offen. Vier Wege wiederholen sich in der Praxis auffällig oft, und für alle vier gibt es eine belegbare, nachvollziehbare Logik.

Veraltete Software

WordPress.org formuliert es unmissverständlich: Ältere Versionen sind anfälliger für Hacks als neuere. Das gilt für den WordPress-Kern selbst, und derselben Logik folgend genauso für Plugins und Themes, die von unabhängigen Anbietern gepflegt werden – jede bekannt gewordene Sicherheitslücke in einer veralteten Version ist öffentlich dokumentiert und damit für automatisierte Angriffswerkzeuge leicht auffindbar. Je länger eine Installation nicht aktualisiert wird, desto größer die Zahl bekannter, ungeschlossener Lücken.

Gestohlene Zugangsdaten – und zwar oft nicht am Server

Ein Punkt, der in vielen internen Diskussionen fehlt, aber in WordPress.orgs eigener Anleitung ausdrücklich benannt wird: In vielen Fällen beginnt die Quelle des Angriffs beziehungsweise der Infektion auf dem eigenen Rechner des Betreibers. Schadsoftware auf einem Notebook oder Desktop kann Zugangsdaten für FTP oder den wp-admin-Bereich lokal mitschneiden, während der eigentliche Websitebetreiber nichts von der Infektion seines Geräts bemerkt. Der Server war in diesem Fall nie das eigentliche Ziel – er war nur der Ort, an dem die gestohlenen Zugangsdaten benutzt wurden.

Schwache oder wiederverwendete Passwörter

Die eigene Sicherheits-Dokumentation von WordPress formuliert die Anforderung an ein Passwort so, dass sie zugleich den Angriffsweg beschreibt: Es soll für andere schwer zu erraten und für einen Brute-Force-Angriff schwer zu knacken sein. Beide Formulierungen benennen jeweils eine reale Angriffsmethode – das systematische Ausprobieren häufiger Passwörter und Kombinationen, die aus anderen Datenlecks bereits bekannt sind. Ein Passwort, das auch für andere Dienste verwendet wird, macht diesen Weg noch leichter, sobald irgendeiner dieser Dienste selbst kompromittiert wurde.

Geteilte Hosting-Umgebungen

Der vierte Weg führt nicht über deine eigene Website, sondern über die Nachbarschaft: Auf geteiltem Hosting läuft deine Installation oft auf derselben Serverumgebung wie zahlreiche fremde Websites. Eine Sicherheitslücke bei einem Nachbarn kann sich unter ungünstigen Umständen auf die gesamte Umgebung auswirken – ein Grund mehr, warum Abschnitt 03 den Kontakt zum Hosting-Anbieter ausdrücklich empfiehlt.

Warum die Ursache mehr wiegt als die Symptome

Diese vier Wege haben eines gemeinsam: Keiner von ihnen verschwindet automatisch, nur weil sichtbarer Schadcode entfernt wurde. Ein wiederhergestelltes veraltetes Plugin bleibt angreifbar, ein nicht geändertes gestohlenes Passwort bleibt gültig, eine infizierte Nachbarumgebung bleibt eine Gefahrenquelle. Deshalb gehört die Frage „wie kamen sie herein" für dich als Betreiber genauso zur Bereinigung wie das Entfernen des sichtbaren Schadens selbst – wer nur das eine ohne das andere macht, hat die Website nur kurzzeitig repariert, nicht dauerhaft abgesichert.

Jetzt beginnt der Teil, den WordPress.org selbst als den anspruchsvollsten Teil des gesamten Prozesses bezeichnet: Schadcode zu finden und zu entfernen. Wie viel davon du selbst leisten kannst, hängt stark davon ab, wie technisch versiert du im Umgang mit Dateien, Datenbank und Server bist – ehrlich eingeordnet wird das in Abschnitt 10.

Kernverzeichnisse ersetzen, aber richtig

Für den WordPress-Kern selbst gibt WordPress.org einen konkreten, sicheren Weg vor: Die Verzeichnisse wp-admin und wp-includes lassen sich vollständig durch eine saubere Kopie derselben WordPress-Version ersetzen – ausdrücklich per FTP oder SFTP hochgeladen, nicht über die Reinstallations-Funktion im WordPress-Adminbereich selbst. Der Grund ist entscheidend: Die eingebaute Reinstallation überschreibt nur bereits vorhandene Dateien, während ein Hack häufig zusätzliche, neue Dateien einschleust, die dabei unangetastet blieben. Wichtig ist außerdem, exakt dieselbe Versionsnummer zu verwenden, die die Website vorher hatte – eine andere Version kann die Website zusätzlich beschädigen.

Der Bereich, der keine Abkürzung kennt

Für wp-content, also Themes, Plugins und hochgeladene Medien, gibt es diese Abkürzung nicht, weil hier individuelle, nicht standardisierte Dateien liegen. WordPress.org empfiehlt, diesen Bereich Datei für Datei sorgfältiger zu durchgehen, statt ihn pauschal zu ersetzen. Wer eine Versionsverwaltung wie Git einsetzt, kann laut derselben Anleitung Unterschiede gezielt mit einem Diff-Befehl gegen den offiziellen Stand aus dem WordPress-Repository sichtbar machen – für alle anderen bleibt der manuelle Abgleich mit einer bekannten, sauberen Version der Website.

Die Dateien, die zuerst geprüft werden sollten

Ein einzelner Ort wird von WordPress.org besonders hervorgehoben: die Datei .htaccess. Sie liegt meist im Wurzelverzeichnis, kann aber auch in weiteren Ordnern eingeschleust sein, und wird laut Dokumentation unabhängig von der Art der Infektion besonders häufig für schädliche Zwecke verändert – etwa für unsichtbare Weiterleitungen. Daneben nennt WordPress.org eine kleine Gruppe zentraler Dateien, die bei fast jeder Art von Infektion zu den ersten Zielen gehören: index.php, header.php, footer.php und functions.php. Werden diese verändert, wirkt sich das auf praktisch jeden Seitenaufruf aus – ein Grund, warum sie so beliebt bei Angreifern sind und ebenso früh geprüft werden sollten.

Erst danach: Updates und neue Passwörter

Nach der eigentlichen Bereinigung folgt laut WordPress.org zwingend ein Update auf die aktuelle WordPress-Version – ältere Versionen bleiben, wie in Abschnitt 04 beschrieben, anfälliger. Und die Passwörter, die du bereits in der ersten Stunde zurückgesetzt hast, solltest du ein zweites Mal ändern, jetzt, wo die Website nachweislich sauber ist – falls beim ersten Reset noch ein Zugriff des Angreifers aktiv war, verhindert dieser zweite Wechsel, dass er sich unbemerkt zurückschleicht.

Ein Backup wirkt wie die einfachste Lösung: alten, sauberen Stand einspielen, fertig. Genau dieser Reflex führt aber regelmäßig zu einer zweiten Infektion innerhalb weniger Tage – weil ein Backup fast immer nur die Website selbst zurückholt, nicht aber den Grund, warum sie kompromittiert wurde.

Ein sauberes Backup ist kein sicheres Backup

Zwei Fragen musst du an jedes Backup stellen, bevor du es einspielst. Erstens: Ist es wirklich sauber, oder stammt es aus einem Zeitpunkt, an dem der Schadcode bereits vorhanden war, aber noch nicht sichtbar? Ein Backup vom Vortag ist nicht automatisch ein sicheres Backup, wenn der Angreifer schon Wochen vorher eingedrungen ist und sich zunächst nur unauffällig verhalten hat. Zweitens: Wurde der Einfallsweg aus Abschnitt 04 inzwischen geschlossen? Ein technisch tadelloses Backup bringt nichts, wenn dieselbe veraltete Plugin-Version oder dasselbe kompromittierte Passwort danach wieder aktiv ist – die Website wäre in diesem Fall nicht wiederhergestellt, sondern lediglich zurückgesetzt auf den Moment kurz vor dem nächsten, identischen Hack.

Die richtige Reihenfolge

Deshalb gehört die Reihenfolge selbst zur Sicherheit: Zuerst den Einfallsweg identifizieren und schließen – etwa das veraltete Plugin aktualisieren oder entfernen, das kompromittierte Zugangsdaten ändern –, danach erst das saubere Backup einspielen, nie umgekehrt. Wer zuerst wiederherstellt und die Ursache erst später sucht, riskiert, dass der Angreifer über denselben Weg zurückkommt, bevor die eigentliche Analyse überhaupt abgeschlossen ist. WordPress.org nennt regelmäßige, geprüfte Backups von Datenbank und Dateien ausdrücklich als Grundlage für den gesamten Wiederherstellungsprozess – aber eben als einen Baustein neben der Ursachenanalyse, nicht als Ersatz dafür.

Sitzungen und Schlüssel ein zweites Mal erneuern

Auch nach dem Einspielen eines Backups lohnt sich der Schritt aus Abschnitt 02 ein weiteres Mal: die Sicherheitsschlüssel in wp-config.php neu erzeugen, damit jede bestehende Sitzung ungültig wird, einschließlich solcher, die aus dem wiederhergestellten Stand womöglich übernommen wurden. Erst wenn Ursache geschlossen, Backup eingespielt und Sitzungen erneuert sind, ist der Rückweg tatsächlich abgeschlossen – nicht schon beim bloßen Hochladen der alten Dateien.

Ein Beispiel, das die Reihenfolge greifbar macht

Stell dir einen Onlineshop vor, bei dem eine veraltete Plugin-Version die Schwachstelle war und Kundenkonten in der Datenbank liegen. Wird zuerst das drei Tage alte Backup eingespielt, ohne das Plugin vorher zu aktualisieren, ist die Lücke am Tag danach wieder offen – und ein zweiter, identischer Hack wahrscheinlich nur eine Frage der Zeit. Wird dagegen zuerst das Plugin aktualisiert oder entfernt, dann das Backup eingespielt und anschließend die Sitzungen erneuert, ist derselbe Weg für einen erneuten Angriff bereits verschlossen, bevor die Website überhaupt wieder online geht. Der einzige Unterschied zwischen beiden Fällen ist die Reihenfolge – das Ergebnis auf den ersten Blick sieht identisch aus, ist es aber nicht.

Für viele Betreiber ist genau das der Moment, in dem der Hack überhaupt erst auffällt: eine Warnung in der Google-Suche oder im Browser, lange bevor irgendjemand im Team eine technische Auffälligkeit bemerkt hat. Dieser Abschnitt behandelt ausschließlich diese Außenwirkung – die Sicherheitswarnung selbst und den Weg, sie wieder loszuwerden, nicht die Frage, wie sich das auf Rankings auswirkt.

Was der Bericht zu Sicherheitsproblemen zeigt

In der Google Search Console gibt es dafür einen eigenen Bericht. Google beschreibt ihn so: Stellt eine Google-Auswertung fest, dass eine Website gehackt wurde oder sich so verhält, dass sie Besucher oder deren Computer gefährden könnte, zeigt der Bericht zu Sicherheitsproblemen genau diese Einschätzung an. Google unterscheidet darin ausdrücklich drei Kategorien: gehackte Inhalte, die ohne Berechtigung eingefügt wurden, Malware und unerwünschte Software, die Geräte von Besuchern schädigen oder täuschen kann, und Social Engineering, also Inhalte, die Besucher zu gefährlichen Handlungen verleiten sollen – etwa dazu, Zugangsdaten preiszugeben oder eine schädliche Datei herunterzuladen.

Was Besucher davon zu sehen bekommen

Für deine Website ist das nicht nur ein Eintrag in einem Bericht, den nur du siehst. Betroffene Seiten können laut Google entweder mit einem Warnhinweis direkt im Suchergebnis erscheinen oder als vollständige Zwischenseite mit Warnung angezeigt werden, sobald jemand versucht, sie im Browser zu öffnen. Beides schreckt Besucher zuverlässig ab, unabhängig davon, ob die Website inhaltlich längst wieder in Ordnung ist – solange die Warnung aktiv ist, sieht sie kein Besucher anders.

Der Überprüfungsantrag: Reihenfolge und Inhalt

Die Warnung verschwindet nicht von selbst, sobald du den Schadcode entfernt hast – du musst aktiv einen Überprüfungsantrag stellen, nachdem du sicher bist, dass die Website wirklich sauber ist. Google beschreibt selbst, woraus ein guter Antrag besteht: Er erklärt das genaue Problem auf der Website, beschreibt die Schritte, die zur Behebung unternommen wurden, und dokumentiert das Ergebnis dieser Maßnahmen. Ein Antrag, der nur behauptet, die Seite sei jetzt sauber, ohne diese drei Punkte nachvollziehbar zu machen, ist damit erkennbar unvollständig.

Wie lange die Prüfung dauert

Bei der Erwartungshaltung hilft Googles eigene Auskunft: Die meisten Überprüfungen dauern mehrere Tage bis Wochen. Wichtig ist außerdem ein Hinweis, den Google ausdrücklich gibt: Solange über einen bereits gestellten Antrag noch nicht entschieden wurde, sollte kein weiterer, neuer Antrag eingereicht werden – das verlängert die Bearbeitung eher, als sie zu beschleunigen. Über den Status hältst du dich per E-Mail-Benachrichtigung und im entsprechenden Bericht der Search Console auf dem Laufenden.

Nicht jeder Hack ist automatisch ein Datenschutz-Fall. Relevant wird dieser Abschnitt erst, wenn beim Hack tatsächlich personenbezogene Daten betroffen waren – etwa aus Kontaktformularen, Kundenkonten, einem Newsletter-Verteiler oder gespeicherten Bestelldaten. Wichtig vorweg: Dieser Abschnitt ersetzt keine Rechtsberatung. Er ordnet ein, was im Gesetzestext steht – die verbindliche Einschätzung für deinen konkreten Fall gehört in eine auf Datenschutzrecht spezialisierte Kanzlei.

Die 72-Stunden-Frist aus Artikel 33 DSGVO

Artikel 33 der Datenschutz-Grundverordnung verpflichtet den Verantwortlichen – bei einer eigenen Website in aller Regel der Betreiber selbst – im Falle einer Verletzung des Schutzes personenbezogener Daten dazu, diese der zuständigen Aufsichtsbehörde zu melden, und zwar unverzüglich und möglichst binnen 72 Stunden, nachdem ihm die Verletzung bekannt wurde. Die Frist beginnt also nicht erst mit dem Hack selbst, sondern mit dem Zeitpunkt, an dem du davon erfährst. Wird diese Frist überschritten, verlangt Artikel 33 eine Begründung für die Verspätung.

Wann die Meldepflicht entfällt

Eine Ausnahme sieht das Gesetz ausdrücklich vor: Die Meldepflicht entfällt, wenn die Verletzung voraussichtlich nicht zu einem Risiko für die Rechte und Freiheiten natürlicher Personen führt. Das ist eine Risikoeinschätzung, keine reine Formalität – ob im konkreten Fall ein Risiko vorliegt oder nicht, hängt unter anderem davon ab, welche Daten betroffen waren und ob sie beispielsweise verschlüsselt gespeichert wurden. Genau diese Einschätzung ist der Punkt, an dem juristischer Rat sinnvoller ist als eine eigene Vermutung.

Was eine Meldung enthalten muss

Fällt die Entscheidung für eine Meldung, verlangt Artikel 33 Absatz 3 bestimmte Mindestangaben: eine Beschreibung der Art der Verletzung und der betroffenen Kategorien von Personen und Datensätzen, die Kontaktdaten einer Anlaufstelle für Rückfragen, die wahrscheinlichen Folgen der Verletzung sowie die bereits ergriffenen oder geplanten Maßnahmen zur Behebung und Schadensbegrenzung. Liegen noch nicht alle Informationen vor, erlaubt das Gesetz ausdrücklich, sie schrittweise nachzureichen, ohne die Meldung deswegen zu verzögern.

Wenn es zusätzlich um Kunden selbst geht

Neben der Meldung an die Behörde regelt Artikel 34 DSGVO eine zweite, höhere Schwelle: Ist ein hohes Risiko für die persönlichen Rechte und Freiheiten natürlicher Personen zu erwarten, müssen zusätzlich die betroffenen Personen selbst informiert werden – etwa deine Kunden. Diese Pflicht entfällt laut Artikel 34, wenn die betroffenen Daten durch angemessene Maßnahmen wie Verschlüsselung ohnehin unzugänglich waren oder das Risiko durch nachträgliche Maßnahmen nachweislich beseitigt wurde. Arbeitest du mit einer Agentur oder einem Hoster, die als Auftragsverarbeiter für dich tätig sind, gilt zusätzlich: Diese müssen dir eine erkannte Verletzung laut Artikel 33 Absatz 2 unverzüglich melden, damit du selbst die 72-Stunden-Frist gegenüber der Behörde einhalten kannst.

Eine bereinigte Website ist ein Zwischenstand, kein Endpunkt. Ohne dauerhafte Änderungen an Gewohnheiten und Konfiguration bleibt derselbe Weg offen, über den der Hack zuerst gelungen ist – die eigene Sicherheits-Dokumentation von WordPress beschreibt genau die Bausteine, die das verhindern.

Zugang: Passwörter und ein zweiter Faktor

An erster Stelle steht ein Passwort, das laut WordPress.org für andere schwer zu erraten und für einen Brute-Force-Angriff schwer zu knacken ist – lang, einzigartig je Dienst, idealerweise aus einem Passwort-Manager. Ergänzend empfiehlt WordPress.org ausdrücklich eine zusätzliche Bestätigungsstufe beim Login, die sogenannte Zwei-Faktor-Authentifizierung: Selbst ein gestohlenes Passwort reicht dann allein nicht mehr aus, um sich anzumelden.

Updates als feste Routine, nicht als Reaktion

Der zweite Baustein knüpft direkt an Abschnitt 04 an: WordPress selbst, alle Plugins und alle Themes sollten fortlaufend aktuell gehalten werden, nicht erst nach dem nächsten Vorfall. Jede veröffentlichte Sicherheitslücke ist ab dem Moment der Veröffentlichung öffentlich bekannt – die Zeitspanne bis zum eigenen Update ist damit ein Zeitfenster, das automatisierte Angriffswerkzeuge aktiv ausnutzen.

Konfiguration, die Angriffsflächen von vornherein verkleinert

Auf technischer Ebene nennt WordPress.org mehrere konkrete Stellschrauben. Die Datei wp-config.php sollte, wo technisch möglich, eine Verzeichnisebene oberhalb der eigentlichen WordPress-Installation liegen und mit restriktiven Dateiberechtigungen versehen sein. Die Konstante DISALLOW_FILE_EDIT, in dieser Datei gesetzt, deaktiviert die Möglichkeit, Theme- und Plugin-Dateien direkt über den WordPress-Adminbereich zu bearbeiten – ein beliebter Weg, um über einen bereits kompromittierten Zugang zusätzlichen Schadcode einzuschleusen. Für die Dateiberechtigungen selbst empfiehlt WordPress.org ein abgestuftes Schema: Kernverzeichnisse wie wp-admin und wp-includes sollten ausschließlich für den Website-Betreiber beschreibbar sein, während wp-content, wo Uploads und von Plugins erzeugte Dateien liegen, notwendigerweise auch für den Webserver selbst beschreibbar bleiben muss. Und der Datenbank-Benutzer sollte laut Dokumentation nur die Rechte besitzen, die WordPress tatsächlich braucht – Lesen, Einfügen, Aktualisieren und Löschen –, nicht die volle Kontrolle über den kompletten Datenbankserver.

Backups, die im Ernstfall wirklich helfen

Der letzte Baustein ist der, der in Abschnitt 06 bereits gebraucht wurde: regelmäßige, geprüfte Backups von Datenbank und Dateien. WordPress.org betont dabei einen Punkt, der leicht übersehen wird – die Integrität dieser Backups ist entscheidend, ein Backup, dem du im Ernstfall nicht vertrauen kannst, ist keines. Dazu gehört, Wiederherstellungen gelegentlich testweise durchzuspielen, statt sich erst im Ernstfall zu zeigen, ob sie funktionieren.

Die ehrliche Antwort auf die Frage, ob du das selbst schaffst, hängt nicht von deinem Mut ab, sondern vom Umfang des Befunds aus Abschnitt 03 und deiner eigenen technischen Erfahrung im Umgang mit Dateien, FTP und einer Datenbank.

Wann Selbermachen realistisch ist

Bei einer einzelnen, klar abgegrenzten Veränderung – etwa fremdem Text auf einer Seite oder einer eingeschleusten Weiterleitung –, einem sauberen, überprüften Backup von vor dem Vorfall und einem WordPress-Kern, den du wie in Abschnitt 05 beschrieben per FTP ersetzen kannst, ist eine eigenständige Bereinigung ein realistisches Vorhaben. Vorausgesetzt, du bringst die Geduld für die Dokumentation aus Abschnitt 02 und die Sorgfalt für die einzelne Dateiprüfung aus Abschnitt 05 mit.

Wann es zum Fall für Fachleute wird

Die Grenze verschiebt sich deutlich, sobald einer von mehreren Punkten zutrifft: Der Hack kehrt nach der Bereinigung wieder zurück, ohne dass der Einfallsweg aus Abschnitt 04 eindeutig identifiziert werden konnte. Die Datenbank selbst zeigt Veränderungen, nicht nur einzelne Dateien. Es waren nachweislich personenbezogene Daten betroffen, und die Einschätzung aus Abschnitt 08 verlangt nach einer Kanzlei ohnehin schon eine zweite, fachkundige Meinung. Oder der Google-Überprüfungsantrag aus Abschnitt 07 wird trotz sorgfältiger Bereinigung abgelehnt, weil an anderer Stelle noch Schadcode aktiv ist, den du selbst nicht findest. In all diesen Fällen kostet jeder weitere eigene Versuch Zeit, die die Website weiterhin offline, gewarnt oder angreifbar lässt.

Der Zeitfaktor, der oft unterschätzt wird

Neben den technischen Kriterien gehört ein weiterer Punkt ehrlich in diese Abwägung: die Zeit, die eine gründliche eigene Bereinigung tatsächlich braucht. Kernverzeichnisse ersetzen, wp-content Datei für Datei durchgehen, Server-Protokolle auswerten und am Ende einen belastbaren Überprüfungsantrag formulieren ist für jemanden ohne tägliche Praxis darin ein Vorhaben von mehreren Tagen, nicht von einem Nachmittag. Für eine Website, die aktiv Umsatz oder Anfragen generiert, ist diese Zeit selbst dann ein Kostenfaktor, wenn am Ende alles selbst gelöst wird.

Was danach bleibt

Selbst nach einer erfolgreichen eigenen Bereinigung bleibt oft die Unsicherheit, ob wirklich jede Hintertür geschlossen wurde – ein Gefühl, das sich technisch nur durch eine gründliche zweite Prüfung ausräumen lässt, nicht durch bloßes Abwarten. Genau an diesem Punkt übernehmen wir bei EINSHOCH im Rahmen unserer laufenden WordPress-Betreuung und Absicherung die technische Detailarbeit: vom vollständigen Scan über die Suche nach der eigentlichen Ursache bis zur dauerhaften Härtung nach den Punkten aus Abschnitt 09.

Am Ende bleibt die Grundlogik aus Abschnitt 01: Ein echter Befund ist konkret, die erste Stunde entscheidet über den Umfang des Schadens, und die Bereinigung ist erst abgeschlossen, wenn auch die Ursache geschlossen ist. Ob du diesen Weg allein gehst oder ab einem bestimmten Punkt Hilfe holst, ändert daran nichts – nur das Tempo und die Sicherheit, mit der du am Ende ankommst.