WordPress 7.1.4 behebt 22 Schwachstellen, darunter Update-RCE
WordPress 7.1.4 wurde am 28. Oktober 2026 mit Korrekturen für 22 Schwachstellen veröffentlicht, die in 17 Sicherheitshinweisen behandelt werden. Die vorangegangene Version 7.1.3 hatte drei Wochen zuvor sieben Schwachstellen behoben. Die meisten der neu behobenen Probleme erfordern ein bestehendes Konto, normalerweise mit Contributor-Zugriff oder höher, doch eine race condition konnte ohne Authentifizierung zu remote code execution führen. Eine race condition ist eine Schwachstelle, die davon abhängt, dass Aktionen in einer engen und unbeabsichtigten Reihenfolge stattfinden, während remote code execution oder RCE bedeutet, dass ein Server vom Angreifer kontrollierten Code ausführt.
WordPress veröffentlichte am selben Tag backports, also für ältere Software-Branches angepasste Korrekturen, für jeden unterstützten Branch bis einschließlich 4.7.39. Zu den verfügbaren Versionen gehören 7.0.8, 6.9.11, 6.8.12, 6.7.11, 6.6.11, 6.5.14 und 6.4.14 sowie weitere backports bis hinunter zu 4.7.39. Websites mit WordPress 4.6 oder älter erhalten kein Update. WordPress 7.1.4 ist über Dashboard, Updates und WordPress.org verfügbar; Websites mit aktivierten background updates sollten es automatisch installieren.
Die Codeanalyse von Patchstack ergab, dass die folgenreichste Schwachstelle im zentralen Upgrade-Prozess lag. Während einer Installation oder eines Updates entpackt WordPress ein Paket in wp-content/upgrade/, ein Verzeichnis, das vom Webserver möglicherweise öffentlich bereitgestellt wird. Vor 7.1.4 übernahm der entpackte Ordner den Paketnamen, wodurch sein Speicherort bei Paketen vorhersehbar war, die über den Administrationsbereich hochgeladen wurden. Bei der anfänglichen Bereinigung wurde außerdem alles im Upgrade-Verzeichnis entfernt, einschließlich der Datei index.php, die verhindert, dass Besucher eine Verzeichnisauflistung sehen.
Während der wenigen Sekunden, die zum Abschluss eines Updates erforderlich sind, konnten die entpackten Dateien daher unter einer erratbaren und potenziell durchsuchbaren Adresse eine vollständige WordPress-Installation bilden. Diese Kopie enthielt wp-admin/setup-config.php, das unabhängig und ohne die Konfiguration der aktiven Website gestartet werden konnte. Ein Angreifer, der die Datei während des Update-Zeitfensters erreichte, konnte das Installationsprogramm mit einer vom Angreifer kontrollierten Datenbank ausführen, während es sich weiterhin innerhalb des document root der betroffenen Website befand, also in dem über das Web erreichbaren Ordner, der die Website enthält. Weder ein Konto noch eine Benutzerinteraktion waren erforderlich, allerdings erschwerten die Anforderungen an Timing und Erreichbarkeit die Ausnutzung.
WordPress 7.1.4 ergänzt den Namen des temporären Ordners um 16 zufällige Zeichen, stellt index.php wieder her und löscht diese Datei nicht mehr. Patchstack identifizierte außerdem eine separate Änderung an update-core.php, die verhindert, dass wp-config.php aus dem Arbeitsverzeichnis herauskopiert wird. Patchstack bewertete die Schwachstelle mit AC:H, was eine hohe Angriffskomplexität bedeutet, und erklärte, dass ihre Ausnutzung nicht praktikabel sei. Dennoch stammte der anfällige Mechanismus bereits aus WordPress 2.8 und trat bei jedem Update erneut auf, einschließlich unbeaufsichtigter Updates.
Eine in PHP, der Programmiersprache von WordPress, implementierte firewall kann diese konkrete Anfrage nicht abfangen. Patchstack erklärt, dass die entpackte Kopie ihre eigenen WordPress-Dateien lädt, während das offizielle Archiv kein mu-plugins-Verzeichnis für automatisch geladene Plugins enthält; deshalb startet die PHP-firewall der aktiven Website nie. Als Gegenmaßnahme auf Serverebene wird empfohlen, den Webzugriff auf wp-content/upgrade/ zu verweigern und zu prüfen, dass Besucher dessen Inhalt nicht durchsuchen können. Zwischen Updates sollte dieses Verzeichnis ausschließlich index.php enthalten.
Sieben Sicherheitshinweise betreffen die Interactivity API, eine WordPress-Funktionalität, mit der Seitenelemente auf Besucher reagieren können. KSES, das Filtersystem, das steuert, welches HTML Benutzer ohne die Berechtigung unfiltered_html speichern dürfen, erlaubte jedes data-*-Attribut und jeden Wert. Interactivity-Direktiven verwenden diese Attribute, sodass Contributors Direktiven in Beiträgen platzieren konnten, die die Filterung überstanden und anschließend vom browser-side runtime ausgeführt wurden, wenn jemand die Seite aufrief. Zu den daraus resultierenden Schwachstellen gehörte stored cross-site scripting oder stored XSS, bei dem schädlicher Browsercode in Website-Inhalten gespeichert und später an Besucher ausgeliefert wird.
Die Probleme der Interactivity API betrafen javascript:-Links, Bindings für Event-Handler, die von der PHP-Seite bereits abgelehnt wurden, reservierte Keys wie __proto__, die in einen Context-Merge gelangten, unsichere Bindings an object-Elementen sowie einen CSS-Parser, der seine Eingabe wiederholt verarbeitete. Der CSS-Fall konnte den Browser-Tab eines Besuchers einfrieren, erschöpfte jedoch nicht die Ressourcen des Servers. Weitere Sicherheitshinweise betrafen object-Elemente, die Administrationsseiten luden, prototype pollution sowie stored XSS und denial of service in Bindings. Version 7.1.4 sorgt dafür, dass KSES Bindings entfernt, die einen zuvor validierten Wert verändern könnten, beschränkt Bindings von object-Elementen im PHP directive processor und lässt den client runtime unsichere Ziele ablehnen. Da der client runtime mit Version 6.4 eingeführt wurde und die PHP-Klasse mit 6.5 folgte, führt WordPress für beide Versionen dieselbe Anzahl betroffener Probleme auf.
Eine damit zusammenhängende state-shadowing-Schwachstelle entstand, weil die Interactivity API getElementById() verwendete, um ein script mit ihrem State zu finden. Diese Funktion gibt unabhängig vom Elementtyp die erste übereinstimmende ID zurück, und WordPress gab das legitime script in wp_footer nach dem Beitragsinhalt aus. Ein Contributor konnte deshalb in gespeicherten Inhalten ein früheres Element mit derselben ID platzieren und dem runtime einen State bereitstellen. WordPress 7.1.4 prüft nun, ob das ausgewählte Element tatsächlich ein script ist. Ein weiteres Problem im Interactivity Router ermöglichte stored XSS über hochgeladene Textdateien und erforderte ein Konto auf Author-Ebene mit der Berechtigung zum Hochladen von Dateien.
Außerdem wurden zwei Probleme im Customizer behoben. Selective refresh vertraute data-customize-partial-*-Attributen aus dem in der Vorschau angezeigten Inhalt und übergab einen vom Angreifer kontrollierten Selector an die jQuery-Funktion $(). jQuery interpretiert einen String, der mit einem Kleiner-als-Zeichen beginnt, als zu erstellendes HTML und nicht als zu suchenden Selector. WordPress verwendet nun .find(), das ausschließlich Selectors verarbeitet. Unabhängig davon konnte eine anonyme Vorschauanfrage ohne changeset UUID das neueste unveröffentlichte changeset übernehmen, unabhängig von dessen Autor, und dadurch seine UUID sowie die gerenderte Vorschau offenlegen. Änderungen an Einstellungen blieben durch separate Berechtigungen geschützt. Die Korrektur erfordert die customize-Berechtigung.
Mehrere Schwachstellen im Block-Editor betrafen Inhalte, die nach der Filterung erneut interpretiert wurden. Der Categories-Block filterte das Label eines Dropdown-Menüs und verwendete es anschließend als sprintf()-Format-String, sodass Formatierungsdirektiven danach expandiert werden konnten. Die Image- und Playlist-Blöcke verwendeten vom Angreifer beeinflussbaren übereinstimmenden Text als Ersatzwert für preg_replace(), wobei PHP Backreferences wie $0 expandieren und Markup in ein Attribut einfügen konnte. Diese Blöcke verwenden nun die HTML API. Die Blöcke Comments Pagination und Post Navigation Link maskierten ihre Label-Attribute nicht. Ein separates Problem im Categories-Block, die Härtungskorrektur für Image und Playlist sowie diese nicht maskierten Labels erforderten jeweils Contributor-, Author- beziehungsweise Contributor-Zugriff.
Die Server- und Editor-Parser von WordPress behandelten außerdem Whitespace in block delimiters unterschiedlich. Der PHP-Parser erkannte sechs Whitespace-Zeichen, während JavaScript zusätzlich non-breaking spaces, mehrere Unicode-Spaces und eine byte order mark akzeptierte.