Nach einem Hack einer WordPress-Website dient die erste Stunde der Dokumentation, die Bereinigung kommt danach. Zuerst sichere ich Beweise, dann ermittle ich das Einfallstor, und erst dann entferne ich die Malware, auf einer Kopie der Website, getrennt von der Live-Website. Blind gelöschte Dateien verwischen die Spuren des Einfallstors, und ein altes Backup, das ohne Prüfung des Infektionsdatums zurückgespielt wird, bringt den Schadcode oft gleich mit.
Diese Seite beschreibt die Anzeichen eines Hacks, die Reihenfolge meiner Arbeit nach einem Vorfall, Hacks von WooCommerce-Shops und Websites auf anderen Systemen sowie die Pflichten aus der DSGVO, die ab der Entdeckung laufen. Wenn Sie die Bereinigung selbst angehen wollen, steht die vollständige Anleitung mit Befehlen im Leitfaden zur Bereinigung einer gehackten WordPress-Website.
WordPress gehackt: die Anzeichen
Symptome, die meist einen Hack bedeuten, und mein erster Schritt in diesem Fall.
- Was Sie sehen: Google zeigt eine Warnung zu Ihrer Website, oder die Search Console meldet ein Sicherheitsproblem
- Was ich tueIch prüfe den Bericht Sicherheitsprobleme in der Search Console und die gemeldeten Adressen. Das ist der Ausgangspunkt für die Diagnose und den späteren Antrag auf Überprüfung.
- Was Sie sehen: In der Search Console steht ein Inhaber, den Sie nicht eingetragen haben
- Was ich tueIch halte ihn als Beweis fest und entferne den Zugang. Die Prüfung der Inhaber in der Search Console gehört zu den ersten Schritten nach einem Hack.
- Was Sie sehen: In der Benutzerliste steht ein unbekanntes Administratorkonto
- Was ich tueIch prüfe alle Administratorkonten und Cron-Aufgaben. Konten, die niemand angelegt hat, entferne ich, nachdem ich ihre Daten als Beweis gesichert habe.
- Was Sie sehen: Core-Dateien stimmen nicht mit dem Original überein
- Was ich tueIch führe wp core verify-checksums aus und vergleiche Plugin- und Theme-Dateien mit den Versionen aus offiziellen Quellen.
- Was Sie sehen: Die Website leitet Besucher auf fremde Adressen um oder verteilt Schadcode
- Was ich tueIch schalte den Wartungsmodus ein, damit die Website keine Besucher infiziert, und sichere Dateien und Datenbank als Beweis.
- Was Sie sehen: Kunden des Shops melden seltsames Verhalten beim Bestellabschluss oder bei der Zahlung
- Was ich tueIch behandle das als mögliche Verletzung des Schutzes personenbezogener Daten. Ich sichere Beweise, notiere den Zeitpunkt der Meldung und informiere Sie, weil ab diesem Moment die Fristen der DSGVO laufen.
- Was Sie sehen: Die Infektion kommt einige Tage nach der Bereinigung zurück
- Was ich tueIch suche das Einfallstor, das offen geblieben ist: eine Hintertür in der Datenbank, eine Cron-Aufgabe, ein altes Konto. Eine Bereinigung ohne geschlossenes Einfallstor hält nicht.
WordPress gehackt: was Sie in der ersten Stunde selbst tun können
Bevor Sie mir oder jemand anderem schreiben, erledigen Sie fünf Dinge. Löschen Sie keine Dateien. Sichern Sie Dateien und Datenbank, auch infiziert, denn das ist Beweismaterial. Notieren Sie Datum und Uhrzeit, zu der Sie den Hack bemerkt haben. Prüfen Sie in der Search Console, ob in der Liste der Inhaber jemand Fremdes steht. Verteilt die Website Malware oder leitet Besucher um, schalten Sie den Wartungsmodus ein.
Danach ändern Sie die Passwörter für den WordPress-Admin-Bereich, SFTP und die Datenbank. Spielen Sie kein altes Backup zurück, solange Sie nicht wissen, wann die Infektion begann. Ein Backup von letzter Woche hilft nicht, wenn der Schadcode seit einem Monat auf der Website liegt.
Die Bereinigung geht schneller, wenn ich sofort Zugang zum Hosting-Panel, zu den Server-Logs, zu SFTP, zur Datenbank und zur Search Console bekomme. Sind die Zugänge auf mehrere Personen oder Firmen verteilt, sammeln Sie sie an einer Stelle, bevor wir anfangen.
Malware entfernen: die Reihenfolge meiner Arbeit
Jeder Schritt endet mit etwas, das sich prüfen lässt: einer Kopie, einem Bericht, einer Liste der Änderungen.
Auftragsverarbeitungsvertrag vor dem Zugang
Bevor ich Zugang zur Website erhalte, schließen wir einen Auftragsverarbeitungsvertrag (AVV) nach Art. 28 DSGVO. Auf der infizierten Website liegen die Daten Ihrer Kunden.
Erste Stunde: Beweise sichern
Kopie von Dateien und Datenbank als Beweis, notierter Zeitpunkt der Entdeckung, Wartungsmodus, wenn die Website Malware verteilt, und Prüfung der Inhaber in der Search Console. Ab der Entdeckung zählen die Fristen der DSGVO.
Diagnose als eigene Phase
Die Diagnose hat einen eigenen Preis und einen abgeschlossenen Umfang. Ihr Ergebnis sind Ursache, Umfang der Bereinigung und Kosten, schriftlich. Die Bereinigung beginnt nach Ihrer Bestätigung dieses Umfangs.
Einfallstor auf einer Kopie ermitteln
Ich arbeite auf einer Kopie, nicht auf der Live-Website. Das Einfallstor ermittle ich aus den Server-Logs, mit wp core verify-checksums und durch den Vergleich der Plugin- und Theme-Dateien mit sauberen Versionen.
Dateien und Datenbank bereinigen
Ich entferne Malware und Hintertüren aus den Dateien und aus der Datenbank, prüfe Administratorkonten und Cron-Aufgaben und stelle Core und Plugins aus sauberen Quellen wieder her.
Neue Passwörter und Zugänge
Ich ändere die Passwörter für WordPress-Admin, SFTP und Datenbank. Alte Zugangsdaten behandle ich als dem Angreifer bekannt.
Ein Deployment, das sich zurücknehmen lässt
Die bereinigte Version spiele ich in einem Schritt ein, mit Möglichkeit zur Rücknahme. Ich ergänze Schutz gegen das ermittelte Einfallstor und beschreibe Ursache und Vorbeugung schriftlich.
Antrag auf Überprüfung bei Google
Ist die Website sauber, stelle ich im Bericht Sicherheitsprobleme der Search Console den Antrag auf Überprüfung.
Auf den letzten Schritt habe ich keinen Einfluss. Laut der Hilfe von Google dauert eine Überprüfung einige Tage bis einige Wochen, und nach ihrem Abschluss schickt Google eine E-Mail. Ein Datum, an dem die Warnung aus den Suchergebnissen verschwindet, verspreche ich deshalb nicht.
Was kostet es, Malware entfernen zu lassen
Einen Preis für die Bereinigung nenne ich nicht im Voraus, weil er davon abhängt, was die Diagnose findet: ob die Infektion einige Dateien betrifft oder auch Datenbank und Konten, ob die Backups älter sind als die Infektion und ob das Einfallstor ein Plugin ist, das sich einfach aktualisieren lässt. Die Diagnose ist eine eigene, abgeschlossene Phase mit eigenem Preis. Ihr Ergebnis sind Ursache, Umfang der Bereinigung und Kosten, schriftlich. Die Bereinigung beginne ich nach Ihrer Bestätigung dieses Umfangs.
Eine Website ohne Wartungsvertrag geht über die WordPress-Reparatur, wo ich den Preis nach der Beschreibung des Vorfalls nenne. Was die laufende Wartung mit Malware-Scan und täglichen Backups kostet, steht auf der Seite WordPress-Wartung: Kosten. Für Ausfälle nach Updates und schwache Core Web Vitals, die nicht von einer Infektion kommen, gibt es die Seite WordPress-Spezialist.
Gehackter WooCommerce-Shop
Ein Hack eines Shops unterscheidet sich vom Hack einer Firmenwebsite dadurch, dass fast immer personenbezogene Daten betroffen sind. In der Datenbank des Shops liegen Kundenkonten, Lieferadressen, Telefonnummern und die Bestellhistorie. Im Shop gehe ich deshalb ab der ersten Stunde davon aus, dass es um eine Datenschutzverletzung gehen kann, und notiere sofort den Zeitpunkt der Entdeckung, den ich Ihnen als Verantwortlichem weitergebe.
Die Reihenfolge der Arbeit ist dieselbe wie bei der Firmenwebsite, aber der Prüfumfang ist größer. Neben Dateien, Datenbank, Konten und Cron-Aufgaben prüfe ich die Plugins für Zahlung und Versand und die Konnektoren zu anderen Systemen, denn jedes davon hat eigene API-Schlüssel. Schlüssel, die abgeflossen sein könnten, müssen außer in WordPress auch beim Zahlungsanbieter, in der Warenwirtschaft oder im ERP ausgetauscht werden. Dafür braucht es Zugang zu den Konten dieser Dienste, deshalb erneuern wir die Schlüssel gemeinsam.
Nach der Bereinigung prüfe ich den Ablauf Warenkorb, Daten, Versand, Zahlung ohne echte Bestellung, bevor der Shop wieder verkauft. Einen Shop, in dem dieser Test ständig laufen soll, betreue ich im Store Reliability Plan. Funktionieren nach dem Hack Warenkorb oder Zahlung nicht und muss der Verkauf wieder anlaufen, ist der WooCommerce Rescue Sprint die passende Leistung.
Typisches Szenario: Shop mit Kundenkonten und veraltetem Plugin
Ein typischer Fall, mit dem Shop-Inhaber kommen, sieht so aus: Der Shop läuft seit einigen Jahren, hat Kundenkonten und ein gutes Dutzend Plugins, von denen einige seit Monaten nicht aktualisiert wurden. Jemand bemerkt ein fremdes Administratorkonto oder seltsames Verhalten beim Bestellabschluss. In so einem Shop sichere ich zuerst Beweise und notiere den Zeitpunkt der Entdeckung, dann prüfe ich, ob und welche Kundendaten gelesen werden konnten. Diese Beschreibung gebe ich Ihnen, denn Sie entscheiden, ob und wann die Verletzung der Aufsichtsbehörde gemeldet wird.
Typisches Szenario: Firmenwebsite leitet Smartphone-Besucher um
Ein anderes typisches Szenario: Der Inhaber einer Firmenwebsite erfährt von einem Kunden, dass die Website auf dem Smartphone auf eine fremde Seite weiterleitet, am Rechner aber normal aussieht. So ein Symptom bedeutet meist Schadcode in den Dateien oder in der Datenbank, der nur für ausgewählte Besucher aktiv wird. Auch hier beginne ich mit der Kopie als Beweis und dem Wartungsmodus und suche das Einfallstor in den Server-Logs und im Vergleich der Dateien mit sauberen Versionen. Hat die Website ein Kontaktformular, prüfe ich auch, ob der Schadcode Zugriff auf die Anfragen hatte, denn das sind personenbezogene Daten.
Gehackte Website auf Drupal, TYPO3, Laravel oder Symfony
Dieselbe Reihenfolge (Beweise, Einfallstor, Bereinigung auf einer Kopie, neue Zugänge, ein Deployment mit Rücknahme) gilt für Systeme außerhalb von WordPress. Es unterscheiden sich die Werkzeuge: In Drupal und TYPO3 stelle ich Core und Module über Composer aus sauberen Quellen wieder her, in einer Laravel- oder Symfony-Anwendung vergleiche ich den Code auf dem Server mit dem Repository.
Eine Version ohne Sicherheitssupport bekommt keine Korrekturen für neue Lücken. Drupal 7 bekommt seit dem 5. Januar 2025 keine Sicherheitsupdates mehr, Drupal 10 erreicht am 9. Dezember 2026 sein Supportende. Der kostenlose Support für TYPO3 12.4 endete am 30. April 2026. Nach der Bereinigung einer Website auf einer solchen Version reicht das Entfernen des Schadcodes nicht, es braucht einen Plan für das Update oder die Migration zu WordPress. Für Drupal 10 beschreibe ich die Optionen im Beitrag Drupal 10 End of Life: Upgrade oder Migration.
Datenpanne nach dem Hack: DSGVO, 72 Stunden und die zuständige Behörde
Konnte durch den Hack jemand an personenbezogene Daten gelangen (Kundenkonten, Bestellungen, Formularanfragen), beginnen die Fristen der DSGVO. Nach Art. 33 Abs. 1 DSGVO meldet der Verantwortliche die Verletzung unverzüglich und möglichst binnen 72 Stunden, nachdem sie ihm bekannt wurde, der zuständigen Aufsichtsbehörde, es sei denn, sie führt voraussichtlich nicht zu einem Risiko für die Rechte und Freiheiten natürlicher Personen. Eine spätere Meldung muss die Gründe für die Verzögerung nennen. Bei einem hohen Risiko verlangt Art. 34 Abs. 1 außerdem, die betroffenen Personen unverzüglich zu benachrichtigen.
Deutschland: Landesdatenschutzbehörde, BfDI und BSI
Die Meldepflicht folgt laut dem Bundesbeauftragten für den Datenschutz aus Art. 33 DSGVO und § 65 BDSG. Dieselbe Seite stellt klar, dass Privatunternehmen meist von den Landesbehörden beaufsichtigt werden, mit einigen Ausnahmen. Für einen Shop oder eine Firmenwebsite ist also in der Regel die Datenschutzbehörde des Bundeslands zuständig, in dem das Unternehmen seinen Sitz hat. Den Sicherheitsvorfall selbst können Sie unabhängig davon beim BSI als IT-Sicherheitsvorfall melden, freiwillig oder, wo eine Pflicht besteht, verpflichtend.
Österreich: Datenschutzbehörde und CERT.at
In Österreich geht die Meldung an die Datenschutzbehörde. Laut DSB hat sie unverzüglich und möglichst binnen 72 Stunden zu erfolgen, über ein Online-Formular. Den Vorfall selbst nimmt CERT.at entgegen.
Schweiz: EDÖB
Für Verantwortliche in der Schweiz stellt der EDÖB ein Online-Formular für Meldungen bereit, das DataBreach-Portal. Verkauft ein Schweizer Shop an Kunden in der EU, prüfen Sie mit Ihrer Rechtsberatung, welche Meldewege zusätzlich gelten.
Wer bei einer Datenpanne wofür zuständig ist
Die Aufteilung folgt aus der DSGVO und aus dem AVV, den wir vor dem ersten Zugang schließen.
Sie, als Verantwortlicher
- Sie entscheiden, ob die Verletzung der Aufsichtsbehörde gemeldet werden muss (Art. 33 DSGVO)
- Sie entscheiden, ob die betroffenen Personen benachrichtigt werden (Art. 34 DSGVO)
- Sie reichen die Meldung bei der Landesdatenschutzbehörde oder der DSB ein und behalten die 72 Stunden im Blick
- Sie führen die Kommunikation mit Kunden, deren Daten betroffen sein könnten
Ich, als Auftragsverarbeiter
- Ich informiere Sie unverzüglich, nachdem mir die Verletzung bekannt wurde (Art. 33 Abs. 2 DSGVO)
- Ich liefere die Fakten für die Meldung: Zeitpunkt der Entdeckung, betroffene Dateien und Daten, ermitteltes Einfallstor
- Ich melde nicht in Ihrem Namen an die Behörde, außer der Vertrag sieht das vor
- Ich beseitige die Folgen des Hacks und schließe das Einfallstor im Umfang, der im Vertrag steht
Die Haftung beider Seiten, auch für die Folgen eines Hacks, regelt der Vertrag. Deshalb schließen wir den AVV vor dem ersten Zugang zur Website und nicht am Tag des Vorfalls. Für die Meldung hilft, was in den ersten Schritten meiner Arbeit entsteht: Zeitpunkt der Entdeckung, Umfang der betroffenen Dateien und Tabellen und das ermittelte Einfallstor. Den vollständigen Bericht mit der Ursache erhalten Sie schriftlich.
Fällt Ihr Unternehmen unter NIS2 oder DORA, können die Meldepflichten weiter reichen als die DSGVO. Die Vorbereitung einer WordPress-Infrastruktur auf diese Anforderungen umfasst das Readiness-Audit für NIS2 und DORA.
Bereinigen, zurückspielen oder ersetzen
Die Wahl hängt davon ab, wann die Infektion begann und was ihre Quelle ist.
Sie haben ein Backup, das sicher älter ist als die Infektion, und das Einfallstor ist bekannt.
Ich spiele dieses Backup auf einer Arbeitskopie zurück, schließe das Einfallstor und deploye erst dann. Inhalte und Bestellungen seit dem Datum des Backups müssen separat übertragen werden.
Sie wissen nicht, wann die Infektion begann, oder alle Backups sind jünger als sie.
Ich bereinige die Website auf einer Kopie: Dateien, Datenbank, Konten, Cron-Aufgaben, Core und Plugins aus sauberen Quellen.
Die Quelle ist ein Theme oder Plugin, das niemand mehr weiterentwickelt.
Ich entferne es oder schlage Ersatz vor. Braucht der Ersatz neuen Code, bekommt er ein eigenes Angebot.
Die Website läuft auf einer CMS-Version ohne Sicherheitssupport.
Die Website läuft nach dem Hack nicht, und Sie haben keinen Wartungsvertrag.
Nichts deutet auf einen Hack hin, aber Sie möchten wissen, ob die Website sauber ist.
WordPress-Sicherheitsaudit: Bericht innerhalb von 5 Werktagen, nach Prioritäten geordnet.
Einen Hack erkennen, bevor Google es tut
Die Warnung in den Suchergebnissen von Google ist ein spätes Symptom. Vorher hinterlässt ein Hack Spuren in den Dateien und in der Datenbank. In der Wartung vergleiche ich Core-, Plugin- und Theme-Dateien mit den Prüfsummen aus offiziellen Quellen (wp checksum core, wp checksum plugin --all), so dass eine veränderte Datei innerhalb eines Tages auffällt. Der Malware-Scan sucht bekannte Muster von Schadcode, und die monatliche Prüfung der Administratorkonten findet Konten, die niemand angelegt hat.
Die zweite Quelle sind Schwachstellendatenbanken, unter anderem Patchstack und WPScan. Erscheint eine Lücke in einem Plugin, das auf Ihrer Website läuft, aktualisiere ich es außerhalb des Wochenzyklus. Das schließt das Einfallstor, bevor jemand es nutzt.
Code-Korrekturen nach dem Hack
War das Einfallstor eigener Code der Website, etwa ein Formular in einem für das Unternehmen geschriebenen Plugin oder eine Funktion im Theme, die Eingaben nicht geprüft hat, korrigiere ich ihn als Teil der Absicherung gegen das ermittelte Einfallstor. Die Korrektur landet in der Versionsverwaltung, und den Code prüfe ich mit PHP_CodeSniffer und den Regeln der WordPress Coding Standards, die auch Sicherheitsregeln enthalten, sowie mit statischer Analyse durch PHPStan. In Systemen außerhalb von WordPress halte ich mich an PSR-12. Vor dem Deployment sehe ich die Änderung noch einmal durch, getrennt vom Schreiben. Verlangt die Korrektur den Umbau eines größeren Codeteils, beschreibe und kalkuliere ich ihn separat.
Was Sie nach der Bereinigung erhalten
Nach der Bereinigung erhalten Sie eine schriftliche Beschreibung: wie es zum Hack kam, was in den Dateien und in der Datenbank geändert wurde, welche Zugänge erneuert wurden und welchen Schutz ich gegen das ermittelte Einfallstor ergänzt habe. Diese Beschreibung hilft bei einer Meldung an die Datenschutzbehörde, falls Sie sie einreichen, und im Gespräch mit dem Hoster. Die bereinigte Version ist in einem Schritt mit Möglichkeit zur Rücknahme eingespielt, und eine Kopie der infizierten Version bleibt als Beweis erhalten.
Soll nach der Bereinigung jemand dauerhaft auf die Website achten, geht sie in die normale Wartung über.
Was ich nach einem Hack nicht verspreche
Ich gebe keine Garantie, dass die Website nie wieder gehackt wird. Die Bereinigung entfernt den Schadcode und schließt das Einfallstor, das sich ermitteln ließ, aber in Plugins tauchen ständig neue Lücken auf. Ich garantiere auch keine Reparaturzeit: Sie hängt vom Umfang der Infektion ab, vom Zugang zum Hosting und davon, ob die Backups älter sind als die Infektion. Ein Datum für das Entfernen der Warnung durch Google verspreche ich nicht, weil Google die Überprüfung durchführt.
Zusagen kann ich die oben beschriebene Reihenfolge der Arbeit, das schriftliche Ergebnis der Diagnose vor der Bereinigung und den Bericht mit Ursache und Vorbeugung danach.
Wie Wartung das Risiko eines weiteren Hacks senkt
Im Rahmen der WordPress-Wartung erstelle ich täglich Backups und bewahre sie mindestens 30 Tage auf, scanne die Dateien auf Malware und prüfe ihre Integrität, und einmal im Monat sehe ich die Administratorkonten durch. Das Monitoring prüft die Erreichbarkeit alle 1 bis 5 Minuten und alarmiert mich, wenn die Website nicht antwortet. Findet der Scan etwas, isoliere ich die infizierten Teile, stelle eine saubere Version aus dem Backup wieder her, ergänze Schutz gegen das Einfallstor und beschreibe den Vorfall im Monatsbericht.
Dreißig Tage Backups zählen bei Hacks, die spät entdeckt werden. Ist die Infektion zwei Wochen alt, liegt in der Backup-Historie noch eine Version von davor. Das Infektionsdatum prüfe ich trotzdem, bevor ich etwas zurückspiele.
Ein veraltetes Plugin mit veröffentlichter Lücke ist ein offenes Einfallstor. Davor schützt ein regelmäßiger Update-Zyklus, den die Seite WordPress-Updates-Service beschreibt. Was die Wartung mit Scan und Backups kostet, steht auf der Seite WordPress-Wartung: Kosten.
Nächster Schritt, wenn die Website gerade infiziert ist: Löschen Sie nichts, sichern Sie Dateien und Datenbank, notieren Sie die Uhrzeit der Entdeckung und schreiben Sie mir mit der Adresse der Website und einer Beschreibung der Symptome.
