WordPress Core: RCE-Lücke im Update-Prozess, fast 63.000 Angriffsversuche in 24 Stunden
Eine Race Condition im WordPress-Update erlaubt Codeausführung ohne Login (4.7 bis 7.1.3, CVSS 8.1, keine CVE). Wordfence blockte fast 63.000 Versuche in 24 Stunden. Patch: 7.1.4 plus Backports.
Kurz nachdem WordPress am 28. Oktober 2026 ein Sicherheitsupdate veröffentlicht hat, suchen Angreifer bereits nach Seiten, die es noch nicht eingespielt haben. Die Lücke steckt im WordPress-Core selbst und nicht in einem Plugin. Betroffen sind die Versionen 4.7 bis 7.1.3. Das ist der größte Teil aller WordPress-Installationen, die heute noch laufen.
Was passiert ist
Die Lücke ist eine sogenannte Race Condition. Damit ist ein Fehler gemeint, bei dem das Ergebnis vom zeitlichen Ablauf abhängt: Wer im richtigen Moment zugreift, „gewinnt das Rennen“. Laut den Release Notes zu WordPress 7.1.4 handelt es sich um „eine Race Condition bei Core-Updates, die zu Remote Code Execution führen kann“. Gemeldet hat sie der Sicherheitsforscher Umut Bayram. Remote Code Execution (RCE) bedeutet, dass ein Angreifer aus der Ferne eigenen Programmcode auf dem Server ausführen kann.
Das Problem in groben Zügen: Bei einem Update mit dem vollständigen Core-Paket entpackt WordPress die neuen Dateien zuerst in ein Zwischenverzeichnis unter wp-content/upgrade. Dessen Pfad ist vorhersehbar, und auf vielen Servern ist er aus dem Internet erreichbar. In dieser Kopie liegt auch der WordPress-Installer. Wer ihn in dem kurzen Zeitfenster aufruft, in dem die Dateien dort liegen, kann laut The Hacker News bis zur Ausführung von PHP-Code kommen, und zwar ohne Anmeldung.
Ganz einfach ist das nicht. Mehrere Bedingungen müssen zusammenkommen: ein Update mit vollem Paket, öffentlicher Web- und PHP-Zugriff auf das Zwischenverzeichnis, ein bekannter oder erratener Pfad und genug Zeit, bevor WordPress die temporären Dateien wieder löscht. In Laborumgebungen existierte das Verzeichnis laut heise Security nur wenige Sekunden. SecurityWeek spricht deshalb von hoher Angriffskomplexität. Die Bewertung liegt bei CVSS 8.1 („hoch“). Eine CVE-Nummer gibt es bisher nicht.
Die Angriffsversuche
Die Sicherheitsfirma Wordfence (Defiant) hat nach eigenen Angaben innerhalb von 24 Stunden 62.969 Angriffe auf diese Lücke blockiert. Die erste Übereinstimmung mit der neuen Firewall-Regel kam neun Minuten nach deren Einführung. Allein in den ersten 21 Stunden zielten mehr als 18.500 Anfragen auf den Installer im Zwischenverzeichnis. Zwei der aktivsten Quellen haben kleine Gruppen von Seiten rund 14,5 Stunden lang immer wieder abgefragt, offenbar in der Hoffnung, ein laufendes Update zu erwischen.
Wichtig ist die Unterscheidung: Das sind Versuche. Keine der Quellen berichtet bisher von einem bestätigten erfolgreichen Einbruch.
Was sich seit meinem Post geändert hat
Inzwischen ist klarer, wie genau gepatcht wird. Die aktuelle Version ist 7.1.4. Für ältere Zweige gibt es Backports bis hinunter zu 4.7.39, zum Beispiel 7.0.8, 6.9.11 und 6.8.12. Laut SecurityWeek legt WordPress das Zwischenverzeichnis jetzt unter einem zufälligen Namen an, ergänzt einen Index-Schutz und übernimmt dort abgelegte Konfigurationsdaten nicht mehr. Version 7.1.4 schließt außerdem 22 weitere Sicherheitsprobleme, darunter mehrere XSS-Lücken. Versionen vor 4.7 bekommen gar keine Sicherheitsupdates mehr.
Warum das wichtig ist
Das Perfide an dieser Lücke ist, dass sie genau in dem Moment greift, in dem man das Richtige tut, nämlich beim Update. Wer WordPress noch auf einer betroffenen Version betreibt, ist bei jedem künftigen Core-Update mit vollem Paket diesem Risiko ausgesetzt, solange das Zwischenverzeichnis erreichbar bleibt. Hinzu kommt, dass schon die Lücke von Ende September innerhalb weniger Stunden angegriffen wurde. Die Zeit zwischen Patch und Angriff ist bei WordPress praktisch null.
Was du jetzt tun solltest
- Updaten: auf 7.1.4 oder auf den Backport deines Zweigs. Im Dashboard unter „Aktualisierungen“ nachsehen, welche Version wirklich läuft.
- Automatische Updates prüfen: Sie sind für Sicherheitsreleases eigentlich aktiv, werden aber manchmal durch Hoster, Konfiguration oder Dateirechte blockiert. Nicht davon ausgehen, dass sie gelaufen sind, sondern es kontrollieren.
- Zwischenverzeichnis absichern: Patchstack empfiehlt, den Webzugriff auf
wp-content/upgrade/zu sperren und sicherzustellen, dass das Verzeichnis nicht auflistbar ist. - Logs prüfen: nach auffälligen Aufrufen von PHP-Dateien unter
wp-content/upgradesuchen, besonders wenn das Update erst nach dem 28. Oktober eingespielt wurde. - Auf Spuren achten: unbekannte Admin-Konten, Plugins, die niemand installiert hat, und PHP-Dateien, die nicht dorthin gehören.
Mein Rat: Wer mehrere WordPress-Seiten betreut, sollte heute jede einzelne prüfen und sich nicht auf „läuft automatisch“ verlassen. Die Angreifer prüfen ebenfalls jede einzelne Seite.