Kurz gesagt: Eine WordPress-Backdoor finden Sie am schnellsten, indem Sie Kern und Plugins per WP-CLI gegen die offiziellen Prüfsummen abgleichen und danach gezielt mu-plugins, Uploads, wp-config.php, Admin-Konten und Datenbank durchsehen. Wichtig nach PHP2Shell: Ein WordPress-Update schließt die PHP-Lücke nicht und entfernt keine vorhandene Hintertür.
Warum WordPress-Betreiber jetzt genauer hinsehen sollten
Mit PHP2Shell sind im Oktober 2026 zwei kritische Lücken in PHP selbst bekannt geworden, CVE-2026-109618 und CVE-2026-109619. Sie erlauben die Ausführung von Schadcode ohne Anmeldung, unabhängig davon, wie gepflegt Ihre WordPress-Installation ist. Patches gibt es seit dem 21.10.2026, laut Medienberichten wurde ein erster Angriffsversuch aber schon am 17.10. beobachtet.
Wer in diesem Zeitraum verwundbar war, sollte nach Spuren suchen. WordPress ist dabei ein typisches Ziel, weil viele Installationen ähnlich aufgebaut sind und Angreifer die Verstecke kennen. Was Betreiber zum Thema PHP2Shell allgemein tun müssen, steht auf der Seite WordPress und PHP2Shell.
Arbeiten Sie die folgenden Prüfungen möglichst auf einer Kopie oder nach einer Sicherung durch. Die Befehle lesen nur und verändern nichts.
Woran Sie eine Backdoor im Alltag bemerken
Eine Hintertür ist darauf ausgelegt, unauffällig zu bleiben. Trotzdem gibt es Anzeichen, die auch ohne technisches Wissen auffallen. Dazu gehören Weiterleitungen auf fremde Seiten, die nur bei Besuchern aus der Google-Suche oder nur auf Mobilgeräten auftreten. Ebenso verdächtig sind neue Seiten mit Werbung für Medikamente, Glücksspiel oder Kopien von Markenprodukten, die im Suchindex erscheinen, aber nicht im WordPress-Backend.
Weitere Hinweise sind Warnungen von Google oder vom Browser, Beschwerden von Kunden über Spam-Mails von Ihrer Domain, ein plötzlich stark gestiegener Verbrauch von Rechenzeit beim Hoster oder Administratoren, die niemand im Team kennt. Keines dieser Zeichen beweist für sich eine Backdoor. Treten mehrere zusammen auf, sollten Sie die folgenden Prüfungen nicht aufschieben.
Umgekehrt gilt: Wenn nichts davon auffällt, heißt das nicht, dass die Installation sauber ist. Gerade Hintertüren, die nur für einen späteren Zugriff angelegt wurden, zeigen nach außen oft gar keine Wirkung.
WordPress-Backdoor finden: Kern und Plugins prüfen
WP-CLI kann die Dateien des WordPress-Kerns und der Plugins aus dem offiziellen Verzeichnis mit den veröffentlichten Prüfsummen vergleichen. Jede Abweichung ist ein konkreter Prüfauftrag.
cd /var/www/meine-seite
# Kerndateien gegen die offiziellen Prüfsummen
wp core verify-checksums
# Plugins aus dem offiziellen Verzeichnis
wp plugin verify-checksums --all
# Installierte Versionen und Status
wp plugin list
wp theme list
Kommerzielle Plugins und Themes lassen sich so nicht prüfen. Für sie hilft nur der Vergleich mit einem frisch heruntergeladenen Originalpaket des Anbieters. Unbekannte Plugins, die niemand im Team installiert hat, sind immer verdächtig, auch wenn sie deaktiviert erscheinen.
Typische Verstecke im Dateisystem
Einige Orte tauchen bei kompromittierten WordPress-Installationen immer wieder auf:
wp-content/mu-plugins/: wird automatisch geladen und erscheint nicht in der normalen Plugin-Liste.wp-content/uploads/: dort gehören Bilder und Dokumente hin, keine PHP-Dateien.wp-config.php: zusätzlicheinclude- oderrequire-Zeilen am Anfang oder Ende..htaccessund.user.iniim Webverzeichnis und in Unterordnern: unerwartete Weiterleitungen oder automatisch vorgeladene Dateien.- Dateien im Hauptverzeichnis, deren Namen an WordPress-Kerndateien erinnern, aber nicht dazugehören.
# PHP-Dateien im Upload-Ordner
find wp-content/uploads -type f -name "*.php*"
# Inhalt der Must-Use-Plugins
ls -la wp-content/mu-plugins/
# Alle .htaccess- und .user.ini-Dateien mit Änderungsdatum
find . \( -name ".htaccess" -o -name ".user.ini" \) -exec ls -la {} +
# Kürzlich geänderte PHP-Dateien
find . -type f -name "*.php" -newermt "2026-10-17" -ls
Allgemeine Suchmuster für verschleierten Code beschreibt der Ratgeber Webshells erkennen und entfernen.
Benutzer, Datenbank und geplante Aufgaben prüfen
Viele Hintertüren liegen gar nicht im Dateisystem. Ein zusätzliches Administrator-Konto reicht Angreifern oft, um später zurückzukehren.
# Alle Administratoren mit Registrierungsdatum
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
# Geplante Aufgaben in WordPress
wp cron event list
# Adresse der Seite (Manipulationen führen zu Weiterleitungen)
wp option get siteurl
wp option get home
# Beiträge mit eingebetteten Skripten
wp db query "SELECT ID, post_title FROM $(wp db prefix)posts WHERE post_content LIKE '%<script%'"
Prüfen Sie auch Optionen mit ungewöhnlich großen Inhalten und Widgets mit fremdem Code. Treffer bedeuten nicht automatisch einen Angriff, denn Tracking-Codes oder eingebettete Karten nutzen ebenfalls Skripte. Entscheidend ist, ob jemand im Team den Inhalt kennt.
Wechseln Sie nach einem Fund alle Passwörter und die Sicherheitsschlüssel in wp-config.php. Sonst bleiben bestehende Anmeldungen der Angreifer gültig.
Hintertüren schließen und Wiederkehr verhindern
Wenn Sie eine Backdoor gefunden haben, ist eine Neuinstallation meist sicherer als das Reparieren einzelner Dateien. Bewährt hat sich diese Reihenfolge:
- Spuren sichern: Logs, verdächtige Dateien und einen Datenbank-Export mit Datum ablegen.
- PHP auf einen behobenen Stand bringen und alle PHP-Prozesse neu starten.
- WordPress-Kern, Plugins und Themes frisch aus Originalquellen installieren.
- Uploads und Datenbank geprüft übernehmen, fremde Konten löschen, alle Zugänge wechseln.
- PHP-Ausführung im Upload-Ordner auf Serverebene unterbinden.
Für Nginx genügt dafür ein Block in der Serverkonfiguration:
location ~* ^/wp-content/uploads/.*\.php$ {
deny all;
}
Unter Apache erreichen Sie dasselbe mit einer Regel in der Serverkonfiguration für den Upload-Ordner. Eine .htaccess im Upload-Ordner selbst ist schwächer, weil ein Angreifer mit Schreibrechten sie wieder ändern kann.
Planen Sie nach der Bereinigung einige Wochen engere Beobachtung ein. Neue Administratoren, neue PHP-Dateien und Änderungen an wp-config.php sollten in dieser Zeit sofort auffallen, etwa durch eine regelmäßige Prüfung per WP-CLI oder eine Dateiüberwachung auf dem Server.
Wie Sie die Dateirechte anschließend so setzen, dass WordPress nur dort schreiben darf, wo es nötig ist, zeigt der Ratgeber Dateirechte auf dem Webserver.
Wie hilft PHP SOS konkret?
- Wir sichern den Zustand der Installation, bevor etwas verändert wird.
- Wir prüfen Kern, Plugins, Themes, Datenbank, Konten und Serverkonfiguration auf Hintertüren.
- Wir setzen WordPress aus sauberen Quellen neu auf und übernehmen nur geprüfte Inhalte.
- Wir härten Server und Installation und dokumentieren, was gefunden und behoben wurde.
Den Ablauf einer Bereinigung beschreibt die Leistung Malware und Webshells entfernen lassen.
Häufige Fragen
Schließt ein WordPress-Update die PHP2Shell-Lücke?
Nein. PHP2Shell steckt im PHP-Interpreter, nicht in WordPress. Ein Update von WordPress, Themes oder Plugins ändert daran nichts; entscheidend ist der PHP-Stand des Servers und ein Neustart aller PHP-Prozesse.
Findet ein Sicherheits-Plugin alle Backdoors?
Nicht zuverlässig. Ein Plugin läuft innerhalb der kompromittierten Installation und kann selbst manipuliert sein. Ergänzen Sie es um Prüfungen von außen, etwa per WP-CLI-Prüfsummen und einem Vergleich mit sauberen Originaldateien.
Was sind mu-plugins und warum sind sie verdächtig?
Must-Use-Plugins im Ordner wp-content/mu-plugins werden automatisch geladen und erscheinen nicht in der normalen Plugin-Liste. Angreifer nutzen das gern, weil Betreiber diesen Ordner selten ansehen.
Kann eine Backdoor auch in der Datenbank stecken?
Ja. Schadcode oder Weiterleitungen werden häufig in Optionen, Beiträgen oder Widgets abgelegt. Zusätzlich legen Angreifer oft eigene Administrator-Konten an, die Sie in der Benutzertabelle finden.