WordPress gehackt prüfen: Konten, Plugins und verdächtige Dateien nach dem Update auf 7.1.4

Das Update auf WordPress 7.1.4 ist eingespielt — vielleicht erst ein paar Tage nach dem Release vom 28. Oktober 2026, vielleicht durch ein automatisches Hintergrundupdate, dessen Abschluss niemand kontrolliert hat. Die eigentliche Frage beginnt jetzt: War zwischen dem Zeitpunkt der Veröffentlichung und dem Einspielen des Patches schon jemand auf der Website?

Die Sicherheitslücke CVE-2026-119977 beschreibt genau dieses Szenario. Beim Update mit einem vollständigen Paket entpackt WordPress die neuen Dateien in ein vorhersagbares Verzeichnis unterhalb von wp-content/upgrade/. Auf vielen Servern ist dieses Verzeichnis aus dem Web erreichbar. Das temporäre Verzeichnis enthält eine Kopie des WordPress-Installers — und wer im richtigen Moment zugreift und PHP ausführen kann, kann bis zur Codeausführung gelangen. Laut Wordfence registrierte deren Firewall allein in den ersten 21 Stunden nach dem Release mehr als 18.500 Anfragen auf die betroffenen Pfade (Einzelherstellerquelle).

Klar: Das Zeitfenster ist eng. Wordfence beschreibt die Angriffskomplexität als hoch, Patchstack hält die Lücke für nicht praktikabel ausnutzbar. Bestätigte erfolgreiche Angriffe über CVE-2026-119977 sind bis zum Stand dieses Artikels nicht dokumentiert. Aber „kein Beweis für einen Angriff" ist nicht dasselbe wie „kein Angriff". Wenn das Update verspätet war, die automatischen Updates nicht überwacht wurden oder die Website ohnehin selten aktiv gepflegt wird, lohnt der Blick in die Logs und Systemdateien.

Dieser Artikel beschreibt, was Sie nach einem verspäteten Update prüfen sollten, worauf die Spuren hindeuten und was im Ernstfall zu tun ist.

Was die Lücke konkret bedeutet — und warum verspätete Updates das Risiko erhöhen

WordPress 7.1.4 behebt 22 Sicherheitslücken. Die schwerste davon — CVE-2026-119977, gemeldet von Umut Bayram — betrifft eine Race Condition im Update-Prozess. Die Bewertung ist uneinheitlich: Wordfence (als CVE Numbering Authority) vergibt einen CVSS-3.1-Basiswert von 8.1 „High" (Vektor AV:N/AC:H/PR:N/UI:N). Das GitHub-Advisory von WordPress stuft dieselbe Lücke als „Low" ein. Der CVE-Eintrag steht in der NVD mit Status „Deferred" ohne eigene Bewertung.

Betroffen sind alle WordPress-Versionen von 4.7 bis 7.1.3. Wer auf 7.1.4 oder einem der Backports aktualisiert hat, hat auch die kritische Lücke CVE-2026-87902 aus Version 7.1.2 geschlossen — eine Pfad-Traversal-Schwachstelle in der Seitenvorlagen-Auflösung, die CISA am 25. September 2026 in den Katalog bekannt ausgenutzter Schwachstellen (KEV) aufgenommen hat. Das bedeutet: Wer heute auf dem aktuellen Stand ist, aber seit August oder September keine Patches eingespielt hat, war potenziell mehreren aktiv ausgenutzten Lücken ausgesetzt.

Websites mit aktivierten automatischen Hintergrundaktualisierungen erhalten Sicherheitsreleases normalerweise zeitnah — aber ob das Update tatsächlich durchgelaufen ist und erfolgreich abgeschlossen wurde, muss gesondert geprüft werden. Ein fehlgeschlagenes automatisches Update bleibt ohne Eingriff oft still unbemerkt.

Die Kernfrage lautet nicht: „Ist meine Website jetzt sicher?" Sie lautet: „War sie es während des Patches-Prozesses?"

WordPress Logs prüfen: Zugriffe auf wp-content/upgrade

Der erste und direkteste Prüfpunkt sind die Webserver-Logs. Suchen Sie nach unerwarteten GET- oder POST-Anfragen auf PHP-Dateien unterhalb von wp-content/upgrade/. Ein normaler Websitebetrieb erzeugt dort keine Zugriffe aus dem Web — das Verzeichnis wird nur während des Update-Vorgangs genutzt.

Auffällig sind vor allem Anfragen, die eine PHP-Datei in einem Unterordner von wp-content/upgrade/ aufrufen, besonders gehäuft rund um den Zeitpunkt eines Core-Updates. Hat der Server eine solche Anfrage mit dem Statuscode 200 beantwortet, ist das ein ernst zu nehmendes Signal. Ein 403 oder 404 bedeutet, dass der Zugriff geblockt oder das Verzeichnis nicht gefunden wurde — was die Wahrscheinlichkeit einer Ausnutzung reduziert, aber nicht ausschließt.

Wo finden Sie die Logs?

Wenn Sie keinen direkten Zugriff auf die Webserver-Logs haben, ist die erste Anlaufstelle Ihr Hosting-Provider. Bei einfacheren Shared-Hosting-Paketen ist der Zugriff auf Rohlog-Dateien nicht immer standardmäßig aktiviert — fragen Sie explizit danach.

Wichtig: Fehlen die Logs oder sind sie zu kurz (viele Provider halten Logs nur 7–30 Tage vor), schließt das eine Kompromittierung nicht aus. Die Abwesenheit eines Log-Eintrags ist kein Beweis für einen sauberen Stand.

Unbekannte Administratorkonten erkennen und prüfen

Ein häufiger Angriffsindikator — unabhängig von der konkreten Einfallstür — ist ein neu angelegtes Benutzerkonto mit Administratorrechten. Prüfen Sie unter WordPress-Dashboard → Benutzer → Alle Benutzer gezielt:

• Konten mit der Rolle „Administrator", die Sie nicht kennen oder die kürzlich angelegt wurden
• Konten mit generischen oder zufällig wirkenden Benutzernamen (z. B. wp_admin2, support_acc, zufällige Zeichenfolgen)
• Konten ohne E-Mail-Adresse in einer bekannten Domain Ihres Unternehmens
• Konten, bei denen das Registrierungsdatum in den Zeitraum nach dem Erscheinen der Lücken fällt

Wenn Sie Zugriff auf die Datenbank haben, ist eine direkte Abfrage zuverlässiger als das Dashboard, weil manche Schadsoftware Konten im Dashboard versteckt:

SELECT user_login, user_email, user_registered
FROM wp_users
ORDER BY user_registered DESC
LIMIT 20;

Vergleichen Sie das Ergebnis mit Ihrer bekannten Benutzerliste. Unbekannte Konten nicht sofort löschen — sichern Sie den Befund zuerst (Screenshot, Export), bevor Sie Änderungen vornehmen.

Unerwartete Plugins: Installiert und ggf. deaktiviert

Angreifer installieren gelegentlich Plugins, um persistenten Zugriff zu behalten — manchmal deaktiviert, damit sie im aktiven Betrieb nicht auffallen. Das WordPress-Dashboard zeigt unter Plugins → Installierte Plugins auch deaktivierte Plugins an.

Prüfen Sie:

• Plugins, die Sie nicht selbst installiert haben
• Plugins mit unklaren oder generisch klingenden Namen ohne Verlags- oder Entwicklerangabe
• Plugins, die keinen Link zum WordPress-Repository haben
• Plugins, deren Dateipfad auf ein ungewöhnliches Verzeichnis zeigt

Eine ergänzende Methode ist der direkte Blick ins Dateisystem. Das Verzeichnis wp-content/plugins/ enthält für jedes Plugin einen eigenen Unterordner. Neue Ordner, die nicht zu installierten Plugins im Dashboard passen, oder Ordner mit zufälligen Namen sind verdächtig.

ls -lt wp-content/plugins/

Der -t-Parameter sortiert nach Änderungszeit — neueste Einträge zuerst. Das macht unbekannte oder kürzlich angelegte Plugin-Verzeichnisse sichtbar.

Fremde PHP-Dateien und veränderte Core-Dateien

PHP-Webshells — Dateien, die einem Angreifer dauerhaften Fernzugriff ermöglichen — werden oft in Verzeichnissen abgelegt, in denen PHP-Dateien grundsätzlich erwartet werden. Typische Ablageorte sind wp-content/uploads/, wp-content/themes/ (in Unterordnern) und wp-content/upgrade/.

Suchen Sie nach PHP-Dateien in Verzeichnissen, die keine PHP-Dateien enthalten sollten:

find wp-content/uploads/ -name "*.php" -type f
find wp-content/upgrade/ -name "*.php" -type f

Jede PHP-Datei in wp-content/uploads/ ist verdächtig — Upload-Verzeichnisse sollten grundsätzlich keine ausführbaren PHP-Dateien enthalten.

WordPress Core-Dateien auf Veränderungen prüfen

Die WordPress-Core-Dateien — also alle Dateien außerhalb von wp-content/ — sollten identisch mit dem offiziellen Release sein. Eine Möglichkeit zur Prüfung ist der WP-CLI-Befehl:

wp core verify-checksums

Dieser Befehl vergleicht alle Core-Dateien mit den offiziellen Prüfsummen aus dem WordPress-Repository. Abweichungen werden aufgelistet. Achtung: Dieser Befehl prüft nur Core-Dateien, nicht Plugins, Themes oder Dateien in wp-content/.

Wenn WP-CLI nicht verfügbar ist, können Sie alternativ manuell einzelne Core-Dateien (z. B. wp-login.php, wp-config.php, wp-includes/functions.php) mit einer frischen WordPress-Installation vergleichen. Veränderte wp-config.php-Dateien sind besonders relevant, weil dort Datenbank-Zugangsdaten und Security-Keys gespeichert sind.

Geplante Aufgaben (Cron Jobs) auf versteckte Einträge prüfen

WordPress nutzt intern einen Pseudo-Cron-Mechanismus (wp-cron). Angreifer können über kompromittierten Code oder direkte Datenbankmanipulation zusätzliche geplante Aufgaben eintragen, die in regelmäßigen Abständen Schadcode ausführen oder externe Verbindungen aufbauen.

Prüfen Sie die registrierten Cron-Einträge über WP-CLI:

wp cron event list

Oder direkt in der Datenbank:

SELECT option_value FROM wp_options WHERE option_name = 'cron';

Das Ergebnis ist ein serialisiertes PHP-Array. Bekannte WordPress-interne Cron-Ereignisse sind beispielsweise wp_version_check, wp_update_plugins und wp_update_themes. Ereignisse mit unbekannten Namen, auffälligen URLs oder ungewöhnlichen Intervallen (z. B. minütlich) sind zu untersuchen.

Zugangsdaten und Passwörter erneuern

Wenn Sie Hinweise auf eine Kompromittierung gefunden haben — oder einfach wegen der verspäteten Aktualisierung sichergehen wollen — sind folgende Zugangsdaten zu erneuern:

1. WordPress-Administratorpasswörter aller Konten mit erhöhten Rechten
2. WordPress Security-Keys und Salts in wp-config.php (neue Werte über den offiziellen Generator unter https://api.wordpress.org/secret-key/1.1/salt/ beziehen)
3. Datenbankpasswort — Änderung sowohl beim Datenbankserver als auch in wp-config.php
4. FTP/SFTP- und SSH-Zugangsdaten beim Hosting-Provider
5. Hosting-Panel-Passwort (cPanel, Plesk o. Ä.)

Die Security-Keys und Salts invalidieren alle aktiven Sitzungen — eingeloggte Nutzer werden beim nächsten Seitenaufruf automatisch ausgeloggt. Das ist im Ernstfall erwünscht, weil es auch etwaige Angreiferkonten aus aktiven Sitzungen wirft.

Praxisbeispiel: Was eine verspätete Aktualisierung in der Praxis bedeutet

Ein hypothetisches Beispiel zur Veranschaulichung: Ein Mittelständler betreibt eine WordPress-Website für seinen Online-Auftritt. Automatische Updates sind aktiv, aber seit Wochen nicht kontrolliert worden. WordPress 7.1.4 erscheint am 28. Oktober 2026. Das automatische Update läuft am Abend desselben Tages durch — drei Stunden, nachdem Wordfence die ersten Zugriffsversuche registriert hat.

Der Betreiber erfährt durch einen Branchenbericht erst zwei Wochen später von der Lücke. Jetzt stellt sich die Frage: War das Zeitfenster in jener Nacht ausreichend, um eine Spur zu hinterlassen?

Ohne Blick in die Logs lässt sich das nicht beantworten. Die Prüfung zeigt: Ein 200-Statuscode auf wp-content/upgrade/ existiert nicht in den Logs. Es gibt kein unbekanntes Administratorkonto. Kein fremdes Plugin. wp core verify-checksums meldet keine Abweichungen. Im Upload-Verzeichnis keine PHP-Dateien.

Das ist ein beruhigendes Ergebnis — aber es schließt eine Kompromittierung nicht mit Gewissheit aus. Es fehlen möglicherweise ältere Logs. Und eine Kompromittierung über CVE-2026-87902 (7.1.2, aktiv ausgenutzt laut CISA) hätte ein anderes Muster hinterlassen.

Die Schlussfolgerung aus einer sauberen Prüfung lautet: Es gibt keine sichtbaren Spuren. Keine Garantie für einen fehlerfreien Stand — aber eine belastbare Grundlage für die weitere Entscheidung.

Was nach einem Fund zu tun ist

Wenn Sie einen oder mehrere der oben beschriebenen Indikatoren finden, gilt eine klare Abfolge:

Schritt 1: Isolieren. Nehmen Sie die Website offline oder blockieren Sie den öffentlichen Zugriff über Ihren Hosting-Provider oder eine .htaccess-Regel. Eine kompromittierte Website liefert möglicherweise Schadcode an Besucher aus.

Schritt 2: Sichern. Erstellen Sie eine vollständige Sicherung des aktuellen Stands — Dateien und Datenbank — als forensischen Snapshot. Nehmen Sie diese Sicherung nicht als Wiederherstellungsgrundlage; sie dokumentiert den kompromittierten Zustand.

Schritt 3: Bereinigen oder aus sauberem Backup wiederherstellen. Die zuverlässigere Methode ist die Wiederherstellung aus einem Backup, das nachweislich vor dem mutmaßlichen Angriffszeitraum liegt. Eine manuelle Bereinigung ist möglich, birgt aber das Risiko, versteckte Hintertüren zu übersehen. Wenn kein belastbares Pre-Incident-Backup vorhanden ist, sind eine vollständige Neuinstallation des WordPress-Cores, eine sorgfältige Prüfung aller Plugins und Themes sowie eine Datenbanksäuberung der nächste Schritt.

Schritt 4: Zugänge erneuern. Alle oben genannten Zugangsdaten ändern, bevor die Website wieder online geht.

Schritt 5: Datenschutzpflichten prüfen. Wenn personenbezogene Daten verarbeitet werden — was bei den meisten geschäftlichen WordPress-Websites der Fall ist (Kontaktformulare, Kommentare, WooCommerce-Bestelldaten, Newsletter-Anmeldungen) — und eine Kompromittierung wahrscheinlich ist, besteht nach Art. 33 DSGVO eine Meldepflicht gegenüber der zuständigen Datenschutzaufsichtsbehörde innerhalb von 72 Stunden nach Bekanntwerden. Art. 34 DSGVO verpflichtet unter bestimmten Voraussetzungen zusätzlich zur Benachrichtigung der Betroffenen. Holen Sie bei Unsicherheit rechtlichen Rat ein.

Grenzen der Selbstprüfung

Die beschriebenen Prüfschritte sind ein sinnvoller erster Überblick — aber keine forensische Volluntersuchung. Ein erfahrener Angreifer kann Logs manipulieren, Zeitstempel von Dateien zurücksetzen oder Schadcode in Datenbankeinträgen verstecken, die weder wp core verify-checksums noch eine einfache Dateisuche aufdeckt. Auch verschlüsselte oder obfuskierte PHP-Payloads in Plugin-Dateien entziehen sich einer schnellen Sichtprüfung.

Die Selbstprüfung liefert belastbare Signale. Sie ersetzt keine professionelle Forensik, wenn der Verdacht konkreter wird oder wenn besonders sensible Daten verarbeitet werden.

Die Lücke CVE-2026-87902 aus September 2026 — von CISA als aktiv ausgenutzt eingestuft — hat außerdem ein ganz anderes Angriffsmuster als CVE-2026-119977. Wer beide Lücken abdecken will, muss den Prüffokus entsprechend anpassen: Bei CVE-2026-87902 geht es um Pfad-Traversal in der Seitenvorlagen-Auflösung, nicht um Zugriffe auf das Upgrade-Verzeichnis. Dort sind unerwartete Dateieinbindungen und Remote-File-Inclusion-Spuren die relevanten Indikatoren.

Mehr zur übergreifenden WordPress-Sicherheit und dauerhaften Absicherung lesen Sie in unserem Grundlageartikel.

Wie SW Business Solutions dabei helfen kann

Die beschriebenen Prüfschritte setzen Zugang zu Webserver-Logs, SSH-Zugang oder direkten Datenbankzugriff voraus — und die Erfahrung, um auffällige Muster von normalem Systembetrieb zu unterscheiden. Beides ist nicht bei jedem Betreiber vorhanden, und das ist keine Kritik: Eine gut gepflegte WordPress-Website erfordert im Normalbetrieb diese Tiefe nicht.

SW Business Solutions prüft WordPress-Websites systematisch auf Spuren eines Angriffs — mit Zugang zu den tatsächlichen Logs, einem Abgleich der Core-Dateien, Plugins und Datenbank sowie einem klaren schriftlichen Befund. Wenn eine Bereinigung oder Wiederherstellung nötig ist, begleiten wir den vollständigen Prozess bis zum nachweislich sauberen Wiederanlauf — einschließlich der Frage, ob und was gegenüber der Datenschutzbehörde zu melden ist.

Wenn Sie unsicher sind, ob Ihre WordPress-Website nach dem Sicherheitsrelease 7.1.4 geprüft werden sollte, ist ein erstes unverbindliches Gespräch der einfachste nächste Schritt.

Für weiterführende Informationen zur Sicherheitsarchitektur und dauerhaften Pflege Ihrer Website empfehlen wir auch den Überblick zu unseren WordPress-Sicherheitsmaßnahmen sowie den Serienartikel WordPress-Sicherheitslücken 2026: Was Unternehmen nach 7.1.2 und 7.1.4 jetzt prüfen müssen.

Autor: Steven Weißheimer, SW Business Solutions. Stand: 03.11.2026. Alle Angaben zu CVEs, Versionen und Angriffszahlen basieren auf den im Artikel verlinkten Primärquellen; eigene Einschätzungen sind als solche gekennzeichnet.