WordPress gehackt — was tun? Neun Schritte in Reihenfolge

Neun Schritte, und die Reihenfolge ist der Inhalt dieses Beitrags:

1. Seite vom Netz nehmen und den Hoster informieren
2. Den befallenen Zustand sichern und notieren
3. Den eigenen Rechner prüfen, dann alle Zugänge wechseln
4. Das Ausmaß feststellen
5. Einen sauberen Stand herstellen
6. Die Lücke finden und schließen
7. Google informieren, wenn Google gewarnt hat
8. Prüfen, ob die DSGVO eine Meldung verlangt
9. Härten und ein paar Wochen genau hinsehen

Wer anders herum vorgeht, putzt mit offener Tür: Der Angreifer hat seine Zugangsdaten noch und ist in ein paar Tagen wieder drin. Der häufigste Fehler ist Eile an der falschen Stelle. Die verdächtige Datei sofort löschen, die Sicherung von gestern zurückspielen, das eigene Passwort ändern und weitermachen fühlt sich nach Handeln an und lässt fast immer etwas zurück: ein eingeschleustes Administratorkonto, eine Hintertür in einem Ordner, in den niemand schaut, eine Sicherung, die schon befallen war.

Die Schritte folgen der Anleitung von WordPress.org für gehackte Seiten und den Leitfäden von Google für gehackte Websites. Die Befehle sind WP-CLI und laufen im Verzeichnis der Installation auf dem Server. Wer keinen Shell-Zugang hat, findet die meisten Prüfungen auch im Kundenmenü des Hosters oder im Backend; dann dauert es länger.

WordPress.org nennt in seiner Hilfe eindeutige Anzeichen: Google oder Bing warnt vor der Seite, der Hoster hat sie gesperrt, Besucher melden Warnungen ihres Virenscanners, jemand beschwert sich, dass von der Seite Angriffe ausgehen, oder es passiert etwas, das niemand veranlasst hat, etwa neue Benutzer. Dazu kommen die leiseren Fälle: fremdsprachige Seiten in der site:-Suche, Weiterleitungen nur für Besucher aus der Google-Suche, E-Mails der Domain, die plötzlich im Spam landen. Ist noch unklar, ob überhaupt etwas passiert ist, stehen die sechs Prüfungen dafür im nächsten Abschnitt. Die neun Schritte beginnen dort, wo der Befund feststeht.

So erkennst du, ob die Seite gehackt ist#

Zwei Abrufe derselben Seite, einmal als gewöhnlicher Besucher, einmal so, wie Google kommt, und dann der Vergleich:

curl -sL https://deine-domain.at/ -o normal.html
curl -sL https://deine-domain.at/ -o google.html \
  -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  -e "https://www.google.com/"
diff normal.html google.html

Bleibt diff bis auf Zufallswerte wie Nonces oder Zeitstempel stumm, liefert der Server beiden dasselbe. Zeigt er zusätzliche Verweise, Weiterleitungen oder ein Skript, das nur in google.html steht, hast du den Befund, den du im Browser nie gesehen hättest.

Denn das ist der Normalfall bei einem Angriff auf eine Website: Wer sie übernimmt, will sie nicht kaputtmachen, er will sie benutzen. Ein sichtbar verunstalteter Auftritt wird sofort repariert. Einer, der nur für Google und nur für Besucher aus der Suche anders aussieht, bleibt Monate unentdeckt. Du klickst dich durch, alles normal, und trotzdem sind die Zugriffe eingebrochen oder in der Suche steht unter deinem Namen etwas, das du nie geschrieben hast.

Warum du es selbst nicht siehst#

Die Technik ist einfach: Der Server liefert unterschiedliche Inhalte, je nachdem wer fragt. Google führt das in seinen Spam-Richtlinien unter „gehackte Inhalte“ auf: eingeschleuster Code, der Nutzer je nach Referrer, User-Agent oder Gerät weiterleitet.

Ein angemeldeter Redakteur bekommt die echte Seite. Wer die Adresse direkt eintippt, ebenfalls. Wer aber aus der Google-Suche kommt oder sich als Suchmaschinen-Crawler ausweist, bekommt etwas anderes: eingeschobene Verweise, fremdsprachige Unterseiten, Weiterleitungen auf Verkaufsangebote. Deshalb bringt es nichts, den eigenen Auftritt anzusehen. Man muss ihn so ansehen, wie Google ihn sieht.

Die sechs Prüfungen#

1. Suche nach dir selbst, eingeschränkt auf die Domain. Der site:-Operator in der Google-Suche listet, was tatsächlich im Index steht. Tauchen dort Seiten auf, die du nie angelegt hast, oft mit Begriffen aus ganz anderen Branchen oder in fremder Sprache, ist das der eindeutigste Befund, den es gibt.

2. Search Console, Bericht „Sicherheitsprobleme“. Google meldet dort gehackte Inhalte, Schadsoftware und Social Engineering. Ein leerer Bericht ist kein Freispruch, ein voller ist ein Alarm. Sieh im selben Zug unter „Manuelle Maßnahmen“ nach. Ob Google die Seite schon als gefährlich führt, zeigt für jede Adresse auch ohne Search Console der Safe-Browsing-Status im Transparenzbericht.

3. Die Seite ohne Browser abrufen, mit den beiden Befehlen von oben. Ein direkter Abruf zeigt das ausgelieferte Markup, bevor ein Skript es verändern konnte. Fremde Verweise am Ende des Markups sind ein klassisches Muster, Unterschiede zwischen normal.html und google.html der direkte Beweis.

4. Die URL-Prüfung in der Search Console. Sie zeigt unter „Gecrawlte Seite anzeigen“, was Google tatsächlich bekommen hat. Was dort steht und was du siehst, muss dasselbe sein. Wie man die Felder dieses Werkzeugs liest, steht in Die URL-Prüfung der Search Console lesen.

5. Nach Änderungen im Dateibestand suchen. Dateien mit einem Änderungsdatum, an dem niemand gearbeitet hat. Neue Dateien in Verzeichnissen, in denen es keine geben sollte, besonders in Upload-Ordnern, wo nur Bilder liegen dürfen. Die Befehle dafür stehen unten in Schritt 4.

6. Die Benutzerliste. Ein zusätzliches Administratorkonto, das niemand angelegt hat, ist selten ein Versehen.

Ein Scan von außen zählt auch, welche fremden Skript-Quellen eine Seite lädt. Für www.cyberscale.io ist es am 03.10.2026 genau eine (der Zähler cloud.umami.is); taucht dort plötzlich eine zweite auf, die niemand eingebaut hat, ist das Prüfung 3 mit Werkzeug.

Woran man den Zeitpunkt festmacht#

Wenn die Zugriffe eingebrochen sind, hilft die Search Console beim Datieren: Der Verlauf der Impressionen zeigt oft einen scharfen Knick. Der liegt selten am Tag des Angriffs, sondern an dem Tag, an dem Google die veränderten Seiten neu bewertet hat.

Das ist für die Aufräumarbeit wichtig: Eine Sicherung von vor dem Knick kann bereits kompromittiert sein. Dieser Zeitpunkt entscheidet in Schritt 5, welcher Sicherung du noch trauen kannst.

1. Die Seite vom Netz nehmen und den Hoster informieren#

Google rät im Leitfaden für gehackte Seiten, die Seite ganz offline zu nehmen, damit sie keine Schadsoftware mehr an Besucher ausliefert und der Angreifer während der Arbeit weniger dazwischenfunkt. Wichtig ist das Wie: Die Antwort soll von außerhalb der befallenen Installation kommen, etwa als Statuscode 503 von einer Wartungsseite, die der Hoster vor die Seite schaltet. Ein Wartungsplugin innerhalb der befallenen Installation ist dafür ungeeignet, weil es im selben Code läuft, den der Angreifer kontrolliert.

Ein Eintrag in der robots.txt reicht nicht. Er hält nur Suchmaschinen ab, Besucher bekommen den Schadcode weiterhin. Und dass die Seite ein paar Tage offline ist, schadet laut Google dem späteren Ranking voraussichtlich nicht.

Im selben Zug gehört der Hoster informiert. Auf einem geteilten Server kann der Angriff mehr betroffen haben als die eigene Seite, und der Hoster hat die Zugriffsprotokolle, die du für Schritt 6 brauchst. Frag ausdrücklich danach, wie lange er sie aufbewahrt; viele löschen sie nach wenigen Tagen.

2. Den befallenen Zustand sichern und notieren#

Bevor irgendetwas gelöscht wird, kommt eine vollständige Kopie auf die Seite: Dateien und Datenbank, so wie sie jetzt sind. WordPress.org empfiehlt diesen „Schnappschuss“ ausdrücklich, auch wenn er befallen ist. Er ist die einzige Grundlage, um später zu verstehen, was passiert ist, und der Rückfall, falls beim Aufräumen etwas Wichtiges verloren geht.

wp db export ~/vorfall-$(date +%F)-db.sql
tar -czf ~/vorfall-$(date +%F)-dateien.tar.gz -C /pfad/zu/wordpress .

Beide Dateien gehören danach weg vom Server, auf den eigenen Rechner oder in einen getrennten Speicher.

Dann aufschreiben, ehe es verschwimmt: was du gesehen hast, wann du es bemerkt hast (mit Uhrzeit), und was in den Tagen davor geändert wurde, etwa ein neues Plugin, eine Theme-Anpassung, ein neuer Benutzer. WordPress.org nennt das die Grundlage eines Vorfallberichts. Der Zeitpunkt des Bemerkens ist auch der, ab dem eine mögliche Meldefrist nach der DSGVO läuft (Schritt 8).

3. Den eigenen Rechner prüfen, dann alle Zugänge wechseln#

Die Reihenfolge ist Absicht. WordPress.org weist darauf hin, dass ein Angriff oft auf dem Rechner des Betreibers beginnt: Ein Schadprogramm liest FTP- und Admin-Zugangsdaten mit. Wer auf einem solchen Rechner neue Passwörter vergibt, liefert sie gleich mit. Also zuerst einen vollständigen Virenscan auf jedem Gerät, von dem aus die Seite verwaltet wird.

Dann jeden Zugang neu, nicht nur das WordPress-Passwort. WordPress.org zählt auf: FTP oder SFTP, wp-admin, das Kundenmenü des Hosters und die Datenbank, und zwar für alle Personen, die Zugang haben. Dazu das E-Mail-Postfach, an das WordPress Passwort-Links schickt; wer das kontrolliert, setzt jedes Passwort zurück.

# Wer ist Administrator? Jede Zeile muss jemandem gehören, den du kennst.
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

# Neue Passwörter für alle Konten, die Betroffenen bekommen eine E-Mail
wp user reset-password $(wp user list --field=ID)

# Neue Schlüssel in der wp-config.php: wirft alle angemeldeten Sitzungen hinaus
wp config shuffle-salts

Ein fremdes Administratorkonto zuerst notieren (Name, Anlagedatum), dann löschen. Das Anlagedatum grenzt oft ein, seit wann der Angreifer drin war. Nach einem neuen Datenbank-Passwort beim Hoster muss es auch in der wp-config.php nachgezogen werden, sonst steht die Seite mit „Fehler beim Aufbau der Datenbankverbindung“ da. Anwendungspasswörter unter „Benutzer → Profil“ gehören ebenfalls durchgesehen: Sie gelten für Programme weiter, auch wenn das Konto ein neues Passwort hat.

4. Das Ausmaß feststellen#

Jetzt wird gesucht. Der schnellste Befund ist der Vergleich mit den Originaldateien von WordPress.org:

# Kern: veränderte Dateien und, mit --include-root, Fremdes im Hauptverzeichnis
wp core verify-checksums --include-root

# Plugins aus dem Verzeichnis auf WordPress.org (gekaufte fallen durchs Raster)
wp plugin verify-checksums --all

Danach die Stellen, an denen sich Schadcode gern versteckt:

# PHP-Dateien im Upload-Ordner: dort gehören nur Medien hin
find wp-content/uploads -type f -name "*.php"

# Alles, was in den letzten 14 Tagen geändert wurde
find . -type f -name "*.php" -mtime -14 -printf "%TY-%Tm-%Td %p\n" | sort

# Must-Use-Plugins und Drop-ins laden ohne Eintrag in der Plugin-Liste
wp plugin list --status=must-use
wp plugin list --status=dropin

# Typische Verschleierung im Code
grep -rlE "eval\(|base64_decode\(|gzinflate\(|str_rot13\(" wp-content --include=*.php

# Geplante Aufgaben, die niemand angelegt hat
wp cron event list --fields=hook,next_run_relative,recurrence

base64_decode steht auch in harmlosen Plugins. Ein Treffer ist ein Grund hinzusehen, kein Urteil. Verdächtig ist er, wenn er in einer Datei mit sinnlosem Namen steht, in einer einzigen langen Zeile oder am Anfang einer sonst normalen Datei.

Die Datenbank kommt dazu, weil eingeschleuste Skripte oft gar nicht in Dateien liegen, sondern in Beiträgen, Widgets oder Optionen:

wp option get siteurl
wp option get home
wp db search "<script" --all-tables-with-prefix

Und die .htaccess sowie die wp-config.php von Hand ansehen: Weiterleitungen nur für Besucher von Google und zusätzliche include-Zeilen sind dort klassische Muster. Wie die unveränderte .htaccess aussieht, steht in Die Standard-.htaccess von WordPress.

5. Einen sauberen Stand herstellen#

Hier fällt die wichtigste Entscheidung: zurückspielen oder neu aufsetzen. Eine Sicherung hilft nur, wenn sie nachweislich älter ist als der Einbruch. Den Zeitpunkt grenzen das Anlagedatum eines fremden Kontos, die Änderungsdaten aus Schritt 4 und der Knick in der Search Console ein; wer keinen sicheren Zeitpunkt hat, kann der jüngsten Sicherung nicht trauen.

Ohne verlässliche Sicherung wird neu aufgesetzt, Teil für Teil, mit denselben Versionen, die vorher liefen. WordPress.org warnt, dass eine andere Version die Seite leicht unbenutzbar macht. Und ausdrücklich nicht über die Neuinstallation im Backend: Die läuft im befallenen WordPress selbst.

# Kern: alte Verzeichnisse weg, dieselbe Version frisch von WordPress.org
VERSION=$(wp core version)
rm -rf wp-admin wp-includes
wp core download --version=$VERSION --skip-content --force

# Plugins aus dem Verzeichnis: frisch und in derselben Version
wp plugin install <slug> --version=<version> --force

Gekaufte Plugins und Themes kommen frisch aus dem Kundenkonto beim Hersteller, nicht aus der alten Installation. Was nicht mehr gebraucht wird, kommt gar nicht zurück. Aus wp-content/uploads werden nur Medien übernommen. Die wp-config.php am besten neu schreiben und die Werte von Hand übertragen, statt die alte Datei zu behalten.

6. Die Lücke finden und schließen#

Ein aufgeräumtes WordPress mit derselben Lücke ist in ein paar Tagen wieder befallen. Google nennt als häufigste Wege hinein: einen verseuchten Rechner des Betreibers, schwache oder mehrfach verwendete Passwörter, veraltete Software und nachlässigen Code. Bei WordPress heißt veraltete Software fast immer ein Plugin; die Zahlen dazu stehen in WordPress-Sicherheit prüfen.

Wie sichtbar der Rückstand von außen ist, zeigt eine eigene Zählung vom 03.10.2026: Von 131 Tiroler Startseiten, die ich per curl abgerufen habe (in eigener Sache, Betriebe und Tourismusverbände aus meiner Akquise-Liste, nur Summen), laufen 22 erkennbar auf WordPress, und 11 davon nennen im Generator-Tag ihre Version. Acht stehen auf 7.1.2, zwei auf 7.0.6, eine auf 6.7.9. Ob auf den drei älteren die Sicherheitskorrekturen noch laufen, sieht man von außen nicht; die Versionsnummer sagt nur, dass dort seit mindestens einer Hauptversion niemand aktualisiert hat. Ein Angreifer liest dieselbe Zeile.

Die Zugriffsprotokolle des Hosters zeigen oft den genauen Weg: eine Anfrage an eine Plugin-Datei kurz vor dem ersten verdächtigen Änderungsdatum, eine Reihe von Anmeldeversuchen, ein Upload. Das Plugin, über das es lief, wird aktualisiert oder, wenn es keine Korrektur gibt oder es nicht mehr gepflegt wird, ersetzt. Woran man ein gepflegtes Plugin erkennt, bevor es auf die Seite kommt, steht in WordPress-Plugins prüfen.

7. Google informieren, wenn Google gewarnt hat#

Ob Google die Seite als gefährlich führt, zeigt der Safe-Browsing-Status im Transparenzbericht für jede Adresse, auch ohne Search Console. Für die eigene Domain steht der genaue Befund in der Search Console im Bericht „Sicherheitsprobleme“, daneben unter „Manuelle Maßnahmen“.

Die Überprüfung wird dort angefordert, aber erst, wenn die Seite sauber und wieder online ist. Google warnt, dass eine verfrühte Anfrage die Warnung nur verlängert, und bittet um eine kurze Beschreibung, was bereinigt und welche Lücke geschlossen wurde. Zur Dauer nennt Google selbst: Phishing etwa einen Tag, Schadsoftware einige Tage, gehackte Inhalte mit Spam bis zu mehrere Wochen.

Seiten, die der Angreifer angelegt hat, sollen nach dem Aufräumen mit 404 oder 410 antworten. Wer sie schneller aus der Suche haben will, nutzt das Werkzeug „Entfernen“ in der Search Console.

Der Schaden bei der Sichtbarkeit verschwindet nicht mit dem Aufräumen. Google muss die Seiten neu abrufen und neu bewerten, und das dauert Wochen. In dieser Zeit sieht es so aus, als hätte das Aufräumen nichts gebracht.

8. Prüfen, ob die DSGVO eine Meldung verlangt#

Liegen auf der Seite personenbezogene Daten (Kundenkonten, Bestellungen in WooCommerce, Anfragen aus Formularen, eine Newsletter-Liste), muss geklärt werden, ob der Angreifer darauf Zugriff hatte. Ist das der Fall, ist es eine Verletzung des Schutzes personenbezogener Daten.

Art. 33 DSGVO verlangt dann eine Meldung an die Aufsichtsbehörde, unverzüglich und möglichst binnen 72 Stunden, nachdem die Verletzung bekannt wurde. Die Meldung kann unterbleiben, wenn die Verletzung voraussichtlich zu keinem Risiko für die Rechte und Freiheiten der Betroffenen führt. In Österreich ist das die Datenschutzbehörde, die dafür ein Online-Formular bereitstellt. Bei voraussichtlich hohem Risiko sind nach Art. 34 auch die Betroffenen selbst zu benachrichtigen. Dokumentiert werden muss der Vorfall nach Art. 33 Abs. 5 in jedem Fall, auch wenn keine Meldung nötig war; die Notizen aus Schritt 2 sind der Anfang davon.

Ob ein konkreter Vorfall meldepflichtig ist, ist eine Einzelfallfrage. Im Zweifel gehört sie zu jemandem mit rechtlicher Zulassung, und zwar innerhalb der Frist, nicht danach.

9. Härten und ein paar Wochen genau hinsehen#

Nach dem Aufräumen kommt das, was den nächsten Einbruch verhindern soll: Zwei-Faktor-Anmeldung für jeden Administrator, Plugins mit automatischen Updates oder fester Wartung, ungenutzte Plugins gelöscht, DISALLOW_FILE_EDIT in der wp-config.php, Sicherungen an einem Ort, den ein Angreifer mit den Zugangsdaten der Seite nicht überschreiben kann. Die vollständige Liste mit Befehlen steht in WordPress-Sicherheit prüfen. Was zusätzlich vorbeugt und zehn Minuten kostet: eine Content-Security-Policy, die fremde Skripte gar nicht erst zulässt; der Einstieg steht in CSP Report-Only.

In den Wochen danach lohnt der wiederholte Blick auf drei Dinge: die Administratorliste, die Prüfsummen aus Schritt 4 und die site:-Suche. Wer seine E-Mails über denselben Server verschickt, sollte zusätzlich mit dem Blacklist-Check prüfen, ob dessen Adresse auf einer Sperrliste gelandet ist; WordPress.org nennt das als eine der ernsteren Folgen, wenn eine Seite für Spam missbraucht wurde.

So sieht ein sauberes Ergebnis aus, hier für die eigene Domain am 03.10.2026: Mail- und Webserver auf keiner der fünf Listen.

Fünf Abkürzungen, die den Angreifer drin lassen#

Ein Sicherheitsplugin installieren und auf „Bereinigen“ drücken. Ein Scanner im befallenen WordPress läuft im selben Code wie die Schadsoftware; er findet Bekanntes und übersieht, was sich gut versteckt. WordPress.org empfiehlt, Scanner innerhalb der Seite und von außen zu kombinieren, als Hinweisgeber, nicht als Ersatz für den Neuaufbau aus Schritt 5.

Nur die auffällige Datei löschen. Die sichtbare Datei ist meist die Nutzlast. Die Hintertür, die sie wieder anlegt, liegt woanders: in einem Must-Use-Plugin, einer Option in der Datenbank, einer geplanten Aufgabe.

Die Sicherung von gestern zurückspielen, ohne den Zeitpunkt zu kennen. Angreifer warten oft, bevor sie die Seite benutzen. Die Sicherung von gestern kann die Hintertür schon enthalten.

Nur das eigene WordPress-Passwort ändern. Solange Datenbank, SFTP, Hoster-Konto und die Sitzungen gleich bleiben, ändert das für den Angreifer nichts.

Die Überprüfung bei Google sofort anfordern. Ist die Seite dann noch nicht sauber, wird die Anfrage abgelehnt, und die Warnung bleibt länger stehen.

Häufige Fragen#

Wenn du es nicht selbst machen willst#

In eigener Sache: cyberscale bin ich, Stefan Haun aus Tirol, und das hier ist eine meiner Leistungen. Wer keinen Shell-Zugang hat, keine Zeit oder nicht sicher ist, ob alles erwischt wurde, kann die Arbeit abgeben.

Die Bereinigung selbst hat keinen Festpreis, weil niemand vorher weiß, wie tief es geht. Ich rechne sie nach Aufwand ab, 60 € pro Stunde, und wir sprechen den Rahmen vorher ab. Danach hält die WordPress-Wartung für 49 € im Monat die Seite aktuell und überwacht sie. Wer nur wissen will, wie es um eine Seite steht, die (noch) nicht brennt, bekommt mit dem Sicherheits-Check für 290 € einen Bericht nach Dringlichkeit, inklusive Plugin-Stand; alle Pakete stehen unter Cybersecurity. Anfragen gehen über die Kontaktseite.

Einen ersten Blick von außen gibt es kostenlos: Der Security-Scan prüft ohne Anmeldung unter anderem, ob Dateien wie /.env oder /backup.sql offen liegen, welche fremden Skripte die Seite lädt und wie die Security-Header stehen. WordPress-Version und Plugins prüft er nicht; dafür sind die Befehle aus Schritt 4 da.

Die meiste Zeit kostet nicht das Löschen, sondern das Suchen und das Neuaufsetzen, und genau das wird übersprungen, wenn die Seite schnell wieder laufen soll. Wer einen der neun Schritte weglässt, macht die Arbeit in ein paar Wochen ein zweites Mal.

Stand 05.10.2026. An diesem Tag hat der Beitrag den bisherigen Beitrag „Gehackte Website erkennen“ als ersten Abschnitt aufgenommen; dessen Adresse leitet hierher. Quellen abgerufen am 03.10.2026, die curl-Befehle an der eigenen Domain nachgestellt; die WP-CLI-Befehle entsprechen der verlinkten Referenz, die Zählung der 131 Tiroler Startseiten stammt vom 03.10.2026.