WordPress Malware-Scan: selbst prüfen, bevor du bereinigst

Ein Malware-Scan von WordPress beantwortet zwei Fragen: Weicht etwas von den Originaldateien ab, und liegt etwas dort, wo nichts liegen sollte? Kein einzelnes Werkzeug beantwortet beide. WordPress.org rät deshalb, Scanner innerhalb der Seite (Plugins) und von außen (Crawler) zu kombinieren: „No one solution is the best approach, but together you improve your odds greatly“ (FAQ My site was hacked).

Ein Scanner, der nichts findet, hat nur in seinem Blickfeld nichts gefunden. Sucuri schreibt über den eigenen Online-Scanner, er sehe nur, was im Browser sichtbar ist, und finde „nothing on the server-side“, also keine Hintertüren und keine Versandskripte (Sucuri SiteCheck). Ein Plugin-Scanner wiederum läuft im selben WordPress wie der Schadcode, den er finden soll.

Und gescannt wird erst, wenn eine Kopie des jetzigen Zustands gesichert ist. Der Scan soll klären, wie tief es geht. Löscht ein Plugin dabei Dateien, fehlen sie für die Frage, wie der Angreifer hineinkam. Die Befehle für die Kopie stehen in Schritt 2 von WordPress gehackt: was tun, der Weg für eine laufende Sicherung in WordPress-Backup.

Schicht 1: von außen#

Treffer gefunden? Die WordPress-Bereinigung ab 290 € übernimmt ab hier: Zugänge wechseln, Ausmaß feststellen, sauberer Neuaufbau, Überprüfung bei Google. Preis nach kostenloser Ersteinschätzung, vorab fix.

Das geht ohne Serverzugang und zeigt, was Besucher und Google bekommen.

• Google Safe Browsing. Der Transparenzbericht zeigt für jede Adresse, ob Google sie als gefährlich führt. Für die eigene Domain steht der genaue Befund in der Search Console unter „Sicherheitsprobleme“.
• Abruf als Googlebot. Schadcode zeigt sich oft nur Suchmaschinen oder Besuchern aus der Google-Suche. Google beschreibt für die Untersuchung den Abruf mit curl und gesetztem Referrer (web.dev, Hacked with malware). Der Vergleich normal gegen Googlebot mit diff steht im Abschnitt So erkennst du, ob die Seite gehackt ist.
• Online-Scanner. Sucuri SiteCheck und VirusTotal nennt WordPress.org als „Remote Based Scanners“. Sie finden eingeschleuste Skripte, Weiterleitungen und Spam-Verweise im ausgelieferten HTML.

Der Security-Scan prüft ebenfalls von außen, aber anders: welche fremden Skripte die Seite lädt, ob Dateien wie /.env oder /backup.sql offen liegen, wie die Security-Header stehen. Malware-Signaturen und Plugins prüft er nicht. Eine fremde Skript-Quelle, die niemand eingebaut hat, ist aber genau der Befund, mit dem viele Infektionen auffallen.

Schicht 2: Dateien gegen die Originale#

WP-CLI lädt die Prüfsummen von WordPress.org und vergleicht sie mit den installierten Dateien (core verify-checksums, plugin verify-checksums):

wp core verify-checksums --include-root
wp plugin verify-checksums --all

Ich habe beide Befehle am 05.10.2026 an einer Testinstallation (WordPress 7.1.2, WP-CLI 2.12) mit absichtlich eingebauten Veränderungen laufen lassen, um zu sehen, was sie melden und was nicht:

Drei Dinge folgen daraus. Ohne --include-root rutscht eine fremde Datei im Hauptverzeichnis durch, sobald ihr Name nicht mit wp- beginnt. Der Upload-Ordner und die .htaccess gehören nicht zum Kern und werden nicht geprüft. Und plugin verify-checksums kennt nur Plugins aus dem Verzeichnis auf WordPress.org; gekaufte Plugins und Themes fallen durch.

Ein Vorteil für den Ernstfall: core verify-checksums läuft, bevor WordPress geladen wird, und braucht keine Datenbank. In der Testinstallation ließ sich eine heruntergeladene Kopie auf dem eigenen Rechner prüfen, mit absichtlich falschem Datenbankzugang. Die Plugin-Prüfung brach dort dagegen mit „Fehler beim Aufbau einer Datenbankverbindung“ ab; sie braucht die laufende Seite.

Schicht 3: die Stellen, die kein Abgleich sieht#

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

# Code, der vor jeder Seite geladen wird
grep -rn "auto_prepend_file" --include=.htaccess --include=.user.ini --include=php.ini .

# 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
grep -rlE "eval\(|base64_decode\(|gzinflate\(|str_rot13\(" wp-content --include=*.php

# Skripte in Beiträgen, Widgets, Optionen
wp db search "<script" --all-tables-with-prefix

# Benutzer und geplante Aufgaben
wp user list --role=administrator --fields=ID,user_login,user_registered
wp cron event list --fields=hook,next_run_relative,recurrence

In der Testinstallation fanden find die PHP-Datei im Upload-Ordner, grep die Zeile in der .htaccess und die verschleierte Zeile im Plugin, wp db search ein in einen Beitrag eingeschleustes <script>. Ein Treffer bei base64_decode ist ein Grund hinzusehen, kein Urteil, auch harmlose Plugins nutzen die Funktion. Google nennt dieselben Muster als typisch: versteckte iframe, verschleierten Code mit eval(base64_decode(...)) und Weiterleitungen in der .htaccess.

Die Benutzerliste gehört dazu, weil ein Konto, das niemand angelegt hat, für WordPress.org ein klares Anzeichen ist. Was jede Rolle darf, steht in WordPress-Benutzerrollen.

Plugin-Scanner: was sie können#

WordPress.org nennt als „Application Based Scanners“ Quttera, GOTMLS, Wordfence und Sucuri. Wordfence etwa gleicht laut Beschreibung Kern, Themes und Plugins mit dem Verzeichnis auf WordPress.org ab und sucht zusätzlich nach Signaturen bekannter Schadsoftware, nach Hintertüren und SEO-Spam. Zwei Einschränkungen, die man kennen sollte:

• Die kostenlose Fassung von Wordfence bekommt neue Signaturen 30 Tage später. So steht es in der Plugin-Beschreibung: „free version is delayed by 30 days“ (Wordfence im Plugin-Verzeichnis). Für frische Infektionen ist der kostenlose Scan also blind.
• Wordfence CLI, der Scanner für die Kommandozeile, ist ein Auslaufmodell. Laut Projektseite gibt es keine neuen Lizenzen mehr, und die kostenlose Fassung endet am 14. Oktober 2026 (wordfence-cli auf GitHub).

Ein Plugin-Scanner ist ein Hinweisgeber. Was er „bereinigt“, ist das, was er erkannt hat, und die Hintertür, die den Schadcode wieder anlegt, erkennt er selten.

Was nicht hilft#

Scannen und gleich auf „Bereinigen“ drücken. Damit sind die Spuren weg, die zeigen, wann und wie es passiert ist, und mit ihnen die Grundlage für die Entscheidung, welcher Sicherung man noch trauen kann.

Nur von außen prüfen. Ein sauberer Online-Scan heißt, dass das ausgelieferte HTML gerade unauffällig ist. Eine Hintertür in wp-content/uploads liefert kein HTML aus.

Ein zweites Sicherheitsplugin dazu installieren. Zwei Scanner im befallenen WordPress sehen dasselbe aus derselben Perspektive.

Nur die gemeldete Datei löschen. Die gemeldete Datei ist meist die Nutzlast. Was sie wieder anlegt, liegt in einem Must-Use-Plugin, einer Option, einer geplanten Aufgabe oder in der .htaccess.

Vom Befund zur Bereinigung#

Ein Scan ohne Befund über alle drei Schichten ist ein gutes Zeichen, aber kein Beweis. Ein Scan mit Befund ist der Anfang einer Bereinigung, und die hat eine Reihenfolge: Zugänge wechseln, bevor gesucht und gelöscht wird, sonst ist der Angreifer in ein paar Tagen zurück. Die neun Schritte stehen in WordPress gehackt: was tun. Danach schützen Zwei-Faktor-Anmeldung und aktuelle Plugins vor dem nächsten Mal.

In eigener Sache: Die Bereinigung, wenn der Scan Treffer zeigt, übernehme ich ab 290 €. Den genauen Preis sage ich nach einer kostenlosen Ersteinschätzung, weil niemand vorher weiß, wie tief es geht, und er steht fest, bevor ich anfange; Anfrage über die Kontaktseite. Danach hält die WordPress-Wartung für 49 € im Monat die Seite aktuell und überwacht sie. Was davor alles zur Absicherung gehört, steht in WordPress-Sicherheit prüfen.

Stand 13.10.2026. Befehle und Tabelle am 05.10.2026 an zwei Testinstallationen geprüft (WordPress 7.1.2, einmal in WordPress Playground mit SQLite, einmal deutsch mit MariaDB 11.4.13; PHP 8.3, WP-CLI 2.12.0), mit absichtlich eingebauten Veränderungen; an keiner fremden Seite. Plugin-Angaben aus dem Verzeichnis auf WordPress.org und der Projektseite von Wordfence CLI vom selben Tag.