wp-content/upgrade prüfen: so finden Sie heraus, ob die WordPress Updater-Lücke Ihre Website getroffen hat

Von Patrick Schlesinger · Aktualisiert am 30. Oktober 2026

Veröffentlicht: 30.10.2026 · Letzte Aktualisierung: 30.10.2026

Was ist passiert

WordPress 7.1.4 schließt eine Lücke im Update-Prozess des Cores selbst, und Angreifer suchen bereits aktiv nach verwundbaren Installationen. Nach Angaben des Sicherheitsunternehmens Wordfence, über die unter anderem heise online berichtete, zählte Wordfence in den ersten 21 Stunden nach Einführen einer passenden Firewall-Regel mehr als 18.500 Anfragen, die nach anfälligen Installationspfaden für setup-config.php suchten.

Das Release erschien am 28. Oktober 2026. Der offizielle Release-Post auf wordpress.org beschreibt die Lücke als Schwäche im Upgrade-Prozess, die während des Update-Fensters zu Codeausführung führen kann. Gemeldet hat sie der Sicherheitsforscher Umut Bayram. Unsere vollständige Auswertung aller Fixes des Releases finden Sie in der Diff-Analyse zu WordPress 7.1.4. Dieser Artikel behandelt nur die Updater-Lücke und die Frage, die seit den Angriffsversuchen die wichtigere ist: Woran erkennen Sie, ob Ihre Website getroffen wurde?

Unangenehm ist diese Lücke, weil sie nicht in einem Plugin steckt, das man deaktivieren kann, sondern in dem Vorgang, mit dem WordPress sich selbst aktualisiert. Jedes Core-Update vor 7.1.4 hat kurzzeitig ein angreifbares Zeitfenster geöffnet.

Eine CVE-ID ist zum Zeitpunkt dieses Artikels nicht bekannt. In der Berichterstattung über die Wordfence-Warnung wird die Lücke mit CVSS 8.1 als hoch eingestuft.

Die Lücke im Detail: warum das Update-Fenster selbst angreifbar war

Der Kern des Problems ist ein Arbeitsverzeichnis mit vorhersehbarem Namen, das während eines Updates aus dem Internet erreichbar war und eine vollständige, noch nicht konfigurierte WordPress-Kopie samt Installationsskripten enthielt.

Wie der Core ein Update vorbereitet

WordPress entpackt ein Update nicht direkt über die laufende Installation, sondern zunächst in ein Arbeitsverzeichnis unter wp-content/upgrade. Erst danach werden die Dateien an ihre Zielorte kopiert. Bei einem vollständigen Core-Paket liegt in diesem Arbeitsverzeichnis für die Dauer des Vorgangs eine komplette WordPress-Installation, einschließlich wp-admin/setup-config.php, dem Assistenten, der eine wp-config.php anlegt.

Was der Patch verrät

Der öffentliche Commit zum Fix („Upgrade/Install: Improve the handling of the upgrade working directory“, gemergt in die 7.1-Branch am 28. Oktober 2026) zeigt drei Änderungen:

1. Unvorhersehbarer Verzeichnisname: Bisher leitete sich der Name des Arbeitsverzeichnisses aus dem Dateinamen des heruntergeladenen Pakets ab. Jetzt hängt WordPress 16 Zufallszeichen an.
2. Kein Verzeichnis-Listing mehr: Beim Aufräumen von wp-content/upgrade löschte WordPress bisher alle Dateien, auch eine schützende index.php. Jetzt bleibt sie erhalten oder wird neu angelegt. Laut Code-Kommentar soll so verhindert werden, dass der Name des Arbeitsverzeichnisses über ein Directory Listing sichtbar wird.
3. Keine fremde wp-config.php: Beim Kopieren der neuen Core-Dateien überspringt WordPress jetzt eine wp-config.php, „which could have been written to the working directory“, wie es im Code heißt.

Daraus ergibt sich der Angriffsweg, den wir aus dem Code ableiten: Wer das Arbeitsverzeichnis während eines Updates fand und die dort liegende setup-config.php aufrief, konnte eine eigene wp-config.php schreiben lassen, etwa mit Zugangsdaten zu einer selbst kontrollierten Datenbank. Der Updater kopierte diese Datei anschließend über die echte Konfiguration. Ab diesem Punkt ist die Website unter Kontrolle des Angreifers, und Codeausführung auf dem Server ist möglich.

Laut heise online war das Staging-Verzeichnis in Laborumgebungen nur Sekunden verfügbar. Angreifer müssen also ein Wettrennen gegen den Installationsvorgang gewinnen. Dass das trotzdem versucht wird, zeigen die Wordfence-Zahlen.

Aktive Ausnutzung: was Wordfence beobachtet

Wordfence weist laut heise online darauf hin, dass die eigenen Telemetriesysteme bereits Angriffsversuche aufgezeichnet haben. Die Kennzahlen, die heise aus der Wordfence-Warnung wiedergibt:

• mehr als 18.500 Anfragen auf anfällige setup-config.php-Pfade in den ersten 21 Stunden nach Einführen der Firewall-Regel
• zwei der aktivsten Quellen fragten rund 14,5 Stunden lang wiederholt kleine Gruppen von WordPress-Websites ab
• andere Quellen variierten die angefragten Staging-Pfade und Versionsnamen

Für die Praxis heißt das: Es handelt sich um breites Scannen mit Listen plausibler Pfad-Kombinationen, nicht um gezielte Angriffe auf einzelne Websites. Langsame, verteilte Abfragen dieser Art fallen durch einfache Ratelimits leicht hindurch.

Zur Quellenlage

Wir machen transparent, wie belastbar die Angaben sind. Den Original-Beitrag von Wordfence konnten wir bis zur Veröffentlichung nicht abrufen. Die Angriffszahlen und die CVSS-Einstufung stammen deshalb aus der Wiedergabe durch heise online und sind hier als Angaben von Wordfence gekennzeichnet. Release-Datum, Melder, betroffene Versionen und die drei Änderungen im Code haben wir direkt in den Primärquellen geprüft. Zum Release am 28. Oktober war noch keine Ausnutzung bekannt, so stand es auch in unserer Analyse vom selben Tag. Das ist kein Widerspruch, sondern eine Chronologie: Die Telemetriedaten kamen nach dem Release.

Wer ist betroffen

Betroffen sind WordPress-Installationen von 4.7 bis 7.1.3. Anfällig ist nach Angaben von Wordfence allerdings nur ein Update mit dem vollständigen Core-Paket, das WordPress in ein vorhersehbares Verzeichnis unter wp-content/upgrade entpackt.

Das Risiko entstand also nicht im Dauerbetrieb, sondern jeweils während eines Core-Updates. Wer in den vergangenen Wochen mehrfach aktualisiert hat, hatte entsprechend mehr Zeitfenster. Und das war die Regel: Laut WordPress-Sicherheitsteam erschienen zwischen dem 17. September und dem 28. Oktober 2026 vier Sicherheitsreleases in 41 Tagen.

Versionsmatrix

Ihre Branch	Zielversion mit Fix
7.1	7.1.4
7.0	7.0.8
6.9	6.9.11
6.8	6.8.12
6.7	6.7.11
6.6	6.6.11
6.5 bis 6.0	6.5.14, 6.4.14, 6.3.14, 6.2.15, 6.1.16, 6.0.18
5.9 bis 5.0	5.9.20, 5.8.19, 5.7.21, 5.6.23, 5.5.24, 5.4.25, 5.3.27, 5.2.30, 5.1.28, 5.0.31
4.9 bis 4.7	4.9.35, 4.8.34, 4.7.39

Der Release-Post kündigte die Backports als „in progress“ an. Stand 30. Oktober 2026 bietet die offizielle Update-Schnittstelle von WordPress alle oben genannten Versionen an.

Besonders im Blick behalten sollten Sie

• Installationen, die aktuell noch auf 7.1.3 oder älter stehen: Hier ist die Lücke offen, und das nächste Update ist selbst ein Zeitfenster.
• Umgebungen, in denen wp-content/upgrade aus dem Internet erreichbar ist.
• Installationen ohne automatische Hintergrund-Updates, weil die Lücke dort bis zum manuellen Update offen bleibt.
• Agenturen und Unternehmen mit vielen betreuten Installationen. Bei 50 oder 200 Websites ist nicht die Frage, ob eine davon in einem Scan-Fenster lag, sondern welche. Wie wir Installationen betreuen, lesen Sie unter WordPress Wartung.

Timeline

Die Lücke ist kein Einzelfall, sondern Teil einer ungewöhnlich dichten Folge von Sicherheitsreleases.

Datum	Ereignis
30. Oktober 2026	Deutsche Fachmedien berichten über die von Wordfence beobachteten Angriffsversuche
29. Oktober 2026	Das WordPress-Sicherheitsteam zieht Bilanz nach zwei Monaten Core Security Initiative
28. Oktober 2026	WordPress 7.1.4 erscheint, darunter der Fix für die Updater-Lücke, gemeldet von Umut Bayram. Unsere Diff-Analyse zu 7.1.4
6. Oktober 2026	WordPress 7.1.3
22. September 2026	WordPress 7.1.2 gegen CVE-2026-87902
17. September 2026	WordPress 7.1.1 gegen die RCE-Kette Click2Shell
seit Mitte Juli 2026	sieben Core-Sicherheitsreleases mit mehr als 50 als kritisch oder hoch eingestuften Lücken

Den Hintergrund dieser Kadenz beschreibt das WordPress-Sicherheitsteam selbst: 2026 gingen mehr als 3.000 Schwachstellenmeldungen ein, mehr als in den zwölf Jahren davor zusammen. Im Juli waren es 450, im August 773, gegenüber 20 bis 30 pro Monat im langjährigen Mittel. Inzwischen sind 73 Prozent der 109 Schritte eines Sicherheitsreleases automatisiert, Backports betreffen bis zu 25 Branches.

Das erklärt, warum Patches schneller kommen. Es erklärt aber auch, warum die Zeit zwischen Release und Angriff kürzer wird: Jeder öffentliche Patch zeigt, wo gesucht werden muss.

Sofortmaßnahmen: in dieser Reihenfolge

Arbeiten Sie die fünf Schritte in der angegebenen Reihenfolge ab. Schritt 1 schließt die Lücke, die Schritte 2 und 3 beantworten die Frage, ob Sie getroffen wurden, Schritt 4 begrenzt den Schaden, Schritt 5 schützt künftige Updates.

Schritt 1: Version prüfen und aktualisieren

Prüfen Sie zuerst, auf welcher Version Sie stehen. Mit WP-CLI:

wp core version

Ohne WP-CLI öffnen Sie die Datei wp-includes/version.php und suchen die Zeile mit der Variablen $wp_version.

Steht dort eine Version unterhalb der Zielversion Ihrer Branch, aktualisieren Sie jetzt. Warten Sie nicht auf WordPress 7.2, das laut Release-Post für den 8. Dezember 2026 geplant ist.

wp core update
wp core version

Ein Hinweis aus unserer Code-Lektüre: Beim Update auf die Patch-Version entpackt noch der Code der alten Version das Paket. Den abschließenden Kopiervorgang übernimmt aber bereits die neue update-core.php, die keine wp-config.php mehr aus dem Arbeitsverzeichnis übernimmt. Das entschärft den bekannten Angriffsweg, ersetzt aber die Prüfungen in Schritt 2 und 3 nicht.

Schritt 2: wp-content/upgrade auf Rückstände prüfen

Das Verzeichnis sollte nach einem abgeschlossenen Update leer sein oder höchstens eine index.php enthalten. Jede andere PHP-Datei ist verdächtig.

find wp-content/upgrade -name "*.php" -type f -exec ls -la {} \;

So lesen Sie das Ergebnis:

• Keine Ausgabe oder nur eine kleine index.php direkt in wp-content/upgrade: unauffällig.
• Ein Unterverzeichnis mit einer WordPress-Kopie samt setup-config.php: Ein Update wurde nicht sauber abgeschlossen. Prüfen Sie Schritt 3 besonders gründlich.
• Eine wp-config.php in einem Unterverzeichnis oder eine PHP-Datei mit fremdem Namen: Behandeln Sie die Installation als kompromittiert.

Prüfen Sie zusätzlich, ob das Verzeichnis aus dem Web erreichbar ist: Rufen Sie https://ihre-domain.de/wp-content/upgrade/ im Browser auf. Unauffällig sind eine leere Seite, 403 oder 404. Sehen Sie ein Verzeichnis-Listing, ist Schritt 5 für Sie nicht optional.

Schritt 3: Uploads, Core und Logs prüfen

Im Uploads-Verzeichnis haben PHP-Dateien nichts verloren. Suchen Sie nach solchen, die in den vergangenen 45 Tagen angelegt oder geändert wurden:

find wp-content/uploads -name "*.php" -type f -mtime -45 -exec ls -la {} \;

Danach prüfen Sie die Core-Dateien gegen die offiziellen Prüfsummen:

wp core verify-checksums

Jede gemeldete Abweichung gehört geprüft, auch eine scheinbar harmlose. Kontrollieren Sie außerdem die Administratorkonten auf Einträge, die Sie nicht angelegt haben:

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

Und die Zugriffslogs auf Aufrufe des Staging-Verzeichnisses:

grep -i "wp-content/upgrade" /pfad/zum/access.log | grep -i "\.php"

Wo das Access-Log liegt, hängt von Ihrem Hoster und Webserver ab, verbreitet sind etwa /var/log/nginx/access.log oder /var/log/apache2/access.log. Interessant sind Treffer rund um den Zeitpunkt Ihres letzten Core-Updates. Ein Statuscode 200 auf eine setup-config.php unter wp-content/upgrade ist ein ernstes Alarmsignal, ein 403 oder 404 dagegen nur ein gescheiterter Scan.

Zwei Hinweise zur Bewertung. Erstens: Finden Sie eine fremde PHP-Datei, löschen Sie sie nicht einfach und machen weiter. Moderne WordPress-Malware legt mehrere Hintertüren an und stellt sich nach oberflächlicher Bereinigung wieder her, wie wir am Beispiel der selbstheilenden SC-Backdoor gezeigt haben. Gehen Sie in diesem Fall nach unserer Anleitung WordPress gehackt vor. Zweitens: Nicht jeder Alarm eines Security-Plugins ist ein Fund. Timeouts und Prüfabbrüche erzeugen regelmäßig Fehlalarme.

Schritt 4: Zugangsdaten rotieren, wenn Sie etwas gefunden haben

Dieser Schritt gilt, wenn Schritt 2 oder 3 einen Fund ergeben hat. Rotieren Sie dann in dieser Reihenfolge:

1. Die Datenbank-Zugangsdaten in der wp-config.php, weil der Angriffsweg genau auf die Datenbankkonfiguration zielt.
2. Die Sicherheitsschlüssel (Salts) in der wp-config.php. Das beendet alle bestehenden Sitzungen.
3. Alle Administratorpasswörter sowie SFTP- und SSH-Zugangsdaten.
4. API-Schlüssel von Diensten, deren Zugangsdaten in der Installation hinterlegt sind.

Schritt 5: wp-content/upgrade serverseitig sperren

Auch mit 7.1.4 liegt in diesem Verzeichnis bei jedem Update kurzzeitig ausführbarer PHP-Code. Der Update-Vorgang selbst braucht keinen Webzugriff auf das Verzeichnis, er arbeitet direkt im Dateisystem. Sperren Sie den Zugriff aus dem Internet deshalb auf Webserver-Ebene.

Für nginx, im Server-Block der Website:

location ^~ /wp-content/upgrade/ {
    return 404;
}

Für Apache, in der .htaccess im WordPress-Hauptverzeichnis oder im VirtualHost:

RedirectMatch 404 "^/wp-content/upgrade/"

Legen Sie die Apache-Regel nicht als .htaccess in wp-content/upgrade selbst ab: WordPress löscht beim nächsten Update alle Dateien in diesem Verzeichnis außer der index.php. Testen Sie beide Varianten zuerst in einer Staging-Umgebung und spielen Sie dort ein Update testweise ein. Die Dateirechte des Verzeichnisses sind der zweite Teil derselben Frage, dazu haben wir verbreitete Fehlannahmen zu Dateirechten aufgearbeitet. Weitere Maßnahmen zur Absicherung finden Sie unter WordPress Sicherheit.

Einschätzung von CMS ADMINS

Das eigentliche Problem ist nicht diese einzelne Lücke, sondern die Kadenz dahinter. Vier Sicherheitsreleases in 41 Tagen bedeuten, dass Abwarten kaum noch vertretbar ist.

Wer manuell und unregelmäßig aktualisiert, hat sich im Herbst 2026 nicht einmal, sondern mehrfach für ein Risiko entschieden. Bei einer Website ist das eine Abwägung. Bei 50 betreuten Installationen ist es eine Frage von Prozess und Werkzeug, mehr dazu für Digital- und Marketing-Agenturen.

Die wirksamste Gegenmaßnahme liegt beim Webserver

Bemerkenswert an der Updater-Lücke ist, wo der stärkste Schutz liegt: nicht nur in WordPress, sondern in der Webserver-Konfiguration. Wird wp-content/upgrade nie öffentlich ausgeliefert, läuft der beschriebene Angriffsweg ins Leere, auch bei künftigen Fehlern im Updater. Fragen Sie Ihren Hoster, ob eine solche Sperre gesetzt ist, oder setzen Sie sie selbst. Unsere Hosting-Angebote finden Sie unter WordPress Hosting.

Automatische Updates sind hier Schutz und Risiko zugleich

Automatische Hintergrund-Updates verkürzen das Angriffsfenster drastisch, weil der Patch ohne menschliches Zutun läuft. Gleichzeitig laufen sie selbst durch den Update-Prozess. Die Konsequenz ist nicht, Auto-Updates abzuschalten, sondern das Arbeitsverzeichnis serverseitig zu sperren, damit ein Update kein öffentliches Zeitfenster mehr erzeugt.

FAQ

Wird die WordPress Updater-Lücke tatsächlich aktiv ausgenutzt?

Ja, es laufen Angriffsversuche. Nach Angaben von Wordfence zählte das Unternehmen in den ersten 21 Stunden nach Einführen einer passenden Firewall-Regel mehr als 18.500 Anfragen, die nach anfälligen setup-config.php-Pfaden unter wp-content/upgrade suchten. Die Anfragen variierten Staging-Pfade und Versionsnamen. Das spricht für breites, automatisiertes Scannen und nicht für gezielte Angriffe auf einzelne Websites.

Welche WordPress-Versionen sind betroffen und auf welche Version muss ich aktualisieren?

Betroffen sind alle Versionen von 4.7 bis 7.1.3. Die Zielversion hängt von Ihrer Branch ab: 7.1.4 für die 7.1er Reihe, sonst zum Beispiel 7.0.8, 6.9.11, 6.8.12, 6.7.11 oder 6.6.11. Für ältere Branches gibt es Backports bis hinunter zu 4.7.39. Warten Sie nicht auf WordPress 7.2, das ist erst für den 8. Dezember 2026 geplant.

Woran erkenne ich, ob meine Website über die Updater-Lücke angegriffen wurde?

Drei Prüfungen geben Aufschluss. Erstens: Liegen in wp-content/upgrade andere PHP-Dateien als eine index.php, ist das verdächtig. Zweitens: PHP-Dateien im Uploads-Verzeichnis gehören dort nicht hin. Drittens: wp core verify-checksums meldet veränderte Core-Dateien. Prüfen Sie außerdem das Access-Log auf Zugriffe mit Statuscode 200 auf setup-config.php unter wp-content/upgrade. Bei einem Fund nichts löschen, sondern strukturiert bereinigen.

Reichen automatische Hintergrund-Updates aus?

Automatische Updates spielen den Patch ein und verkürzen das Zeitfenster deutlich. Blind verlassen sollten Sie sich nicht darauf: Prüfen Sie mit wp core version, ob die Zielversion Ihrer Branch tatsächlich installiert ist. Da die Lücke im Update-Vorgang selbst steckt, empfehlen wir zusätzlich, das Verzeichnis wp-content/upgrade auf Webserver-Ebene für Zugriffe aus dem Internet zu sperren.

Warum gibt es für diese Lücke noch keine CVE-ID?

Zum Zeitpunkt dieses Artikels ist keine CVE-ID bekannt. Der offizielle Release-Post von WordPress nennt keine CVE-Nummern, und eine Suche in der NVD-Datenbank nach WordPress 7.1.4 ergab am 30. Oktober 2026 keinen Treffer. Über den Schweregrad sagt das nichts: In der Berichterstattung über die Wordfence-Warnung wird die Lücke mit CVSS 8.1 als hoch eingestuft.

Ich habe erst gestern auf 7.1.4 aktualisiert, war mein eigenes Update gefährdet?

Ein Restrisiko bestand. Nach unserer Lektüre des Codes entpackt beim Update auf die Patch-Version noch der Code der alten Version das Paket. Den abschließenden Kopiervorgang übernimmt aber bereits die neue update-core.php, die keine wp-config.php mehr aus dem Arbeitsverzeichnis übernimmt. Das entschärft den bekannten Angriffsweg. Führen Sie die Prüfungen aus Schritt 2 und 3 trotzdem aus.

Fazit

Aktualisieren Sie auf die Patch-Version Ihrer Branch und prüfen Sie danach wp-content/upgrade und das Uploads-Verzeichnis auf fremde PHP-Dateien. Das ist schnell erledigt und die direkteste Antwort auf die Frage, ob Sie betroffen sind.

Der größere Befund steckt in der Kadenz: vier Sicherheitsreleases in 41 Tagen und Angriffsversuche kurz nach dem Patch. Das Zeitfenster zwischen Veröffentlichung und Ausnutzung schrumpft, und ein Update-Rhythmus nach Kalenderwochen verliert damit seine Grundlage.

Wenn Sie nicht bei jedem Core-Release neu entscheiden wollen, ob es dringend ist, übernehmen wir das für Sie. Was dazu gehört, lesen Sie unter WordPress Wartung. Haben Sie bei den Prüfungen oben einen Fund, melden Sie sich über WordPress gehackt, bevor Sie etwas löschen.

Quellen

Alle Quellen abgerufen am 30. Oktober 2026.

• WordPress 7.1.4 Security Release (wordpress.org): Releasedatum, Beschreibung der Updater-Lücke, Melder, Backports bis 4.7, Termin für WordPress 7.2
• Commit „Upgrade/Install: Improve the handling of the upgrade working directory“ (WordPress/wordpress-develop): die drei Code-Änderungen
• The Core Security Initiative, two months in (make.wordpress.org): Releasefolge, Meldungsvolumen, Automatisierung
• Wordfence: Warnung zu WordPress 7.1.4: Angriffszahlen und CVSS-Einstufung (Original bei Redaktionsschluss nicht abrufbar, Zahlen in der Wiedergabe durch heise online)
• National Vulnerability Database (NVD): Suche nach einer CVE-ID, am 30.10.2026 ohne Treffer