--- title: "WordPress-Dateien auf Veränderungen prüfen: Core und Plugins mit verify-checksums kontrollieren" date: 2026-09-30T21:28:38+02:00 modified: 2026-10-23T22:13:34+02:00 category: wordpress type: how_to author: Marcel Schönfelder canonical: https://s-edv.com/anleitungen/wordpress-core-verify-checksums-datei-integritaet-pruefen keywords: - WordPress - WP-CLI - Sicherheit - Integrität - Malware reading_time: 9 --- # 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. **Kurzfassung:** `wp core verify-checksums` vergleicht alle Kerndateien mit den offiziellen MD5-Prüfsummen von WordPress.org, `wp plugin verify-checksums --all` tut dasselbe für Plugins aus dem Verzeichnis. Veränderte oder fehlende Dateien führen zu Exit-Code 1. Zusätzliche Dateien in `wp-admin` und `wp-includes` erscheinen nur als Warnung „File should not exist“, der Exit-Code bleibt 0. Werten Sie in Skripten deshalb auch die Warnungen aus. Ersetzen Sie veränderte Kerndateien mit `wp core download --skip-content --force` und löschen Sie fremde Dateien erst nach der Untersuchung. ## 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: ```bash $ 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: ```plaintext 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. > **Prüfen:** 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: ```plaintext 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. > **Prüfen:** 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: ```bash $ 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: ```plaintext 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. > **Prüfen:** 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: ```bash $ 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: ```bash $ 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: ```bash $ 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. > **Prüfen:** 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. > **Prüfen:** `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: ```bash #!/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](https://s-edv.com/anleitungen/wordpress-wp-cron-echte-cronjobs-einrichten). 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](https://wordpressupdate.de/?utm_source=s-edv.com&utm_medium=artikel&utm_campaign=46) übernimmt Updates von WordPress, Plugins und Themes, wöchentliche Backups auf externen Speicher sowie Einrichtung und Wartung der Firewall. > **Prüfen:** 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. ## 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](https://wordpressupdate.de/?utm_source=s-edv.com&utm_medium=fazit&utm_campaign=46) von Marcel Schönfelder. ## Weiterführende Anleitungen und Quellen - [WordPress-Plugin nach fehlerhaftem Update zurücksetzen](https://s-edv.com/anleitungen/wordpress-plugin-update-rollback-vorherige-version) - [Benutzerrollen in WordPress sauber vergeben](https://s-edv.com/anleitungen/wordpress-benutzerrollen-rechte-vergeben) - [WordPress Cron Job einrichten: WP-Cron durch echten System-Cron ersetzen](https://s-edv.com/anleitungen/wordpress-wp-cron-echte-cronjobs-einrichten) - [WP-CLI-Handbuch: wp core verify-checksums](https://developer.wordpress.org/cli/commands/core/verify-checksums/) - [WP-CLI-Handbuch: wp plugin verify-checksums](https://developer.wordpress.org/cli/commands/plugin/verify-checksums/) - [WP-CLI-Handbuch: wp core download](https://developer.wordpress.org/cli/commands/core/download/) - [WordPress Advanced Administration: Hardening WordPress](https://developer.wordpress.org/advanced-administration/security/hardening/)