WordPress gehackt – was tun? Erkennen, sperren, sauber bereinigen

Ihre WordPress-Website leitet Besucher auf fremde Seiten um, der Hoster hat Dateien gesperrt oder Ihre E-Mails kommen plötzlich als unzustellbar zurück: Wenn WordPress gehackt wurde, entscheidet die Reihenfolge der nächsten Schritte. Wer zuerst Passwörter ändert und ein Sicherheits-Plugin laufen lässt, übersieht oft genau die Hintertür, über die der Angreifer eine Woche später wieder da ist.

Dieser Beitrag beschreibt, woran Sie einen Hack erkennen, was in den ersten 60 Minuten zu tun ist und wie eine saubere Bereinigung abläuft. Die Muster stammen aus Fällen, die wir 2026 selbst bereinigt haben. Namen lassen wir weg, die Technik dahinter ist bei den meisten Angriffen dieselbe.

Woran Sie erkennen, dass WordPress gehackt wurde

Weiterleitungen auf fremde Seiten oder eine Browser-Warnung sind eindeutig. In unseren Fällen waren die ersten Anzeichen aber meist unauffälliger:

• E-Mails an Kunden kommen als unzustellbar zurück, weil über den Webserver im Hintergrund Spam verschickt wird.
• Der Hoster sperrt Dateien, und die Startseite zeigt nur noch den Fehler 403 oder 500.
• Einzelne Unterseiten wie Impressum oder Datenschutz zeigen fremde Inhalte, während der Rest der Website normal aussieht.
• Der Malware-Scanner des Hosters oder ein Sicherheits-Plugin meldet verdächtige Dateien.

Sichtbare Symptome sind nur die Oberfläche. Was wir bei der Analyse dahinter gefunden haben, steht in der folgenden Übersicht.

Die ersten 60 Minuten: was zuerst, was danach

Die Reihenfolge ist wichtiger als die Geschwindigkeit. Die Grundschritte beschreibt auch die offizielle WordPress-Dokumentation in der FAQ „My site was hacked“. Aus unserer Arbeit ergibt sich diese Abfolge:

1. Festhalten, was Sie sehen. Notieren Sie Symptome und Uhrzeit, machen Sie Screenshots. Das spart später Stunden bei der Suche nach dem Einstieg.
2. Die Website sperren. Schalten Sie den Zugriff von außen ab, am zuverlässigsten über das Kundenmenü Ihres Hosters. Das schützt Ihre Besucher und unterbricht den Angreifer: Viele Hintertüren werden über einen normalen Seitenaufruf gesteuert, und in einem unserer Fälle erzeugte sich der Schadcode bei jedem Aufruf neu.
3. Den befallenen Zustand sichern. Kopieren Sie Dateien und Datenbank an einen Ort außerhalb des Webspace. Diese Kopie spielen Sie nicht zurück. Sie dient der Analyse und als Rückfallebene, falls bei der Bereinigung etwas verloren geht.
4. Zugänge ändern. Kundenmenü des Hosters, FTP und SSH, Datenbank, alle WordPress-Administratoren. Erst jetzt, weil eine aktive Hintertür neue Zugangsdaten sonst sofort wieder ausliest oder ein gelöschtes Konto neu anlegt.
5. Den Hoster informieren. Er sieht, ob vom Server Spam verschickt wird, und kann Protokolle bereitstellen.

Warum ein Sicherheits-Plugin allein nicht reicht

Scanner sind ein gutes Werkzeug für den ersten Überblick. Als einziges Mittel reichen sie nicht aus, und zwar aus vier Gründen, die wir alle selbst erlebt haben.

Datei-Scanner sehen keinen Code in der Datenbank. Auf 35 Websites eines Kunden lagen Code-Schnipsel in der Datenbank, die bei jedem Aufruf Programmcode von einem fremden Server nachladen konnten. Das zugehörige Plugin war deaktiviert und wirkte harmlos. Kein Datei-Scan hätte das gefunden.

Viele Scans prüfen nur Plugins und Themes. Das ist uns selbst passiert: Nach der ersten Bereinigung meldete unser Prüfskript die Websites als sauber. Drei Tage später war der Schadcode wieder da. Die Nester lagen in Upload-Ordnern und tief in den WordPress-Systemordnern, die das Skript nicht durchsucht hatte. Seitdem prüfen wir immer den gesamten Webspace.

Scanner melden auch Fehlalarme. In einem Fall sperrte der Scanner des Hosters eine saubere Originaldatei von WordPress, und die Startseite war danach nicht mehr erreichbar. Typische Suchmuster schlagen außerdem in regulären Plugins an. Jeder Fund muss geprüft werden.

Der Befall erneuert sich. Ein gut verstecktes Skript erzeugt die sichtbaren Schaddateien immer wieder neu. Wer nur das Symptom löscht, hat es beim nächsten Seitenaufruf zurück.

So läuft eine saubere Bereinigung ab

1. Den gesamten Webspace erfassen. Alle Installationen, Unterordner, Subdomains und alten Kopien. Bei einem Kunden standen 22 Websites zunächst nicht auf unserer Liste, 20 davon waren befallen.
2. Den WordPress-Kern gegen die offiziellen Prüfsummen vergleichen. Das ist die schnellste belastbare Aussage, ob in den Systemordnern Dateien verändert oder hinzugefügt wurden.
3. Plugins und Themes durch frische Originale ersetzen, statt jede Datei einzeln zu beurteilen.
4. Uploads und alle übrigen Ordner auf ausführbare Dateien und getarnte Skripte prüfen.
5. Die Datenbank prüfen: Benutzer, Code-Snippets, Einstellungen, Liste der aktiven Plugins.
6. Verdächtiges in Quarantäne verschieben statt löschen, an einen Ort, der von außen nicht erreichbar ist. So bleibt Material für die Analyse, und ein Fehlalarm lässt sich zurückholen.
7. Leere Ordner des Angreifers entfernen. Bleiben sie liegen, zeigen die betroffenen Seiten weiter einen Fehler.
8. Zugänge und die Sicherheitsschlüssel in der Konfiguration erneuern. Damit werden alle angemeldeten Sitzungen ungültig, auch die des Angreifers.
9. Erst dann aktualisieren und wieder online gehen. Danach prüfen wir nach einigen Tagen und nach einer Woche erneut.

Die Schritte 2 bis 6 setzen Zugriff per SSH oder SFTP und Erfahrung mit dem Dateisystem voraus. Wer hier unsicher ist, richtet leicht mehr Schaden an als der Angreifer. In dem Fall ist fachliche Hilfe der kürzere Weg: Wir übernehmen das als Projekt WordPress-Malware entfernen.

Die Ursache finden, sonst kommt der Angreifer wieder

Eine bereinigte Website mit offener Lücke ist nach kurzer Zeit wieder befallen. In unseren Fällen gab es vier Einstiege:

• Veraltete Plugins mit bekannter Lücke. Ein Slider-Plugin und ein Captcha-Plugin. Für beide gab es längst ein Update.
• Altlasten im selben Webspace. Ein altes Content-Management-System von 2010, vergessene Testinstallationen und Datenbank-Werkzeuge lagen neben der gepflegten Website.
• Übernommener Code. Code-Schnipsel aus einem zentralen Rollout, die Programmcode von einem anderen Server nachladen durften.
• Ein übernommenes Administrator-Konto. Über das Konto wurde ein Dateimanager-Plugin hochgeladen. Eine Minute später lag die erste Hintertür auf dem Server.

Den letzten Fall haben wir nur aufklären können, weil das Sicherheits-Plugin jede Anmeldung und jeden Plugin-Upload protokolliert hatte. Ohne Protokolle bleibt die Ursache oft eine Vermutung.

Backup einspielen oder neu aufsetzen?

Ein Backup hilft nur, wenn es sicher aus der Zeit vor dem Einbruch stammt. Bei einer Verlags-Website empfahl der Hoster, den Stand von vor einigen Wochen einzuspielen. Das fremde Administrator-Konto stand aber seit vier Jahren in der Datenbank. Das Backup hätte es zurückgebracht.

Ein Neuaufbau ist die bessere Wahl, wenn sich die Quelle der Neuinfektion nicht finden lässt, wenn der Angreifer Zugriff auf die Kommandozeile des Servers hatte oder wenn im Webspace über Jahre Altlasten gewachsen sind. Bei der Verlags-Website lief auf dem Server ein fremdes Programm im Benutzerkonto des Hostings, der Angreifer hatte also mehr als nur Zugriff auf WordPress. Dort lautet unsere Empfehlung Neuaufbau. Inhalte übernimmt man dabei über die Export-Funktion von WordPress, nicht über eine Kopie der Datenbank.

Nach der Bereinigung absichern

• WordPress, Plugins und Themes aktuell halten. Warum das die wirksamste Maßnahme ist, steht im Beitrag über Updates und Backups.
• Im Upload-Ordner die Ausführung von PHP unterbinden.
• Zwei-Faktor-Anmeldung für alle Administratoren einrichten.
• Nicht benötigte Plugins, alte Installationen und Testkopien entfernen.
• Backups außerhalb des Webspace aufbewahren.
• Den E-Mail-Versand erst nach der Bereinigung mit SPF, DKIM und DMARC absichern. Vorher würde der Spam des Angreifers als gültig signiert zugestellt.

Weitere Maßnahmen listet die WordPress-Dokumentation unter Hardening WordPress. Wer das nicht selbst im Blick behalten möchte, gibt es in die WordPress-Wartung.

Drei Fälle aus 2026

Über 60 Standort-Websites, eine Lücke

Ein Unternehmen betreibt für jeden Standort eine eigene Website auf derselben technischen Basis. Über ein veraltetes Slider-Plugin kamen die Angreifer auf fast alle Seiten. Der Schadcode lag in mehreren Schichten: in Upload-Ordnern, in doppelt verschachtelten Plugin-Ordnern, in der index.php und in der Datenbank. Die Bereinigung dauerte mehrere Tage und brauchte mehrere Durchgänge.

Verlags-Website mit vier Jahre altem Fremdzugang

Der Scanner des Hosters meldete 34 Funde und sperrte Dateien. Dahinter stand ein Administrator-Konto, das seit 2022 existierte und über Reste einer alten Installation neben WordPress angelegt worden war. Wir haben rund 11 GB Altlasten in Quarantäne verschoben und die Website gehärtet.

Gastronomie-Website verschickt Spam

Aufgefallen ist es, weil E-Mails an Gäste als unzustellbar zurückkamen. Auf dem Server lagen ein schreibgeschütztes Must-Use-Plugin, zwei Plugins mit unauffälligen Namen und ein Administrator-Konto, das in der Benutzerliste nicht auftauchte.

Häufige Fragen

Woran erkenne ich, ob meine WordPress-Website gehackt wurde?

Typische Zeichen sind Weiterleitungen auf fremde Seiten, gesperrte Dateien, Fehler 403 oder 500, zurückkommende E-Mails und Administrator-Konten, die niemand angelegt hat. Sicherheit gibt erst ein Blick ins Dateisystem und in die Datenbank.

Reicht es, ein Sicherheits-Plugin scannen zu lassen?

Nein. Datei-Scanner finden keinen Schadcode in der Datenbank, prüfen oft nicht alle Ordner und melden Fehlalarme. Ein Scan ist ein Anfang, ersetzt aber nicht die Prüfung des gesamten Webspace.

Soll ich einfach ein Backup einspielen?

Nur wenn das Backup sicher aus der Zeit vor dem Einbruch stammt. Angreifer sind oft Wochen oder Jahre unbemerkt im System. Ein zu junges Backup bringt die Hintertür zurück.

Wie lange dauert eine Bereinigung?

Bei einer einzelnen Website wenige Stunden bis einen Tag. Bei vielen Installationen im selben Webspace oder mehrschichtigem Befall mehrere Tage, dazu kommen Nachkontrollen in den Wochen danach.

Muss ich meine Kunden informieren?

Wenn personenbezogene Daten betroffen sein können, etwa aus einem Shop, aus Kundenkonten oder Kontaktformularen, kann eine Meldepflicht nach Art. 33 DSGVO bestehen. Die Frist beträgt 72 Stunden. Klären Sie das mit Ihrem Datenschutzbeauftragten.

Kann der Hack nach der Bereinigung wiederkommen?

Ja, wenn die Ursache offen bleibt oder eine Hintertür übersehen wurde. Deshalb gehören die Suche nach dem Einstieg und mehrere Nachkontrollen zur Bereinigung dazu.