Kurz gesagt: Um CMS-Kerndateien zu prüfen, vergleichen Sie die installierten Dateien mit einem sauberen Original derselben Version: bei WordPress über die offiziellen Prüfsummen, bei anderen Systemen über einen frischen Download oder einen Nachbau aus der composer.lock. Jede Abweichung ist ein Prüfauftrag. Der Abgleich findet auch unbekannten Schadcode, deckt aber nur Dateien ab, für die es ein Original gibt.
Warum der Vergleich mehr findet als jede Signatur
Malware-Scanner suchen nach bekannten Mustern. Was sie nicht kennen, übersehen sie. Ein Abgleich mit dem Original arbeitet umgekehrt: Er fragt nicht, ob eine Datei verdächtig aussieht, sondern ob sie exakt dem entspricht, was der Hersteller ausgeliefert hat. Jede Abweichung fällt auf, ob sie einem bekannten Muster folgt oder nicht.
Das ist nach PHP2Shell besonders wertvoll. Für die Lücken CVE-2026-109618 und CVE-2026-109619 gibt es keine veröffentlichten, bestätigten Indicators of Compromise. Scanner können also nicht gezielt nach PHP2Shell-Spuren suchen. Ein Abgleich mit dem Original findet dagegen jede Veränderung am Kern, unabhängig davon, wie sie entstanden ist. Warum Scanner allein nicht reichen, erklärt der Beitrag Malware-Scanner für Websites: Was sie finden und was nicht.
Das Prinzip: gleiche Version, saubere Quelle
Ein Vergleich ist nur so gut wie seine Referenz. Drei Bedingungen müssen erfüllt sein:
- Exakt dieselbe Version: Ein Vergleich gegen eine neuere Version zeigt hunderte harmlose Unterschiede. Ermitteln Sie die installierte Version aus der Anwendung oder der
composer.lock. - Offizielle Quelle: Das Original stammt vom Hersteller, aus dem offiziellen Paketverzeichnis oder aus Ihrem eigenen Versionskontrollsystem. Nicht aus einem alten Backup des betroffenen Servers.
- Vergleich auf einer Kopie: Arbeiten Sie auf einer gesicherten Kopie des Webverzeichnisses, damit Zeitstempel und Spuren erhalten bleiben.
| System | Referenz | Werkzeug |
|---|---|---|
| WordPress-Kern und Plugins aus dem Verzeichnis | Prüfsummen von WordPress.org | wp core verify-checksums, wp plugin verify-checksums |
| Composer-Projekte (z. B. Shopware 6, Laravel, Symfony, Drupal, TYPO3 im Composer-Modus) | Nachbau aus composer.lock |
composer install in leerem Verzeichnis, dann diff |
| CMS mit Download-Paket | Paket gleicher Version vom Hersteller | diff -rq |
| Eigene Projekte mit Git | letzter bekannter Commit | git status, git diff |
| Systempakete des Servers | Paketdatenbank der Distribution | dpkg --verify, rpm -Va |
WordPress: mehr als verify-checksums
Wie Sie Kern und Plugins mit WP-CLI prüfen, steht im Ratgeber Backdoors in WordPress finden. Eine Ergänzung lohnt sich: Laut WP-CLI-Dokumentation prüft die Option --include-root alle Dateien und Ordner im Hauptverzeichnis und warnt vor Einträgen, die nicht zu WordPress gehören. Dort legen Angreifer gern Dateien ab, deren Namen an Kerndateien erinnern.
# Kern gegen offizielle Prüfsummen, inklusive fremder Dateien im Hauptverzeichnis
wp core verify-checksums --include-root
Kommerzielle Plugins und Themes erfasst dieser Weg nicht. Für sie laden Sie das Originalpaket derselben Version beim Anbieter herunter und vergleichen mit diff.
CMS-Kerndateien prüfen bei Composer-Projekten
Viele moderne PHP-Anwendungen bestehen zum größten Teil aus Paketen, die Composer installiert, die Paketverwaltung für PHP. Wie sie arbeitet, erklärt die Seite Composer: Die Paketverwaltung für PHP. Die Datei composer.lock hält fest, welche Versionen genau installiert sind. Laut Composer-Dokumentation verwendet composer install diese exakten Versionen. Damit lässt sich der Auslieferungszustand nachbauen:
# Auf einem sauberen System, nicht auf dem betroffenen Server
mkdir /tmp/referenz && cd /tmp/referenz
cp /pfad/zur/kopie/composer.json /pfad/zur/kopie/composer.lock .
composer install --no-scripts --no-plugins --no-autoloader
# Unterschiede im vendor-Ordner auflisten
diff -rq /tmp/referenz/vendor /pfad/zur/kopie/vendor
Die Optionen --no-scripts und --no-plugins verhindern, dass beim Nachbau Skripte aus den Paketen ausgeführt werden. Wurde die Produktion mit --no-dev installiert, nutzen Sie diese Option auch beim Nachbau, sonst erscheinen Entwicklungspakete als Unterschied. Achten Sie auf zwei Ergebnisarten: Dateien, die sich unterscheiden, und Dateien, die nur auf dem Server existieren. Die zweite Gruppe ist oft die interessantere. Wie Sie die installierten Pakete zusätzlich auf bekannte Lücken prüfen, beschreibt der Ratgeber Composer-Abhängigkeiten auf Lücken prüfen.
Auch das Betriebssystem vergleichen
Hatte ein Angreifer Root-Rechte, kann er auch Systemprogramme ersetzt haben. Die Paketverwaltungen bringen einen eigenen Abgleich mit:
# Debian, Ubuntu: Dateien, deren Inhalt vom Paket abweicht
sudo dpkg --verify
# RHEL, AlmaLinux, Rocky: alle Pakete prüfen
sudo rpm -Va
Eine 5 an dritter Stelle der Ausgabe bedeutet, dass sich der Inhalt einer Datei geändert hat. Laut dpkg-Handbuch ist der Inhaltsabgleich dort derzeit die einzige wirksame Prüfung. Geänderte Konfigurationsdateien sind normal und mit c markiert. Ein verändertes Programm in /usr/bin ist dagegen ein ernstes Alarmzeichen. Beachten Sie: Ein Angreifer mit Root-Rechten kann auch die Paketdatenbank manipulieren. Bei Verdacht auf Root-Zugriff ist ein Neuaufbau verlässlicher als jeder Abgleich.
Ein Versionskontrollsystem für den Anwendungscode macht künftige Abgleiche zur Sache von Sekunden. git status zeigt dann jede Abweichung vom freigegebenen Stand.
Abweichungen bewerten und Grenzen kennen
Nicht jede Abweichung ist ein Angriff. Manche Agenturen haben Kerndateien früher direkt angepasst, statt Erweiterungen zu nutzen. Sprachpakete, Zeilenenden nach einer Übertragung per FTP oder nachträglich eingespielte Korrekturen erzeugen ebenfalls Unterschiede. Entscheidend ist, ob jemand die Änderung erklären kann.
Gehen Sie jede Abweichung einzeln durch und notieren Sie das Ergebnis: bekannt und dokumentiert, harmlos erklärbar oder unklar. Unklare Dateien öffnen Sie nur als Text auf einer Kopie und ersetzen sie aus der sauberen Quelle. Bei Dateien, die nur auf dem Server existieren, ist die Frage einfacher: Wer sie nicht kennt, sollte sie sichern und entfernen lassen, nachdem ihr Inhalt geprüft wurde.
Uploads, Konfigurationsdateien wie wp-config.php oder .env, eigene Anpassungen und Caches haben kein Original. Sie müssen gezielt geprüft werden, ebenso die Datenbank, Cronjobs, Benutzerkonten und SSH-Schlüssel. Ein sauberer Abgleich ist deshalb ein wichtiger Baustein, aber kein Freispruch für den ganzen Server.
Wie hilft PHP SOS konkret?
- Wir ermitteln die installierten Versionen und bauen eine saubere Referenz aus offiziellen Quellen auf.
- Wir vergleichen Kern, Erweiterungen, Composer-Pakete und Systemprogramme und bewerten jede Abweichung.
- Wir prüfen die Bereiche ohne Original gezielt und ersetzen veränderte Dateien im Rahmen der Malware-Entfernung aus sauberer Quelle.
- Wir richten auf Wunsch einen Versionsstand ein, gegen den künftige Prüfungen laufen.
Häufige Fragen
Wie prüfe ich, ob WordPress-Kerndateien verändert wurden?
Mit WP-CLI und dem Befehl wp core verify-checksums. Er vergleicht die Dateien mit den Prüfsummen, die WordPress.org für die installierte Version veröffentlicht. Mit der Option --include-root warnt WP-CLI zusätzlich vor Dateien im Hauptverzeichnis, die nicht zu WordPress gehören.
Was mache ich bei einem CMS ohne eingebaute Prüffunktion?
Sie laden exakt dieselbe Version aus der offiziellen Quelle des Herstellers herunter und vergleichen beide Verzeichnisse mit diff. Bei Composer-Projekten bauen Sie den Stand aus der composer.lock in einem leeren Verzeichnis nach und vergleichen den vendor-Ordner.
Findet der Abgleich auch Schadcode in Plugins und Themes?
Nur, wenn es für diese ein sauberes Original gibt, etwa aus dem offiziellen Verzeichnis oder vom Anbieter. Eigene Anpassungen, Uploads und Konfigurationsdateien haben kein Original und müssen gesondert geprüft werden.
Ersetzt der Abgleich einen Malware-Scanner?
Er ergänzt ihn. Der Abgleich findet jede Veränderung an bekannten Dateien, auch unbekannten Schadcode. Er sagt aber nichts über Dateien ohne Original, die Datenbank, Cronjobs oder Zugänge.