WordPress 7.1.4 behebt Core-RCE während aktiver Angriffssondierungen
WordPress 7.1.4 wurde am 28. Oktober 2026 mit Korrekturen für 22 Sicherheitslücken veröffentlicht, darunter eine nicht authentifizierte remote code execution (RCE), durch die ein Angreifer Code auf einem Server ausführen könnte, ohne sich zuvor anzumelden. Wordfence berichtet, dass Angreifer kurz nach dem Security-Release damit begannen, nach der Schwachstelle zu sondieren. Websitebetreiber sollten bestätigen, dass WordPress Version 7.1.4 oder das entsprechende Sicherheitsupdate für ihren älteren Versionszweig installiert hat, statt davon auszugehen, dass das automatische Update erfolgreich war.
Das schwerwiegendste Problem betrifft WordPress Core in den Versionen 4.7 bis 7.1.3 und hat einen CVSS-Score von 8.1 mit der Einstufung High. CVSS, das Common Vulnerability Scoring System, ist eine Standardskala zur Beschreibung des Schweregrads einer Sicherheitslücke. Bei der Schwachstelle handelt es sich um eine race condition, was bedeutet, dass ein Angreifer innerhalb eines kurzen Zeitraums handeln muss, in dem sich zwei Prozesse überschneiden. Ein Websitekonto ist nicht erforderlich, doch der Angreifer muss WordPress in dem Moment erwischen, in dem es ein vollständiges Core-Update entpackt.
Während eines solchen Updates extrahieren anfällige Versionen neue WordPress-Dateien in ein vorhersehbares Verzeichnis unterhalb von wp-content/upgrade. Dieses staging directory, ein temporärer Speicherort, der verwendet wird, bevor neue Dateien live geschaltet werden, enthält den WordPress-Installer. Auf vielen Servern ist es über das öffentliche Web erreichbar. Ein Angreifer, der den Pfad findet oder vorhersagt, kann die zwischengespeicherte Datei setup-config.php wiederholt anfordern und mit der temporären Installation interagieren, bevor WordPress sie entfernt. PHP ist die serverseitige Programmiersprache, mit der WordPress ausgeführt wird, und der Zugriff auf diese zwischengespeicherte PHP-Datei kann letztlich die Ausführung von Code auf dem Host ermöglichen.
Mehrere Bedingungen müssen zusammentreffen. WordPress muss ein vollständiges Paket verarbeiten, das Installer-Dateien enthält, das temporäre Verzeichnis muss öffentlichen Web- und PHP-Zugriff erlauben, der Pfad muss vorhersehbar sein oder entdeckt werden, und der Angreifer muss den Vorgang vor der Bereinigung abschließen. Laut Wordfence ergaben Labortests, dass das anfällige Verzeichnis im Allgemeinen nur wenige Sekunden lang verfügbar blieb. Eine einzelne Anfrage ist daher wahrscheinlich nicht erfolgreich, automatisiertes Polling kann eine Website jedoch wiederholt prüfen, um zu versuchen, dieses Zeitfenster zu treffen.
WordPress 7.1.4 ändert diesen Prozess, indem es das staging directory zufällig benennt, darin einen index guard platziert und die unsichere Übernahme zwischengespeicherter Konfigurationsdaten blockiert. Die Fixes wurden außerdem bis zurück zu WordPress 4.7 als Backports bereitgestellt. Die gepatchten Versionen sind 4.7.39, 4.8.34, 4.9.35, 5.0.31, 5.1.28, 5.2.30, 5.3.27, 5.4.25, 5.5.24, 5.6.23, 5.7.21, 5.8.19, 5.9.20, 6.0.18, 6.1.16, 6.2.15, 6.3.14, 6.4.14, 6.5.14, 6.6.11, 6.7.11, 6.8.12, 6.9.11, 7.0.8 und 7.1.4. WordPress 4.6 und ältere Versionen erhalten keine Sicherheitsupdates mehr und müssen auf ein unterstütztes Release umgestellt werden.
Aktive Sondierungen begannen schnell. Wordfence stellte am 28. Oktober um 20:30 Uhr UTC eine neue firewall-Regel bereit, etwa drei Stunden nach dem WordPress-Sicherheitsrelease. Eine firewall filtert potenziell schädliche Anfragen, bevor sie eine Website erreichen. Kunden von Wordfence Premium, Care und Response erhielten die Regel sofort, während Nutzer von Wordfence Free sie nach der üblichen Verzögerung von 30 Tagen planmäßig am 27. November 2026 erhalten sollen.
Wordfence verzeichnete neun Minuten nach der Bereitstellung den ersten Treffer für diese Regel. In den ersten 21 Stunden zählte die Telemetrie des Unternehmens, also von geschützten Websites erfasste Sicherheitsereignisdaten, mehr als 18.500 Anfragen an zwischengespeicherte setup-config.php-Pfade. Zwei der größten Quellen fragten kleine Gruppen von Websites etwa 14,5 Stunden lang wiederholt ab. Andere Quellen probierten zahlreiche Kombinationen aus staging directory und Versionsnamen aus. Wordfence weist darauf hin, dass nicht jede Anfrage den genauen anfälligen Pfad verwendete, erklärt jedoch, dass das anhaltende Polling und die exakten Verzeichnisstrukturen zeigen, dass Angreifer die Timing-Schwachstelle verstanden und begonnen hatten, sie gezielt anzugreifen. Aus dem Bericht geht nicht hervor, dass jede Sondierung erfolgreich war.
Für die Bereitstellung der firewall-Regel gilt eine wichtige Voraussetzung. Die schädliche Anfrage geht direkt an eine zwischengespeicherte PHP-Datei, ohne zuvor WordPress zu laden. Websites, die Wordfence verwenden, benötigen daher dessen Extended Protection-Modus, der die firewall startet, bevor direkte PHP-Anfragen die angeforderte Datei erreichen. Eine firewall-Regel kann die Gefährdung verringern, beseitigt jedoch nicht das anfällige Core-Verhalten und ist kein Ersatz für die Installation einer gepatchten Version.
Die weiteren Fixes in WordPress 7.1.4 decken mehrere Klassen von Sicherheitsproblemen ab. Mehrere stored cross-site scripting (XSS)-Schwachstellen, bei denen schädlicher Browsercode auf einer Website gespeichert und später einem anderen Nutzer angezeigt wird, betrafen Block Delimiters, den Categories Block, Labels für Comments Pagination und Post Navigation, Customizer Selective Refresh, Anfragen zur Löschung personenbezogener Daten, speziell konstruierte Benutzernamen sowie die Verarbeitung von Image und Playlist Blocks. Einige erfordern ein Contributor-, Author- oder Editor-Konto, und mehrere setzen zusätzlich voraus, dass ein Nutzer mit höheren Berechtigungen vom Angreifer kontrollierte Inhalte aufruft. Diese Anforderungen begrenzen die Gefährdung im Vergleich zur nicht authentifizierten RCE, doch stored XSS kann weiterhin zu account takeover oder nicht autorisierten Änderungen an einer Website führen.
Das Release korrigiert außerdem Probleme in der Interactivity API im Zusammenhang mit unsicheren URL-, Event Handler-, Internal Property- und Object Bindings. Eine API ist eine festgelegte Methode, über die Softwarekomponenten Anweisungen oder Daten austauschen. Weitere Fixes betreffen prototype pollution, bei der Eingaben Eigenschaften verändern, die von anderen Softwareobjekten geerbt werden, Script Module data shadowing, die Verarbeitung hochgeladener Textdateien im Interactivity Router und eine persistente denial of service-Bedingung, die einen Dienst durch die Erschöpfung oder Blockierung seiner Ressourcen unerreichbar halten kann.
Weitere Patches beheben die nicht authentifizierte Offenlegung unveröffentlichter Customizer Changesets und eine Autorisierungsschwäche in der Notes REST API. Dieses Berechtigungsproblem betraf benutzerdefinierte Rollen, die Kommentare moderieren durften, aber nicht den Beitrag bearbeiten konnten, der eine Notiz enthielt. Mitgelieferte root certificates, die Software bei der Entscheidung helfen, welchen verschlüsselten Verbindungen sie vertrauen kann, wurden nach der eMudhra revocation ebenfalls aktualisiert.
Betreiber, deren Websites ungepatcht blieben, sollten Anfragen an PHP-Dateien unterhalb von wp-content/upgrade überprüfen und nach unbekannten Administratorkonten, unerwarteten Plugins oder PHP-Dateien suchen, die sie nicht selbst hinzugefügt haben. Wordfence empfiehlt außerdem, nach dem Update einen Scan auszuführen, um veränderte Core-Dateien, schädliche Dateien oder andere Hinweise zu erkennen, die untersucht werden müssen. Für Websitebetreiber, die prüfen, wo die Verantwortung für die WordPress-Sicherheit liegt, bietet AEU Hosting durchgängig abgesichertes managed WordPress hosting.
Die unmittelbare Priorität besteht darin, Dashboard > Aktualisierungen zu öffnen und das installierte Release zu überprüfen. Automatische Hintergrundupdates sollten den Fix auf den meisten Websites installieren, doch ein fehlgeschlagenes oder verzögertes Update würde das anfällige Upgrade-Verhalten bestehen lassen. Die Bestätigung der Version, die Prüfung auf verdächtige Aktivitäten und die Untersuchung unerwarteter Änderungen sind notwendig, da aktive Angreifer bereits versuchen, das kurze Update-Zeitfenster zu treffen.