WordPress 7.1.4 behebt 22 Schwachstellen, darunter RCE bei Updates
WordPress 7.1.4 wurde am 28. Oktober 2026 veröffentlicht und behebt 22 Schwachstellen, die in 17 Sicherheitshinweisen behandelt werden. Das ist ein erheblicher Anstieg gegenüber WordPress 7.1.3, das drei Wochen zuvor sieben Schwachstellen behoben hatte. Die meisten neuen Schwachstellen setzen ein bestehendes Konto voraus, üblicherweise eines mit der Contributor-Rolle, doch zwei können Informationen oder Funktionen ohne Authentifizierung offenlegen. Am schwerwiegendsten ist eine race condition, also ein Sicherheitsversagen, das durch präzise zeitlich abgestimmte Vorgänge verursacht wird und zu remote code execution (RCE), also zur Ausführung von Code auf dem betroffenen Server, führen kann, während WordPress aktualisiert wird.
Mehrere Sicherheitshinweise betreffen stored cross-site scripting (stored XSS), bei dem schädlicher Browser-Code in Website-Inhalten gespeichert und ausgeführt wird, wenn eine andere Person die betroffene Seite öffnet. Benutzer mit Contributor-Berechtigung konnten Schwachstellen im Zusammenhang mit Whitespace bei block delimiters, Customizer selective refresh, der Formatierung des Categories block, Labels von Comments Pagination und Post Navigation Link sowie mehreren Teilen der Interactivity API ausnutzen. Bei anderen Problemen galten abweichende Voraussetzungen: Das Problem im Interactivity Router erforderte ein Author-Konto mit der Berechtigung zum Hochladen von Dateien, während für den Bildschirm zum Löschen personenbezogener Daten ein Editor-Konto sowie ein Administrator erforderlich waren, der zunächst Werkzeuge und dann Personenbezogene Daten löschen öffnete. Eine hardening-Korrektur für Multisite betrifft nicht maskierte Benutzernamen mit Markup, wenn diese Namen von etwas außerhalb von WordPress core gespeichert und von einem Netzwerkadministrator angesehen wurden.
Die RCE im Update-Prozess erfordert kein Konto, doch Patchstack bezeichnet die Ausnutzung als unpraktikabel, weil der Angreifer innerhalb eines Zeitfensters von nur wenigen Sekunden handeln muss. Während einer Installation oder Aktualisierung extrahiert WordPress ein Softwarepaket nach wp-content/upgrade/, einem Verzeichnis, das möglicherweise öffentlich vom Webserver bereitgestellt wird. Vor Version 7.1.4 übernahm der temporäre Ordner einen vorhersehbaren Namen aus dem Paket. Bei der anfänglichen Bereinigung wurde außerdem alles in diesem Verzeichnis entfernt, einschließlich der Datei index.php, die normalerweise directory listings verhindert.
Für diese wenigen Sekunden konnte daher eine extrahierte WordPress-Installation unter einer vorhersehbaren, potenziell durchsuchbaren Adresse vorhanden sein. Sie enthielt wp-admin/setup-config.php, das ohne die ursprüngliche Website-Konfiguration gestartet werden konnte. Wenn ein Angreifer diese Datei im richtigen Moment erreichte, konnte er den Installer mit einer von ihm kontrollierten Datenbank ausführen, während sich die Dateien weiterhin im document root der Website des Opfers befanden. Patchstack bewertete das Problem mit AC:H, also hoher attack complexity, wies jedoch darauf hin, dass weder ein Konto noch eine Benutzerinteraktion erforderlich ist, dass es seit WordPress 2.8 besteht und bei jedem Update erneut auftritt, einschließlich unbeaufsichtigter Updates.
WordPress 7.1.4 ergänzt den Namen des temporären Verzeichnisses um 16 zufällige Zeichen, stellt index.php wieder her und löscht diese Datei nicht mehr. Patchstack fand außerdem eine separate Änderung in update-core.php, durch die wp-config.php in die Liste der Dateien aufgenommen wird, die niemals aus dem working directory kopiert werden dürfen. Eine über PHP ausgeführte firewall kann die anfällige Anfrage nicht abfangen, weil das extrahierte Paket seine eigenen WordPress-Dateien lädt und das offizielle Archiv kein mu-plugins-Verzeichnis enthält, aus dem die firewall der Website ausgeführt werden könnte. Patchstack empfiehlt daher, den Webzugriff auf wp-content/upgrade/ auf Webserver-Ebene zu sperren und zu bestätigen, dass Besucher den Inhalt des Verzeichnisses nicht auflisten können.
Sieben der 17 Sicherheitshinweise betreffen die Interactivity API, das System, mit dem WordPress blocks browserseitiges Verhalten hinzufügt. Ihre gemeinsame Ursache war KSES, das WordPress-Filtersystem, das steuert, welches HTML Benutzer ohne uneingeschränkte Veröffentlichungsrechte speichern dürfen. KSES erlaubte jedes data-*-Attribut und jeden Wert, während Interactivity directives Attribute wie data-wp-interactive, data-wp-context und data-wp-bind--href verwenden. Ein Contributor konnte diese directives in einem Beitrag speichern, woraufhin der Browser eines Besuchers sie verarbeitete.
Zu den daraus resultierenden Problemen gehörten bindings, die javascript:-Adressen erzeugten, event-handler bindings, die bereits von der PHP-Seite abgelehnt wurden, sowie reserved keys wie __proto__, die in einen context merge gelangten und prototype pollution verursachten, wodurch von anderen Browser-Objekten geerbte Eigenschaften verändert werden. Andere Schwachstellen ermöglichten es bindings auf object elements, bestehende Daten- und Typprüfungen zu umgehen. Ein CSS parser wiederholte außerdem die Verarbeitung bei jeder Iteration und verursachte dadurch einen denial of service, der den Browser-Tab des Besuchers statt des Servers blockierte. Version 7.1.4 sorgt dafür, dass KSES bindings entfernt, die einen validierten Wert verändern würden, beschränkt bindings auf object elements im PHP directive processor und lässt den browser runtime unsichere Ziele ablehnen. Der Interactivity browser runtime wurde mit WordPress 6.4 eingeführt, eine Version vor der PHP-Klasse in 6.5; deshalb führt WordPress beide Versionen als von derselben Anzahl von Problemen betroffen auf.
Eine weitere Schwachstelle erlaubte es Beitragsinhalten, Script Module data zu shadowen. Die Interactivity API verwendete getElementById(), das unabhängig von seinem Typ das erste Element mit der angeforderten ID zurückgibt. Weil WordPress die echten script data im wp_footer nach dem Beitrag ausgab, konnten Inhalte mit einer übereinstimmenden ID zuerst erscheinen und den runtime state bereitstellen. Version 7.1.4 überprüft nun, ob das ausgewählte Element tatsächlich ein script element ist.
Auch zwei Probleme im Customizer wurden behoben. Selective refresh vertraute data-customize-partial-*-Attributen in Vorschauinhalten und übergab einen bereitgestellten selector an die jQuery-Funktion $(). Ein Wert, der mit einem Kleiner-als-Zeichen begann, konnte als zu erstellendes HTML statt als zu suchender selector behandelt werden. Die Korrektur verwendet .find(), das ausschließlich selectors interpretiert. Darüber hinaus konnte eine Vorschauanfrage ohne changeset UUID den neuesten unveröffentlichten changeset übernehmen, ohne zu prüfen, wer ihn erstellt hatte oder ob der Besucher dazu berechtigt war. Dadurch wurden dessen Kennung offengelegt und die Vorschau anonym gerendert, obwohl zum Ändern der Werte weiterhin die entsprechenden Berechtigungen erforderlich waren. WordPress 7.1.4 verlangt nun die customize capability.
Drei Korrekturen für blocks betreffen Inhalte, die nach dem Filtern neu interpretiert wurden. Der Categories block fügte ein gefiltertes Dropdown-Label in einen sprintf()-format string ein, wodurch formatting directives anschließend erweitert werden konnten. Die Image und Playlist blocks verwendeten vom Angreifer beeinflussbaren Text als preg_replace()-replacement, wobei PHP references wie $0 erweitern und ein Tag in das Attribut eines anderen Tags einfügen konnte. Beide verwenden nun die HTML API. Comments Pagination und Post Navigation Link blocks maskieren ihre Label-Attribute jetzt vor der Ausgabe.
Die Schwachstelle beim block delimiter entstand, weil der PHP parser des Servers und der JavaScript parser des Editors Whitespace unterschiedlich interpretierten. JavaScript erkannte non-breaking spaces, mehrere Unicode spaces und eine byte order mark, die PHP nicht erkannte. Ein speziell geformter delimiter konnte daher auf dem Server ein wirkungsloser Kommentar, im Editor jedoch ein echter block mit vom Angreifer kontrollierten Attributen sein. Version 7.1.4 beschränkt jeden parser auf dieselben fünf Whitespace-Zeichen.