Zum Hauptinhalt springen
S-EDV news
← Alle Anleitungen
📘 Anleitung WordPress 30.09.2026 · 10 min Lesezeit

Malware-Scan für WordPress: Prüfsummen per WP-CLI und Scan mit Wordfence

Veränderte Kerndateien, fremde PHP-Skripte und Schadcode finden: Prüfsummen mit wp core verify-checksums und wp plugin verify-checksums, Suche im Upload-Ordner, ergänzender Wordfence-Scan und sauberer Ersatz durch Originale.

Mit KI erstellt – redaktionelle Prüfung ausstehend

WerbelinksMit * markierte Links sind Werbelinks: Bei einem Kauf erhalten wir eine Provision, der Preis bleibt gleich. Mehr dazu

Grafik mit der Überschrift Malware-Scan für WordPress, drei Karten Scan, Prüfsumme, Schutz und einem stilisierten WordPress-Adminbereich

Schadcode auf einer WordPress-Website versteckt sich selten offen. Meist steckt er in einer veränderten Kerndatei, einem zusätzlichen PHP-Skript mit harmlosem Namen oder einer Datei im Upload-Ordner, wo PHP nichts zu suchen hat. Zwei Werkzeuge ergänzen sich bei der Suche: WP-CLI vergleicht Ihre Dateien mit den offiziellen Prüfsummen von wordpress.org und zeigt jede Abweichung, Wordfence durchsucht zusätzlich Themes, Plugins und Inhalte nach bekannten Schadcode-Mustern. Diese Anleitung zeigt beide Wege, erklärt, wie Sie die Ergebnisse lesen, und wie Sie betroffene Dateien sauber ersetzen. Die WP-CLI-Befehle wurden im Labor mit WordPress 7.1.2 und absichtlich manipulierten Dateien geprüft.

Voraussetzungen

  • WordPress: eine Installation aus dem offiziellen Paket, getestet mit WordPress 7.1.2 in deutscher Sprache.
  • PHP: die Version Ihres Hostings, im Labor PHP 8.4. Wordfence 9.0.2 verlangt laut Plugin-Seite mindestens PHP 7.0.
  • Zugriff: SSH mit WP-CLI (getestet mit 2.12.0) für die Prüfsummen, Administrator im Backend für Wordfence.
  • Internet: Der Server muss api.wordpress.org erreichen, denn von dort lädt WP-CLI die Prüfsummen.
  • Backup: eine Sicherung des aktuellen Zustands von Dateien und Datenbank, bevor Sie irgendetwas ersetzen oder löschen. Sie brauchen sie für die Analyse und falls ein Ersatz schiefgeht.

Schritt 1: Aktuellen Zustand sichern

Auch ein verdächtiges System sichern Sie vor jedem Eingriff. Diese Sicherung ist kein Wiederherstellungspunkt, sondern ein Beweis- und Analysestand. Wenn Sie später wissen wollen, seit wann eine Datei verändert war oder welche Daten betroffen sind, brauchen Sie den ursprünglichen Zustand. Legen Sie die Sicherung außerhalb des Webverzeichnisses ab:

cd /var/www/html
wp db export ~/analyse-$(date +%F).sql
tar czf ~/analyse-dateien-$(date +%F).tgz .

Überschreiben Sie damit keine ältere, saubere Sicherung. Behalten Sie beide getrennt.

Verifizieren: ls -lh ~/analyse-* zeigt eine SQL-Datei und ein Archiv mit plausibler Größe.

Schritt 2: WordPress-Kern mit Prüfsummen vergleichen

Für jede WordPress-Version veröffentlicht wordpress.org Prüfsummen aller Kerndateien. wp core verify-checksums lädt diese Liste und vergleicht jede Datei in wp-admin, wp-includes und im Hauptverzeichnis. Der Vorteil: Das Verfahren braucht keine Schadcode-Signaturen, es erkennt jede Änderung, auch völlig neuen Schadcode.

cd /var/www/html
wp core verify-checksums

Im Labor wurden eine Kerndatei verändert und zwei zusätzliche PHP-Dateien angelegt. Die Ausgabe:

Warning: File doesn't verify against checksum: wp-includes/functions.php
Warning: File should not exist: wp-admin/css/colors/zz.php
Warning: File should not exist: wp-includes/x-cache.php
Error: WordPress installation doesn't verify against checksums.

Die beiden Meldungstypen bedeuten Unterschiedliches. „File doesn't verify against checksum“ heißt: Eine Originaldatei wurde verändert. „File should not exist“ heißt: In einem Kernordner liegt eine Datei, die zum Paket nicht gehört. Beides ist bei einer Standardinstallation ein starkes Warnsignal, denn in wp-admin und wp-includes gehören keine eigenen Dateien.

Wichtig: Zusätzliche Dateien allein lassen den Befehl nicht scheitern. Im Labor endete ein Lauf, bei dem nur die zwei zusätzlichen PHP-Dateien vorhanden waren, mit Success: WordPress installation verifies against checksums. und den Warnungen davor. Lesen Sie deshalb immer die ganze Ausgabe, nicht nur die letzte Zeile.

Harmlose Treffer gibt es auch. Im Docker-Image von WordPress meldet der Befehl wp-config-docker.php, weil das Image diese Datei mitbringt. Bei manchen Hostern liegen ähnliche Dateien im Hauptverzeichnis. Prüfen Sie jede Meldung, bevor Sie sie als harmlos abhaken. Mit --include-root meldet WP-CLI zusätzlich alle fremden Dateien und Ordner im Hauptverzeichnis. Falls Sie eine andere Sprachversion installiert haben, geben Sie sie mit --locale=de_DE an.

Verifizieren: Sie haben eine Liste aller Warnungen. Bei einer sauberen Standardinstallation erscheint nur Success: WordPress installation verifies against checksums. ohne Warnungen davor.

Schritt 3: Plugins prüfen und Upload-Ordner durchsuchen

Für Plugins aus dem Verzeichnis von wordpress.org gibt es ebenfalls Prüfsummen:

wp plugin verify-checksums --all

Im Labor wurde an akismet.php eine Zeile angehängt und eine zusätzliche Datei in den Plugin-Ordner gelegt. Die Ausgabe:

plugin_name	file	message
akismet	class.cache.php	File was added
akismet	akismet.php	Checksum does not match
Error: No plugins verified (1 failed).

Anders als beim Kern führt hier auch eine zusätzliche Datei zum Fehler. Die Option --strict meldet darüber hinaus Änderungen an Dateien, die WP-CLI sonst als unkritisch behandelt, etwa readme.txt. Premium-Plugins und eigene Plugins, die nicht auf wordpress.org liegen, kann WP-CLI nicht prüfen. Für Themes bietet WP-CLI 2.12.0 keinen Prüfsummen-Befehl, im Labor meldete wp theme verify-checksums „is not a registered subcommand“. Diese Lücke schließt Schritt 4.

Unabhängig von Prüfsummen lohnt ein Blick in den Upload-Ordner. Dort legt WordPress Bilder und Dokumente ab, PHP-Dateien gehören nicht hinein. Ein Angreifer, der eine Upload-Lücke ausnutzt, legt dort gern ein Skript ab:

find wp-content/uploads -type f -name "*.php"
find . -type f -name "*.php" -newermt "-7 days" -not -path "./wp-content/languages/*"

Der erste Befehl fand im Labor die präparierte Datei wp-content/uploads/2026/09/bild.php. Der zweite listet PHP-Dateien, die in den letzten sieben Tagen geändert wurden. Nach einem Update ist die Liste lang, ansonsten fallen Einzelfälle schnell auf. Manche Plugins legen legitime Dateien wie index.php in eigene Unterordner von uploads, prüfen Sie den Inhalt, bevor Sie etwas löschen.

Verifizieren: wp plugin verify-checksums --all endet mit Success: Verified N of N plugins., und die Suche im Upload-Ordner liefert keine oder nur erklärbare PHP-Dateien.

Schritt 4: Wordfence-Scan ergänzen

Wordfence Security (im Labor Version 9.0.2) ist ein Sicherheits-Plugin mit Firewall und Malware-Scanner. Laut Plugin-Seite vergleicht der Scanner Kern-, Theme- und Plugin-Dateien mit den Versionen auf wordpress.org, sucht nach Signaturen bekannter Schadsoftware und Hintertüren und prüft Beiträge und Kommentare auf gefährliche Links. Damit deckt er ab, was WP-CLI nicht kann: Themes, Schadcode in Dateien ohne Prüfsumme und Inhalte in der Datenbank. In der kostenlosen Version erhalten Sie neue Firewall-Regeln und Signaturen laut Plugin-Seite 30 Tage verzögert.

Installieren und aktivieren Sie Wordfence unter Plugins > Plugin hinzufügen. Nach der Aktivierung meldet das Plugin „Wordfence-Installation ist unvollständig“ und bittet um eine Registrierung, die auch für die kostenlose Lizenz vorgesehen ist. Tragen Sie laut Installationsanleitung des Plugins in den Optionen eine E-Mail-Adresse ein, an die Wordfence Sicherheitswarnungen sendet. Danach starten Sie unter Wordfence > Scannen mit „Neuen Scan starten“ den ersten Scan. Laut Installationsanleitung des Plugins wird dabei auch der regelmäßige, geplante Scan aktiviert.

Unter „Scan-Optionen und Zeitplanung“ lässt sich der Scan-Typ wählen. „Hohe Empfindlichkeit“ findet mehr, das Plugin weist aber selbst auf eine hohe Wahrscheinlichkeit von Fehlalarmen hin. Nutzen Sie diese Stufe gezielt bei konkretem Verdacht, nicht als Dauereinstellung.

Die Ergebnisliste bietet je Treffer Aktionen wie „Reparatur“, „Datei löschen“ und „Ignorieren“. Die Plugin-Seite empfiehlt ausdrücklich, Scan-Ergebnisse zu prüfen und Dateien zu sichern, bevor Sie etwas löschen. Löschen Sie keine Datei, deren Zweck Sie nicht kennen, ohne die Sicherung aus Schritt 1.

Verifizieren: Unter Wordfence > Scannen ist ein abgeschlossener Scan mit Datum sichtbar, und Sie haben jeden Treffer entweder behoben oder begründet ignoriert.

Schritt 5: Veränderte Dateien durch Originale ersetzen

Bearbeiten Sie infizierte Dateien nicht von Hand. Schadcode ist oft auf mehrere Stellen verteilt, und eine übersehene Zeile reicht für den nächsten Zugriff. Ersetzen Sie Kern und Plugins durch saubere Originale derselben Version:

wp core download --version=7.1.2 --locale=de_DE --skip-content --force
wp plugin install akismet --force
wp core verify-checksums
wp plugin verify-checksums --all

--skip-content verhindert, dass Standard-Themes und -Plugins in wp-content überschrieben werden. Im Labor stellte wp core download --force die veränderte functions.php wieder her, die zusätzlichen Dateien in wp-admin und wp-includes blieben aber liegen und wurden weiter als „File should not exist“ gemeldet. Diese Dateien löschen Sie gezielt, nachdem Sie sie gesichert haben. wp plugin install --force ersetzte den Plugin-Ordner, danach meldete WP-CLI Success: Verified 3 of 3 plugins.

Ein Fund bedeutet in der Regel mehr als eine einzelne Datei: Irgendwo gab es eine Lücke, meist ein veraltetes Plugin oder ein schwaches Passwort. Ändern Sie nach einem Fund alle Passwörter, auch das der Datenbank, prüfen Sie die Benutzerliste auf unbekannte Administratoren mit wp user list --role=administrator und spielen Sie ausstehende Updates ein. Bei einem echten Befall mit Datenabfluss prüfen Sie auch Meldepflichten nach DSGVO.

Prüfsummen, Scans und Updates wirken nur, wenn sie regelmäßig laufen. Wer diese Routine nicht selbst im Kalender halten möchte, kann sie abgeben: Die WordPress-Wartung von wordpressupdate.de übernimmt Updates von WordPress, Plugins und Themes, die Einrichtung und Wartung der Firewall und wöchentliche Backups auf externen Speicher.

Verifizieren: wp core verify-checksums meldet Erfolg ohne unerklärte Warnungen, wp plugin verify-checksums --all meldet alle Plugins als geprüft, und ein erneuter Wordfence-Scan zeigt keine offenen Treffer.

Typische Fehler

  • Nur die letzte Zeile gelesen: wp core verify-checksums meldet bei zusätzlichen Dateien trotzdem „Success“. Die Warnungen davor sind der eigentliche Befund.
  • Falsche Sprachversion: Wurde WordPress in einer anderen Sprache installiert, weichen einzelne Dateien ab. Geben Sie --locale passend an.
  • Error: 'verify-checksums' is not a registered subcommand of 'theme': WP-CLI prüft Themes nicht per Prüfsumme. Themes aus dem Verzeichnis prüft Wordfence, alternativ vergleichen Sie mit dem Original-ZIP der gleichen Version.
  • Datei per Wordfence gelöscht, Website zeigt Fehler: Die Datei wurde noch gebraucht. Aus der Sicherung aus Schritt 1 zurückholen und den Treffer genauer prüfen. Wie Sie Fehlermeldungen sichtbar machen, zeigt WordPress Debug-Modus aktivieren.
  • Nach der Bereinigung wieder infiziert: Die Ursache ist nicht behoben. Updates einspielen, Passwörter ändern, unbekannte Benutzer entfernen, Login absichern.

Häufige Fragen

Reicht Wordfence allein?

Für die regelmäßige Überwachung ja. Die Prüfsummen per WP-CLI sind aber unabhängig von Signaturen und laufen außerhalb von WordPress. Ist ein System so kompromittiert, dass ein Plugin manipuliert wurde, liefert ein Befehl auf der Kommandozeile ein zweites, unabhängiges Urteil.

Wie oft sollte ich prüfen?

Den Wordfence-Scan lassen Sie im Zeitplan laufen. Die Prüfsummen per WP-CLI eignen sich für einen wöchentlichen Cronjob und nach jedem Verdacht, etwa bei unerklärlichen Weiterleitungen oder Spam-Beiträgen.

Kann ich Premium-Plugins prüfen?

Nicht über die Prüfsummen von wordpress.org. Vergleichen Sie mit einem frischen Download aus Ihrem Kundenkonto beim Anbieter, etwa mit diff -rq, oder installieren Sie das Plugin aus diesem Download neu.

Brauche ich Wordfence Premium?

Für die Prüfung auf veränderte Dateien nicht. Premium liefert laut Plugin-Seite Signaturen und Firewall-Regeln ohne die Verzögerung von 30 Tagen. Ob das nötig ist, hängt davon ab, wie schnell Sie Updates einspielen.

Testumfang

Wir haben das Vorgehen im Labor mit WordPress 7.1.2 auf Deutsch durchgespielt, mit einer veränderten Kerndatei und zusätzlichen Dateien. Kontrolliert haben wir die Prüfsummen von Kern und Plugins und anschließend das Ersetzen der Dateien per wp core download --force.

Den Wordfence-Scan haben wir nicht ausgeführt, weil keine Registrierung bei Wordfence erfolgen sollte, die Beschreibung stützt sich auf die Plugin-Seite. Probieren Sie den Scan deshalb zuerst auf einer Kopie Ihrer Website aus.

Fazit

Prüfsummen zeigen zuverlässig, ob Kern und Plugins vom Original abweichen, Wordfence ergänzt Themes, Signaturen und Inhalte. Sichern Sie vor jedem Eingriff, lesen Sie die Warnungen vollständig, ersetzen Sie Dateien durch Originale und schließen Sie danach die Lücke. Wenn Sie Updates und Firewall lieber abgeben, übernimmt das die WordPress-Wartung von Marcel Schönfelder.

Weiterführende Anleitungen und Quellen

WordPressSicherheitMalwareWP-CLIWordfence