WordPress-Dateien auf Veränderungen prüfen: Core und Plugins mit verify-checksums kontrollieren

Nach einem Einbruch in eine WordPress-Website verändern Angreifer häufig Dateien des WordPress-Kerns oder legen eigene PHP-Dateien daneben, um später wiederzukommen. Solche Änderungen sehen Sie im Backend nicht. WordPress.org veröffentlicht für jede Version Prüfsummen aller Kerndateien, und WP-CLI vergleicht Ihre Installation in Sekunden damit. Diese Anleitung zeigt, wie Sie Kern und Plugins prüfen, die Meldungen richtig lesen, veränderte Dateien sauber ersetzen und die Prüfung regelmäßig laufen lassen. Im Labor wurden dazu Dateien gezielt manipuliert. Dabei zeigte sich eine Lücke, die viele übersehen: Eine zusätzlich eingeschleuste Datei führt nicht zu einem Fehlercode.

Voraussetzungen

• WordPress: geprüft mit WordPress 7.1.2. Die Prüfsummen gibt es für alle offiziellen Versionen.
• WP-CLI: geprüft mit WP-CLI 2.12.0. Ohne WP-CLI prüfen Sie nur manuell, dafür ist diese Anleitung nicht gedacht.
• PHP: mindestens 7.4.
• Zugriff: SSH auf den Server mit Schreibrechten im WordPress-Verzeichnis. Für die Kontrolle im Backend ein Konto mit der Rolle Administrator.
• Internetzugang des Servers: WP-CLI lädt die Prüfsummen von WordPress.org.
• Backup: eine aktuelle Sicherung von Datenbank und Dateien, bevor Sie Dateien ersetzen oder löschen. Bei Verdacht auf einen Einbruch zusätzlich eine unveränderte Kopie des Ist-Zustands für die spätere Untersuchung.

Schritt 1: Kerndateien prüfen

Wechseln Sie per SSH in das WordPress-Verzeichnis und starten Sie die Prüfung:

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

Laut WP-CLI-Handbuch lädt der Befehl die MD5-Prüfsummen der installierten Version von WordPress.org und vergleicht sie mit den Dateien. Er läuft auf dem Hook before_wp_load, lädt WordPress also bewusst nicht. Das ist wichtig: Ein manipulierter Kern könnte sonst die eigene Prüfung beeinflussen. Auf einer sauberen Installation lautet die Ausgabe:

Success: WordPress installation verifies against checksums.

Geprüft werden die Dateien in wp-admin, wp-includes und die Kerndateien im Hauptverzeichnis. Der Ordner wp-content mit Themes, Plugins und Uploads gehört nicht dazu. Mit --include-root meldet der Befehl zusätzlich fremde Dateien und Ordner im Hauptverzeichnis. Im Labor erschien dabei wp-config-docker.php, eine Datei des Docker-Images. Solche erklärbaren Funde gehören auf eine Ausnahmeliste, die Sie mit --exclude=datei1,datei2 übergeben.

Verifizieren: Der Befehl endet mit Success, und echo $? direkt danach liefert 0.

Schritt 2: Meldungen richtig lesen

Im Labor wurden gezielt vier Veränderungen vorgenommen: eine Zeile an wp-includes/version.php angehängt, wp-admin/about.php gelöscht sowie zwei neue PHP-Dateien in wp-includes und wp-admin angelegt. Die Prüfung meldete:

Warning: File doesn't exist: wp-admin/about.php
Warning: File doesn't verify against checksum: wp-includes/version.php
Warning: File should not exist: wp-admin/extra.php
Warning: File should not exist: wp-includes/backdoor.php
Error: WordPress installation doesn't verify against checksums.

Die drei Meldungsarten bedeuten:

Meldung	Bedeutung	Exit-Code
File doesn't verify against checksum	Kerndatei verändert	1
File doesn't exist	Kerndatei fehlt	1
File should not exist	zusätzliche Datei, die nicht zu WordPress gehört	0, wenn sonst alles passt

Die letzte Zeile der Tabelle ist die wichtigste Erkenntnis aus dem Test. Lag nur eine zusätzliche Datei wp-includes/zz.php im Kern, endete der Befehl mit Success: WordPress installation verifies against checksums. und Exit-Code 0. Die Warnung stand trotzdem in der Ausgabe. Gerade eingeschleuste Hintertüren sind aber oft neue Dateien mit harmlos klingenden Namen. Ein Skript, das nur auf den Exit-Code achtet, übersieht sie.

Ein zweiter Fallstrick: Eine veränderte wp-includes/version.php mit Syntaxfehler legte im Labor auch WP-CLI lahm. Befehle, die WordPress laden, brachen mit PHP Parse error: syntax error, unexpected token "<" ab. wp core verify-checksums lief dagegen weiter, weil es WordPress nicht lädt.

Verifizieren: Sie können jede Warnung einer der drei Arten zuordnen und haben die betroffenen Pfade notiert.

Schritt 3: Plugins prüfen

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

wp plugin verify-checksums --all

Im Labor wurden eine Zeile an die Hauptdatei von Antispam Bee angehängt und eine neue Datei in den Ordner von Akismet gelegt. Das Ergebnis:

plugin_name   file              message
akismet       neu.php           File was added
antispam-bee  antispam_bee.php  Checksum does not match
Error: Only verified 1 of 3 plugins (2 failed).

Anders als beim Kern führen hier auch hinzugefügte Dateien zu einem Fehler und Exit-Code 1. Mit --strict meldet der Befehl laut Handbuch auch kleine Änderungen, etwa an der readme.txt. Premium-Plugins und Plugins von GitHub haben keine Prüfsummen bei WordPress.org und lassen sich so nicht prüfen. Für Themes bietet WP-CLI 2.12.0 keinen entsprechenden Befehl.

Verifizieren: Die Ausgabe endet mit Success: Verified N of N plugins., wobei N der Zahl Ihrer Plugins aus dem Verzeichnis entspricht.

Schritt 4: Veränderte Dateien ersetzen

Bevor Sie etwas ersetzen, halten Sie den Ist-Zustand fest. Kopieren Sie die gemeldeten Dateien in einen Ordner außerhalb des Webroots. Eine unbekannte PHP-Datei ist ein Beweisstück: Sie verrät, wie der Angreifer vorgeht und ob er Daten abgegriffen haben könnte. Prüfen Sie auch die Änderungszeit mit ls -l --time-style=full-iso DATEI, um den Zeitpunkt des Einbruchs einzugrenzen.

Dann ersetzen Sie die Kerndateien durch eine saubere Kopie derselben Version. wp core version --extra zeigt Version und Paketsprache:

wp core version --extra
wp core download --version=7.1.2 --locale=de_DE --skip-content --force
wp core verify-checksums

--skip-content verhindert, dass WP-CLI Standard-Themes und -Plugins in wp-content überschreibt, --force überschreibt die vorhandenen Kerndateien. Im Labor meldete die Prüfung danach für die veränderte version.php und die gelöschte about.php keinen Fehler mehr. Die zusätzlichen Dateien waren aber noch da, denn core download legt nur Dateien ab und löscht keine fremden. Entfernen Sie diese nach der Sicherung von Hand:

rm wp-includes/backdoor.php wp-admin/extra.php

Veränderte Plugins installieren Sie in derselben Version neu. Die Einstellungen in der Datenbank bleiben erhalten:

wp plugin install antispam-bee --force
wp plugin verify-checksums --all

Im Labor verschwand dabei die geänderte Datei, die zusätzliche Datei im Akismet-Ordner musste jedoch separat gelöscht werden, bis die Prüfung Success: Verified 3 of 3 plugins. meldete.

Verifizieren: Beide Prüfungen melden Success, und die Ausgabe von wp core verify-checksums enthält keine Zeile mit should not exist mehr außer den bekannten Ausnahmen.

Schritt 5: Was die Prüfung nicht sieht

Eine erfolgreiche Prüfung heißt nicht, dass die Website sauber ist. Außerhalb des Blickfelds liegen:

• wp-content/uploads: Hier gehören keine PHP-Dateien hin. find wp-content/uploads -name "*.php" sollte nichts ausgeben. Im Labor wurde eine dort abgelegte Datei weder von der Kern- noch von der Plugin-Prüfung gemeldet, nur find fand sie.
• Themes und Premium-Plugins: keine Prüfsummen bei WordPress.org. Vergleichen Sie sie mit einem frischen Download beim Hersteller.
• wp-config.php und .htaccess: Sie sind individuell und haben keine Prüfsumme. Kontrollieren Sie sie auf unbekannte Zeilen, etwa fremde include-Anweisungen oder Weiterleitungen.
• Datenbank: Schadcode in Beiträgen, Optionen oder neuen Administratorkonten. Prüfen Sie mindestens wp user list --role=administrator.

Finden Sie Anzeichen eines echten Einbruchs, reicht das Ersetzen von Dateien nicht. Ändern Sie alle Passwörter samt Datenbankpasswort und Salts in der wp-config.php und suchen Sie die Ursache, meist ein veraltetes Plugin. Sonst ist der Angreifer bald wieder da.

Verifizieren: find wp-content/uploads -name "*.php" | wc -l liefert 0, und die Administratorenliste enthält nur bekannte Konten.

Schritt 6: Prüfung regelmäßig ausführen

Ein Integritätscheck hilft nur, wenn er regelmäßig läuft. Ein kurzes Skript prüft Kern und Plugins und wertet dabei auch die Warnungen aus, die den Exit-Code nicht verändern:

#!/bin/sh
cd /var/www/html || exit 2
AUSGABE=$(wp core verify-checksums 2>&1); STATUS=$?
FREMD=$(printf '%s\n' "$AUSGABE" | grep "should not exist" | grep -v "wp-config-docker.php")
wp plugin verify-checksums --all --quiet || STATUS=1
if [ "$STATUS" -ne 0 ] || [ -n "$FREMD" ]; then
  printf '%s\n' "$AUSGABE"
  exit 1
fi

Passen Sie die Ausnahme wp-config-docker.php an die bekannten Funde Ihrer Installation an. Per Cron täglich ausgeführt, schickt der Cron-Dienst die Ausgabe bei einem Fund an die hinterlegte Adresse, sofern der Server Mails versenden kann. Wie Cronjobs mit WP-CLI eingerichtet werden, zeigt die Anleitung WP-Cron durch echten System-Cron ersetzen.

Solche Prüfungen gehören zur laufenden Pflege wie Updates und Backups: Wer Kern und Plugins aktuell hält, gibt Angreifern weniger Gelegenheit, überhaupt Dateien zu verändern. Wer diese Aufgaben nicht selbst im Kalender halten möchte, kann sie abgeben: Die WordPress-Wartung von wordpressupdate.de übernimmt Updates von WordPress, Plugins und Themes, wöchentliche Backups auf externen Speicher sowie Einrichtung und Wartung der Firewall.

Verifizieren: Legen Sie testweise eine leere Datei wp-includes/test-integritaet.php an. Das Skript muss sie melden und mit Exit-Code 1 enden. Löschen Sie die Datei danach wieder.

Typische Fehler

• Viele Meldungen File doesn't verify against checksum direkt nach der Installation: Oft passt die Sprachversion nicht. Laut Handbuch helfen dann --version und --locale mit den Werten aus „Dashboard“ › „Aktualisierungen“ bzw. wp core version --extra.
• Paketsprache nach dem Ersetzen verändert: Im Labor zeigte wp core version --extra nach wp core download --force ohne --locale die Paketsprache en_US. Geben Sie beim Ersetzen immer Version und Sprache an.
• Error: Parameter errors: unknown --format parameter: Die im Online-Handbuch beschriebene Option --format kannte das im Labor eingesetzte WP-CLI 2.12.0 für core verify-checksums noch nicht. Prüfen Sie mit wp help core verify-checksums, was Ihre Version unterstützt.
• PHP Parse error bei WP-CLI-Befehlen: Eine Kerndatei ist beschädigt. wp core verify-checksums und wp core download funktionieren trotzdem, weil sie WordPress nicht laden.
• Prüfung „grün“, Website trotzdem verseucht: Der Schadcode liegt in wp-content, in einem Theme, in der Datenbank oder in der wp-config.php. Siehe Schritt 5.

Häufige Fragen

Wie oft sollte ich prüfen?

Täglich per Cron ist üblich, zusätzlich nach jedem Verdacht und nach jedem Wechsel des Hosters. Die Prüfung dauert nur Sekunden.

Ersetzt das einen Malware-Scanner?

Nein. Die Prüfsummen zeigen verlässlich, ob Kern und Verzeichnis-Plugins verändert wurden. Schadcode in Themes, Uploads oder der Datenbank erkennt ein Scanner eher. Beide ergänzen sich.

Gibt es das auch ohne SSH?

WP-CLI braucht eine Kommandozeile. Manche Hoster bieten WP-CLI über ein Web-Terminal an. Sicherheits-Plugins enthalten teils ähnliche Prüfungen im Backend. Diese haben wir hier nicht getestet.

Testumfang

Wir haben die Prüfung am 30.09.2026 in einer Laborinstanz mit WordPress 7.1.2 durchgespielt, dabei wurden Abweichungen an den Kerndateien zuverlässig erkannt. Das Überwachungsskript aus Schritt 6 blieb auf der sauberen Installation ruhig und schlug bei einer eingeschleusten Testdatei an. Den Cron-Eintrag und den Mailversand haben wir nicht getestet, probieren Sie beides deshalb zuerst auf einer Kopie Ihrer Website aus.

Fazit

wp core verify-checksums und wp plugin verify-checksums --all sind ein schneller und verlässlicher Test, ob Kern und Plugins noch dem Original entsprechen. Achten Sie auf die Warnung „File should not exist“, die den Exit-Code nicht ändert, und prüfen Sie uploads, Themes und Konfiguration zusätzlich. Wer die Pflege rund um diese Prüfungen abgeben möchte, findet sie bei der WordPress-Wartung von Marcel Schönfelder.

Weiterführende Anleitungen und Quellen

• WordPress-Plugin nach fehlerhaftem Update zurücksetzen
• Benutzerrollen in WordPress sauber vergeben
• WordPress Cron Job einrichten: WP-Cron durch echten System-Cron ersetzen
• WP-CLI-Handbuch: wp core verify-checksums
• WP-CLI-Handbuch: wp plugin verify-checksums
• WP-CLI-Handbuch: wp core download
• WordPress Advanced Administration: Hardening WordPress