WordPress-Checksummen prüfen: veränderte Core-Dateien finden

Wenn Sie einen Hack vermuten, ist der Abgleich der WordPress-Checksummen ein sinnvoller früher Check. Er darf aber weder die Eindämmung noch die Beweissicherung verzögern. Ein einziger Befehl zeigt Ihnen, ob Ihre Core-Dateien Byte für Byte mit dem offiziellen Release übereinstimmen. Alle Dateien auf der offiziellen Prüfsummenliste müssen exakt zu Ihrer Version und Sprache passen. Seitenspezifische Dateien wie wp-config.php gehören nicht zu diesem Abgleich. Jede Abweichung ist entweder eine lokale Änderung, von der Sie wissen, oder etwas, das Sie sich noch heute ansehen sollten.

Warum sich WordPress-Core-Dateien nach einem Hack verändern

Core-Dateien sind ein gutes Versteck, weil niemand hineinschaut. Website-Betreiber kümmern sich um Theme- und Plugin-Einstellungen. Kaum jemand öffnet wp-includes/load.php oder zählt die Dateien in wp-admin/includes. Ein Angreifer kann Code in einer Core-Datei verstecken, die regelmäßig geladen wird, oder eine harmlos wirkende Datei für einen späteren Zugriff ablegen. Eine solche zusätzliche Datei wird allerdings nicht allein dadurch ausgeführt, dass sie in einem Core-Verzeichnis liegt.

Mit Checksummen wird aus „sieht doch gut aus“ ein nachprüfbarer Vergleich. WordPress.org veröffentlicht für jede Core-Datei jedes Releases einen MD5-Hash. Diese Liste gleichen Sie mit Ihren Dateien ab.

Behalten Sie dabei die Ursache im Blick. Der Bericht State of WordPress Security in 2026 von Patchstack stammt von einem Anbieter. Er zählt für 2025 nur 6 Schwachstellen im WordPress-Core, alle mit niedriger Priorität. Wie ein Angreifer in Ihre Website gelangt ist, verrät diese Zahl nicht. Veränderte Core-Dateien können die Folge eines Einbruchs über ein Plugin, ein Theme oder gestohlene Zugangsdaten sein. Ein frischer Core repariert diese Dateien. Das Einfallstor müssen Sie trotzdem finden und schließen.

WordPress-Checksummen mit WP-CLI prüfen

Verbinden Sie sich per SSH und führen Sie den Befehl im WordPress-Hauptverzeichnis aus:

cd /var/www/example.com
wp core verify-checksums

Aus einem anderen Verzeichnis heraus ergänzen Sie --path=/var/www/example.com. Arbeiten Sie als der Benutzer, dem die Website-Dateien gehören, nicht als root. WP-CLI verweigert die Ausführung als root, solange Sie nicht --allow-root angeben, und diese Voreinstellung ist vernünftig: Als root würde auch jeder Schadcode, den WordPress lädt, mit Root-Rechten laufen.

Standardmäßig liest WP-CLI die Version aus wp-includes/version.php. Auf einer kompromittierten Website kann genau diese Datei manipuliert sein. Wenn Sie wissen, welche Version installiert ist, geben Sie sie fest vor. Bei nicht-englischen Installationen legen Sie zusätzlich die Sprache fest:

wp core verify-checksums --version=6.8.3 --locale=de_DE

Setzen Sie Ihre eigene Versionsnummer ein. Auf einer sauberen Website erscheint genau eine Zeile:

Success: WordPress installation verifies against checksums.

Auf einer problematischen Website sehen Sie Warnungen wie diese:

Warning: File doesn't verify against checksum: wp-includes/functions.php
Warning: File should not exist: wp-includes/class-wp-cache-handler.php
Error: WordPress installation doesn't verify against checksums.

Ergebnisse lesen: veränderte und zusätzliche Dateien

Die beiden Warnungstypen bedeuten Unterschiedliches und verlangen unterschiedliche Schritte.

Eine veränderte Datei ist ernst zu nehmen, es sei denn, Sie kennen einen legitimen lokalen Patch. Solche Patches sind selten, und wer einen eingespielt hat, sollte ihn dokumentiert haben.

Bei zusätzlichen Dateien ist die Lage weniger eindeutig. Manche Updates lassen Dateien älterer Versionen zurück, eine zusätzliche Datei ist also kein Beweis für Malware. Eine PHP-Datei mit zufälligem Namen in wp-includes bleibt aber verdächtig, bis Sie sie gelesen haben. Dasselbe gilt für Dateien, deren Name nur nach Core-Komponente klingt.

Zusätzliche Dateien werden unter Umständen nur als Warnung gemeldet, ohne dass der Befehl fehlschlägt. Es kann also File should not exist erscheinen und darunter trotzdem Success. Lesen Sie jede Warnung, statt sich auf die letzte Zeile zu verlassen.

Die Suche nach zusätzlichen Dateien umfasst standardmäßig wp-admin und wp-includes. Manche WP-CLI-Versionen prüfen auf Wunsch auch das Hauptverzeichnis. Mit wp help core verify-checksums sehen Sie, ob Ihre Version --include-root anbietet.

Kein WP-CLI? Die Checksummen-API von WordPress.org nutzen

Manche Hoster bieten SSH, aber kein WP-CLI. Dann fragen Sie die Checksummen-API direkt ab und lassen md5sum die Dateien vergleichen. Sie benötigen curl und jq:

cd /var/www/example.com
VER=6.8.3        # Ihre exakte WordPress-Version
LOC=en_US        # oder de_DE, fr_FR, ...
(
  set -e
  WORK=$(mktemp -d)
  trap 'rm -rf -- "$WORK"' EXIT
  curl -fsS "https://api.wordpress.org/core/checksums/1.0/?version=$VER&locale=$LOC" \
    -o "$WORK/response.json"
  jq -er '.checksums | select(type == "object" and length > 0) | to_entries[] | select(.key | startswith("wp-content/") | not) | "\(.value)  \(.key)"' \
    "$WORK/response.json" > "$WORK/core.md5"
  test -s "$WORK/core.md5"
  md5sum -c --quiet "$WORK/core.md5"
)

Der select-Filter überspringt die mitgelieferten Themes und Plugins in wp-content, die Sie womöglich bewusst gelöscht haben. Mit --quiet gibt md5sum nur die Dateien aus, die nicht übereinstimmen.

Keine Ausgabe und Exit-Status null bedeuten: Die Dateien aus der gefilterten Checksummenliste stimmen. Ein Fehler beim Herunterladen, Parsen oder Prüfen ist dagegen kein sauberes Ergebnis. Die Subshell arbeitet in einem eigenen temporären Verzeichnis und bricht ab, sobald ein vorheriger Schritt fehlschlägt.

Zusätzliche Dateien findet diese Methode nicht. Dafür laden Sie dasselbe Release herunter, zum Beispiel https://wordpress.org/wordpress-6.8.3.zip. Für nicht-englische Installationen nutzen Sie die passende Sprachseite. Entpacken Sie das Archiv und vergleichen Sie die Ordner:

diff -rq wordpress/wp-includes /var/www/example.com/wp-includes
diff -rq wordpress/wp-admin /var/www/example.com/wp-admin

Zeilen mit Only in /var/www/... zeigen zusätzliche Dateien in Ihrer Installation. Zeilen mit Only in wordpress/... zeigen Dateien, die in der Installation fehlen. Zeilen mit Files ... differ zeigen inhaltliche Abweichungen. Sehen Sie sich auch unerwartete Verzeichnisse an.

Plugins und Themes: Wo Checksummen an Grenzen stoßen

WP-CLI kann auch Plugins prüfen:

wp plugin verify-checksums --all

Das funktioniert nur bei Plugins aus dem WordPress.org-Verzeichnis, denn nur für diese gibt es veröffentlichte Checksummen. Plugins ohne passenden Checksummensatz auf WordPress.org lassen sich so nicht prüfen.

Behält eine genullte oder manipulierte Kopie Slug und Version eines WordPress.org-Plugins bei, kann der Befehl sie trotzdem vergleichen und meldet die veränderten Dateien. Einen vergleichbaren eingebauten Befehl für Theme-Checksummen hat WP-CLI nicht.

Für solche Plugins und für Themes besorgen Sie sich genau die installierte Version aus der offiziellen Quelle oder einem vertrauenswürdigen Build-Archiv. Bei Eigenentwicklungen nehmen Sie ein bekanntermaßen sauberes Release-Artefakt, keine Kopie von der verdächtigen Website. Dann vergleichen Sie mit der installierten Fassung:

diff -rq ~/clean/some-premium-plugin wp-content/plugins/some-premium-plugin

Achten Sie außerdem auf Plugin-Ordner, die Sie keiner Ihrer Installationen zuordnen können. Ein unbekannter Ordner in wp-content/plugins ist ein Alarmsignal. Ein genulltes Plugin ist schon für sich ein Problem, egal was der Diff ergibt. Wie Sie genullte und verwaiste Plugins ersetzen, steht im Leitfaden zu Plugin-Schwachstellen.

WordPress-Core sicher neu installieren

Sichern Sie zuerst die Beweise und erstellen Sie ein vollständiges Backup. Ersetzen Sie dann den Core durch eine saubere Kopie derselben Version:

wp core download --force --skip-content --version=6.8.3

Ergänzen Sie bei Bedarf --locale=de_DE oder Ihre Sprache. Der Befehl überschreibt die Core-Dateien. wp-config.php bleibt unangetastet, weil das Paket keine solche Datei enthält. --skip-content lässt wp-content unverändert.

Zusätzliche Dateien entfernt der Befehl nicht. Eine Datei wie wp-includes/class-wp-cache-handler.php bleibt liegen, denn der Download schreibt nur offizielle Dateien. Kopieren und prüfen Sie jede zusätzliche Datei zuerst. Löschen Sie anschließend die, die schädlich oder nachweislich überflüssig sind. Führen Sie danach erneut wp core verify-checksums aus und kontrollieren Sie, dass keine ungeklärten Warnungen übrig sind.

Was ein sauberes Ergebnis nicht aussagt

Ein grünes Ergebnis betrifft nur den WordPress-Core. Nichts sagt es aus über:

• wp-content: Themes, Premium- und Eigenentwicklungs-Plugins, mu-plugins und uploads
• wp-config.php und .htaccess, die nicht auf der Checksummenliste stehen
• die Datenbank: eingeschleuste Optionen, Spam in Beiträgen, fremde Administratorkonten, geplante Cron-Ereignisse
• Dateien außerhalb von WordPress, etwa andere PHP-Dateien im Hosting-Account oder die Serverkonfiguration

Angreifer wissen, welche Dateien geprüft werden. Auch deshalb ist wp-content/uploads ein beliebter Ablageort für Web-Shells. Für die übrigen Prüfungen gehen Sie die Anzeichen einer gehackten Website durch. Für den Upload-Ordner nutzen Sie den Leitfaden zu Web-Shells.

Dateiintegrität dauerhaft überwachen

Ein einmaliger Check hilft während eines Vorfalls. Eine regelmäßige Prüfung kann die Zeit verkürzen, in der eine Änderung unbemerkt bleibt. Bis zum nächsten Lauf können Besucher aber bereits betroffen sein. Ein kleines Skript per Cron reicht aus:

#!/bin/bash
cd /var/www/example.com || exit 1
OUT=$(/usr/local/bin/wp core verify-checksums 2>&1)
if [ $? -ne 0 ] || echo "$OUT" | grep -q "Warning:"; then
  echo "$OUT" | mail -s "Core checksum alert: example.com" admin@example.com
fi

Richten Sie das Skript in der Crontab des Website-Eigentümers ein, nicht in der von root. Es schlägt bei einem Exit-Code ungleich null Alarm und bei jeder Warnung, also auch bei gemeldeten zusätzlichen Dateien. Setzen Sie einen festen PATH oder verwenden Sie vollständige Programmpfade, denn Cron läuft mit einer eingeschränkten Umgebung. Testen Sie, ob eine Warnung tatsächlich ankommt, und ersetzen Sie mail bei Bedarf durch Ihr funktionierendes Alarmierungssystem.

Für wp-content legen Sie nach jedem sauberen Update eine eigene Referenz an:

find wp-content/plugins wp-content/themes -type f -exec sha256sum {} + > ~/baseline-$(date +%F).sha256

Speichern Sie diese Referenz außerhalb des Web-Roots, am besten nicht auf demselben Server. Zur Prüfung führen Sie im Hauptverzeichnis der Website sha256sum -c --quiet gegen die Referenz aus. So finden Sie veränderte und gelöschte Dateien, aber keine neuen. Neue Dateien erkennen Sie, indem Sie eine frische find-Dateiliste mit der Liste aus der Referenz vergleichen. Legen Sie nach jedem legitimen Update eine neue Referenz an, sonst meldet der nächste Check Ihre eigenen Änderungen.

Regelmäßige Prüfungen helfen auch bei der Compliance. Art. 32 Abs. 1 lit. d DSGVO verlangt ein Verfahren zur regelmäßigen Überprüfung, Bewertung und Evaluierung der Wirksamkeit Ihrer Sicherheitsmaßnahmen. Eine geplante Integritätsprüfung mit gespeicherten Ergebnissen ist ein konkreter Nachweis für ein solches Verfahren. Den größeren Zusammenhang finden Sie unter Art. 32 DSGVO für WordPress.

Wenn Sie keine Skripte pflegen möchten: Das Plugin Security Audit & Compliance von secaudit.eu führt eine Referenz für die Dateiintegrität und meldet veränderte Dateien sowie verschleierte Inhalte. Außerdem prüft es die Core-Checksummen. Es erkennt und meldet. Die Bereinigung bleibt Ihre Aufgabe oder die Ihrer Agentur.

FAQ

Funktioniert verify-checksums auch bei Multisite und nicht-englischen Installationen?

Ja. Ein Multisite-Netzwerk teilt sich einen Satz Core-Dateien, ein Durchlauf deckt also das gesamte Netzwerk ab. Bei nicht-englischen Installationen geben Sie die richtige --locale an, denn lokalisierte Pakete können von en_US abweichen.

Bedeutet „File should not exist“ immer Malware?

Nein. Auch Dateien, die ältere WordPress-Versionen zurückgelassen haben, lösen die Warnung aus. Bewahren Sie eine Kopie auf und prüfen Sie die Datei. Entfernen Sie sie, wenn sie schädlich oder nachweislich überflüssig ist. Unerklärlicher PHP-Code in einem Core-Ordner verdient aber immer einen genauen Blick.

Wie oft sollte ich die Prüfung ausführen?

Für die meisten Unternehmenswebsites ist eine tägliche Prüfung per Cron sinnvoll. Zusätzlich nach einem Vorfall, nach jedem Core-Update und immer dann, wenn eine neue Person Serverzugang erhält.

Kann ein Angreifer das Ergebnis fälschen?

Die Checksummen selbst kommen per HTTPS von WordPress.org. Wer Ihren Server kontrolliert, kann aber die lokalen Werkzeuge manipulieren, etwa die WP-CLI-Datei oder Systemprogramme. Im Zweifel kopieren Sie die Website-Dateien auf einen sauberen Rechner und vergleichen sie dort mit einem frischen Download desselben Releases.