WordPress gehackt: die ersten Schritte

• Löschen Sie keine Dateien. Sie sind Beweismittel, und falls personenbezogene Daten abgeflossen sein könnten, rät Google, zuerst Ihre rechtlichen Pflichten zu klären.
• Spielen Sie kein altes Backup ein, solange die Lücke offen ist.
• Nutzen Sie nicht die Neuinstallation im WordPress-Backend. Die WordPress-FAQ warnt, dass sie oft nur vorhandene Dateien überschreibt, Hacks aber oft neue anlegen.
• Beantragen Sie noch keine Überprüfung bei Google.
• Rufen Sie infizierte Seiten gar nicht im Browser auf: Malware verbreitet sich oft über Schwachstellen in Browsern. Sehen Sie sie sich stattdessen mit dem URL-Prüftool der Search Console oder mit cURL an (Search-Console-Hilfe).
• Melden Sie sich nicht von einem Computer an, der infiziert sein könnte.

Schreiben Sie stattdessen auf, was Sie sehen, wann Sie es bemerkt haben (mit Zeitzone) und was sich zuletzt geändert hat, etwa ein neues Plugin oder ein neuer Benutzer. Die WordPress-FAQ nennt die Dokumentation den ersten Schritt, und aus diesen Notizen wird Ihr Bericht über den Vorfall.

Googles Anleitung zum Isolieren einer Website rät, den Webserver zu stoppen oder die DNS-Einträge auf eine statische Seite auf einem anderen Server zu richten, die mit HTTP-Status 503 antwortet. Dieser 503 muss von außerhalb der gehackten Installation kommen. Ein Wartungsmodus-Plugin läuft im infizierten WordPress selbst, und eine Sperre in der robots.txt hält nur Suchmaschinen ab, keine Besucher:innen. Den 503 kann auch Ihr Hoster einrichten. Ihrem Ranking schadet eine vorübergehende Abschaltung während der Bereinigung laut Google wahrscheinlich nicht.

Informieren Sie jetzt Ihren Hoster. Bei Shared Hosting kann der Hack über Ihre Seite hinausreichen, der Hoster kann seine anderen Kund:innen prüfen, und vielleicht hat er Ihr Konto schon gesperrt.

Der WordPress-Leitfaden zur Härtung ist deutlich: Keine Sicherheitsmaßnahme in WordPress oder auf dem Server hilft, wenn auf Ihrem Computer ein Keylogger läuft. Google empfiehlt mehrere seriöse Virenscanner auf jedem Computer, mit dem sich jemand als Administrator angemeldet hat. Ändern Sie dann von einem vertrauenswürdigen Gerät aus jedes Passwort, das Zugang zur Seite gibt:

• WordPress: zuerst alle Administratoren, dann alle anderen.
• Hosting-Panel, SFTP oder FTP und SSH.
• Datenbank-Benutzer: Tragen Sie das neue Passwort in die wp-config.php ein (DB_PASSWORD), sonst fällt die Seite aus.
• Das Postfach hinter der Admin-E-Mail-Adresse von WordPress: Dort landen die Links zum Zurücksetzen von Passwörtern.

Die Befehle in diesem Leitfaden brauchen SSH-Zugang mit WP-CLI. Nicht jedes Paket hat das: Bei World4You gibt es SSH nur in Webhosting Ultra, bei Hetzner erst ab Webhosting L. Ohne SSH prüfen Sie die Benutzerliste im Backend unter "Benutzer" oder in der Tabelle wp_users in phpMyAdmin und fügen neue Schlüssel aus dem WordPress-Schlüsselgenerator in die wp-config.php ein. Für die Sicherung weiter unten exportieren Sie die Datenbank mit phpMyAdmin und laden die Dateien per SFTP oder FTP herunter, oder Sie bitten Ihren Hoster um eine Kopie.

cd ~/public_html   # Ihr Web-Verzeichnis
wp user list --fields=ID,user_login,user_email,user_registered,roles --skip-plugins --skip-themes   # alle Konten: unbekannte notieren, erst nach der Sicherung unten löschen
wp config shuffle-salts                           # neue Schlüssel: alle werden abgemeldet

--skip-plugins --skip-themes verhindert, dass WP-CLI den Code der infizierten Plugins und Themes ausführt. Dateien in wp-content/mu-plugins werden trotzdem geladen, prüfen Sie diesen Ordner von Hand. Führen Sie wp nie als root aus.

Neue Sicherheitsschlüssel (Salts) beenden angemeldete Sitzungen, mehr nicht. Wer SFTP- oder Datenbankzugang oder eine Hintertür hat, bleibt drin. Prüfen Sie in jedem Benutzerprofil die Anwendungspasswörter: Sie sehen, wann und von welcher IP jedes zuletzt benutzt wurde, und können sie einzeln widerrufen. Schalten Sie für Administratoren die Zwei-Faktor-Anmeldung ein, etwa mit dem Plugin Two Factor von WordPress.org. Ist die Seite sauber, ändern Sie alle Passwörter noch einmal, wie es die WordPress-FAQ verlangt.

Bevor Sie etwas bereinigen, sichern Sie Dateien und Datenbank im jetzigen Zustand außerhalb des Web-Verzeichnisses und beschriften die Kopie als "infiziert":

cd ~                                   # der Ordner, in dem Ihr Web-Verzeichnis liegt
mkdir -p ~/spuren
wp db export ~/spuren/infiziert-$(date +%F).sql --path=public_html
tar czf ~/spuren/infiziert-dateien-$(date +%F).tar.gz public_html   # Ihr Web-Verzeichnis

Ohne SSH exportieren Sie die Datenbank in phpMyAdmin und laden alle Dateien per SFTP in einen lokalen Ordner "infiziert" herunter. Löschen Sie jetzt die unbekannten Konten, die Sie notiert haben, im Backend unter "Benutzer" oder mit wp user delete.

Bitten Sie Ihren Hoster um die Zugriffs- und Fehlerprotokolle. Sie zeigen IP-Adresse und Uhrzeit des Angreifers und was er getan haben könnte.

Dann suchen Sie das früheste Anzeichen des Hacks. Der Bericht "Sicherheitsprobleme" in der Search Console nennt das Datum, an dem Google ihn zuerst erkannt hat. Mehr verraten Protokolle und Änderungsdaten der Dateien. Das Beispiel aus dem Härtungs-Leitfaden: Mit wöchentlichen Sicherungen hat eine Seite, die am 1. Mai gehackt und erst am 12. Mai bemerkt wurde, noch saubere Backups aus der Zeit vor dem 1. Mai. Vergleichen Sie so ein Backup mit den aktuellen Dateien, wie in Googles Anleitung zu Malware:

diff -qr public_html/ backups/2026-10-01/

Mit dem Einspielen eines sauberen Backups ist es nicht getan. Installieren Sie die Updates, schließen Sie die Lücke und ändern Sie die Passwörter noch einmal.

Googles häufigste Ursachen und der Härtungs-Leitfaden nennen diese:

• Ein veraltetes WordPress, Plugin oder Theme mit veröffentlichter Sicherheitswarnung. Für WordPress selbst schreibt der Härtungs-Leitfaden: Sobald eine neue Version eine Lücke schließt, ist fast sicher öffentlich bekannt, wie man sie ausnutzt.
• Ein gestohlenes, erratenes oder mehrfach verwendetes Passwort.
• Ein infizierter Computer eines Administrators.
• Eine "kostenlose" Kopie eines kostenpflichtigen Plugins oder Themes. Beziehen Sie beides nur von WordPress.org oder von bekannten Anbietern.
• Plugins und Themes, die niemand mehr nutzt oder pflegt.

Es kann mehr als eine Lücke geben: Google warnt vor mehreren, voneinander unabhängigen Hacks. Laut CERT.at reicht es oft, die betroffene Software und vor allem alle Plugins und Themes zu aktualisieren. Finden Sie die Ursache nicht, halten Sie das in Ihrem Bericht über den Vorfall fest, statt zu raten. Aufräumen, ohne die Lücke zu schließen, verschafft nur Zeit.

Finden Sie heraus, welche WordPress-Version Ihre Seite verwendet (wp core version oder $wp_version in wp-includes/version.php), und laden Sie genau diese Version von wordpress.org herunter. Löschen Sie /wp-admin und /wp-includes auf dem Server und laden Sie dann die frischen Ordner per SFTP hoch: Wer nur darüberkopiert, lässt die zusätzlichen Dateien des Angreifers liegen, genau wie die Neuinstallation im Backend. Dann prüfen Sie:

cd ~/public_html                                               # Ihr Web-Verzeichnis
wp core verify-checksums --include-root                        # meldet auch fremde Dateien im Hauptverzeichnis
wp plugin verify-checksums --all --skip-plugins --skip-themes  # nur für Plugins von WordPress.org
wp cron event list --skip-plugins --skip-themes                # geplante Aufgaben, die Sie nicht kennen?
find wp-content/uploads -name '*.php'                          # in uploads gehören Medien, kein Code

--include-root braucht WP-CLI 2.8 oder neuer (wp cli version). Bei älteren Versionen lassen Sie die Option weg und vergleichen das Hauptverzeichnis von Hand mit dem frischen Download.

Installieren Sie Plugins und Themes neu, von WordPress.org oder vom Hersteller. Löschen Sie, was Sie nicht nutzen, samt Dateien: Deaktivieren reicht nicht. Prüfen Sie von Hand .htaccess, index.php, den Ordner wp-content/mu-plugins und im Theme header.php, footer.php und functions.php. In der wp-config.php suchen Sie nach eingebundenen Dateien, die Sie nicht kennen. Google schlägt vor, nach eval, base64_decode und unescape zu suchen:

grep -rnE 'eval\(|base64_decode\(|unescape\(' wp-content wp-config.php .htaccess

Ein Treffer beweist nichts, aber jeder verdient einen Blick.

Diese Zeile in der wp-config.php schaltet den Datei-Editor im Backend ab, laut Härtungs-Leitfaden oft das erste Werkzeug eines Angreifers:

define( 'DISALLOW_FILE_EDIT', true );

Prüfen Sie die Benutzerliste noch einmal. Erst dann bringen Sie WordPress, Plugins und Themes auf den aktuellen Stand: mit derselben Version aufräumen, danach aktualisieren. Zu veraltetem PHP: unser Leitfaden zu PHP 8.2.

Was speichert Ihre Seite? Anfragen aus dem Kontaktformular, Bestellungen, Kundenkonten, Newsletter-Listen? Eine Sicherheitsverletzung, die solche Daten betrifft, nennt Art. 4 Z 12 DSGVO eine "Verletzung des Schutzes personenbezogener Daten".

Nach Art. 33 Abs. 1 meldet der Verantwortliche sie "unverzüglich und möglichst binnen 72 Stunden, nachdem ihm die Verletzung bekannt wurde" der 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 Verzögerung begründen. Was noch nicht bekannt ist, darf ohne unangemessene weitere Verzögerung schrittweise nachkommen (Art. 33 Abs. 4). Nach Art. 34 sind die betroffenen Personen unverzüglich zu benachrichtigen, wenn die Verletzung voraussichtlich ein hohes Risiko für sie zur Folge hat. Dokumentieren muss der Verantwortliche jede solche Verletzung ohnehin (Art. 33 Abs. 5): Fakten, Auswirkungen, Abhilfemaßnahmen.

In Österreich ist das die Datenschutzbehörde. Sie nimmt Meldungen per Onlineformular, PDF-Formular, E-Mail oder Brief entgegen und hält fest, dass die Beurteilung des Risikos "dem Verantwortlichen selbst" obliegt. Diese Entscheidung können wir Ihnen nicht abnehmen. Fragen Sie Ihre Ansprechperson für Datenschutz oder Ihre Rechtsberatung.

Nehmen Sie die bereinigte Seite wieder online und heben Sie den 503 auf: Google setzt für eine Überprüfung voraus, dass die saubere Seite wieder erreichbar ist. Dann bestätigen Sie die Inhaberschaft Ihrer Website in der Search Console, öffnen den Bericht "Sicherheitsprobleme" und beheben jedes gelistete Problem auf der ganzen Website. Wer nur einzelne Seiten bereinigt, kommt nicht teilweise in die Suchergebnisse zurück. Prüfen Sie die Seiten von außen mit cURL, einmal mit Google als Referrer und einmal ohne:

curl -v --referer "https://www.google.com" --user-agent "Mozilla/5.0" https://www.example.at/
curl -v --user-agent "Mozilla/5.0" https://www.example.at/

robots.txt und noindex dürfen die bereinigten Seiten nicht sperren. Dann klicken Sie auf "Überprüfung anfordern" und beschreiben das Problem, die Lösung und das Ergebnis. Googles Beispiel sinngemäß: "Ich habe den eingeschleusten Spam entfernt und die Lücke geschlossen, indem ich ein veraltetes Plugin aktualisiert habe." Laut Google dauert die Prüfung bei Spam bis zu mehrere Wochen, bei Malware einige Tage, bei Phishing etwa einen Tag. Findet Google die Seite sauber, verschwinden die Warnungen innerhalb von 72 Stunden. Stellen Sie vor der Entscheidung keinen neuen Antrag. Wer immer wieder zwischen sauber und infiziert wechselt, gilt als Wiederholungstäter und kann erst nach 30 Tagen wieder eine Überprüfung beantragen. Lassen Sie vom Angreifer angelegte Seiten mit 404 antworten: Sie fallen mit der Zeit aus dem Google-Index, schneller, wenn Sie sie in der Search Console zum Entfernen einreichen.

Prüfen Sie auch, ob Mails von Ihrer Domain noch ankommen. Sperrlisten erfassen die IP-Adresse der Website, und über denselben Server läuft oft auch Ihre Mail. Hat Ihnen CERT.at, das österreichische nationale CERT, geschrieben, erklärt dessen Seite "Emails von uns" den Fall. Bei Angriffen auf nationaler Ebene koordiniert CERT.at die Reaktion, ist aber nach eigenen Worten "kein allgemeiner IT-Helpdesk".

Wer die Seite selbst bereinigt, muss laut Google Code lesen, Kommandozeilen-Werkzeuge auf dem Server bedienen und unter Umständen die Webserver-Konfiguration ändern können. Im Zweifel empfiehlt CERT.at Ihren IT-Dienstleister.

Dafür gibt es unsere Hilfe nach einem Vorfall. Wir dämmen den Angriff ein, räumen auf, schließen die Lücke und erklären in klaren Worten, was passiert ist und was wir geändert haben. Rufen Sie an: +43 7235 233 85, Montag bis Freitag 8:00 bis 15:00 Uhr, Samstag und Sonntag 9:00 bis 12:00 Uhr, außer an Feiertagen. Am Telefon sind die Leute, die auch die Arbeit machen. Wenn wir gerade nicht abheben, rufen wir zurück. Sonst schicken Sie uns über das Kontaktformular, was Sie sehen.

Für die laufende Betreuung danach gibt es Bugfixing, Wartung & Optimierung: Updates, die wir zuerst auf einer Kopie testen, Backups, deren Wiederherstellung wir testen, Fehlermeldungen an unser eigenes Error-Monitoring (GlitchTip) und einen regelmäßigen schriftlichen Bericht. Oder Sie melden sich, wenn etwas anfällt, ohne Mindestabnahme. Nicht gehackt, aber ein ungutes Gefühl? Für unseren kostenlosen Website-Check brauchen wir keinen Zugang, und Sie bekommen innerhalb von 3 Werktagen die 5 wichtigsten Befunde schriftlich.