WordPress 7.1.3 behebt Kommentar-XSS und das Durchsickern privater Beiträge
WordPress 7.1.3 wurde am 6. Oktober 2026 als Wartungs- und Sicherheitsrelease mit sieben Sicherheitskorrekturen und vier Fehlerbehebungen veröffentlicht. Es folgt auf WordPress 7.1.2, das zwei Wochen zuvor eine einzelne Schwachstelle mit der Kennung CVE-2026-87902 behoben hatte, die es einem nicht angemeldeten Besucher ermöglichte, eine lokale Dateieinbindung auszulösen und unter der richtigen PHP-Konfiguration zu einer Remotecodeausführung führen konnte. Dieses Release ist anders gelagert: Zwei der Korrekturen beginnen mit einem nicht angemeldeten Besucher, das Durchsickern des Kommentar-Feeds und das Kommentar-XSS, das zusätzlich einen Klick eines Moderators erfordert. Drei erfordern ein Contributor- oder Author-Konto, eine erfordert einen Administrator, der einen Export durchführt, und eine ist eine pluginabhängige Härtung. Patchstack, das Sicherheitsunternehmen, das die Analyse veröffentlicht hat, bezeichnet das Update als dringend, aber nicht als Notfall, bei dem man alles stehen und liegen lassen muss.
Die auffälligste Korrektur ist eine gespeicherte Cross-Site-Scripting-Schwachstelle (XSS) auf der Kommentar-Adminseite von WordPress. XSS ermöglicht es einem Angreifer, bösartigen Code in eine Seite einzuschleusen, die andere später ansehen. Der Klick-Handler des Hilfe-Tabs in `wp-admin/js/common.js` übergab das href eines Links an jQuerys `$()`, das aus jeder Zeichenfolge, die wie HTML aussieht, HTML erstellt. Ein Link in einem ausstehenden Kommentar kann ein solches href enthalten. Der Handler lauscht nur innerhalb von Elementen mit der Klasse `contextual-help-tabs`, daher benötigt der Link auch einen Wrapper mit dieser Klasse. Vor WordPress 7.1.0 konnten Besucherkommentare keine Klasse tragen; 7.1.0 fügte die Unterstützung für Span-Klassen für Notiz-Erwähnungen hinzu und kürzt sie beim Speichern. Laut Patchstacks Überprüfung betrifft der Angriff über ausstehende Kommentare die Versionen 7.1.0 bis 7.1.2, und ältere Backports härten denselben Code. Die Korrektur in 7.1.3 ersetzt das Verhalten durch `.find()`, das nur Selektoren liest. Die Schwachstelle wurde von Thomas Chauchefoin von Trail of Bits gemeldet.
Zwei separate Probleme betreffen die Offenlegung von Informationen. Bei Kommentar-Feeds für einzelne Beiträge lud `WP_Query` die Kommentare eines Beitrags, bevor geprüft wurde, ob ein Besucher den Beitrag sehen darf. Die Sichtbarkeitsprüfung löschte dann den Beitrag, aber nicht die Kommentare, und da Feeds niemals einen 404-Status zurückgeben, gab der Feed die Kommentare privater oder unveröffentlichter Beiträge an jeden aus. Die Korrektur verschiebt die Kommentarabfrage hinter die Sichtbarkeitsprüfung; dies wurde von Ananda Dhakal von Patchstack gemeldet. Im Fall von Imgur führt WordPress normalerweise HTML von nicht vertrauenswürdigen oEmbed-Anbietern durch einen Filter, der es auf einen sandboxed iframe reduziert. Imgur stand jedoch auf der Vertrauensliste, die diesen Filter überspringt, sodass alles, was von Imgurs API zurückkam, direkt ausgegeben wurde. Diese Antwort enthält Text vom Bild oder Album des Uploaders, sodass alles, was der Angreifer kontrolliert, ungefiltert auf der Seite landete. Die Korrektur entfernt Imgur als vertrauenswürdigen Anbieter, sodass Imgur-URLs nicht mehr ungefiltert eingebettet werden. Bemerkenswert ist, dass das Update vorhandene zwischengespeicherte oEmbed-Inhalte, die in `_oembed_*`-Post-Meta und `oembed_cache`-Posts gespeichert sind, nicht entfernt, sodass eine vorhandene bösartige Einbettung weiterhin gerendert wird, bis der Cache der Website geleert wird. Dieses Problem wurde von Zhengyu Liu, Jingcheng Yang und Gavin Zhong gemeldet.
Mehrere andere Korrekturen erfordern ein Contributor- oder höheres Konto. Ein Denial of Service in `WP_Http::make_absolute_url()` entstand durch eine Schleife, die Segment-/../-Paare zusammenführt, aber bei einem relativen Pfad wie `a//../b` nie endet, weil ihr regulärer Ausdruck nichts findet und sich der Pfad nie ändert. Ein Contributor kann dies über die Linkvorschau des Block-Editors auslösen, indem er auf eine von ihm kontrollierte Seite verweist; 7.1.3 bricht die Schleife ab, wenn ein Durchlauf nichts ersetzt. Eine Second-Order-SQL-Injection im WXR-Export sammelte Featured-Image-IDs direkt aus den `_thumbnail_id`-Metadaten und verknüpfte sie ohne Sicherstellung, dass die ID eine Ganzzahl ist, zu einer Abfragezeichenfolge. Die Korrektur fügt an drei Stellen `absint()` hinzu. Der anfällige Code existiert erst seit WordPress 6.5.0 und wird nur erreicht, wenn ein einzelner Inhaltstyp exportiert wird; der Standardexport "Alle Inhalte" berührt ihn nicht. Autoren konnten Beiträge auch als sticky markieren, weil die REST-API eine Sticky-Anfrage nur ablehnte, wenn dem Benutzer sowohl `edit_others_posts` als auch `publish_posts` fehlten. Autoren haben die `publish_posts`-Fähigkeit, also kamen sie durch; die Korrektur ändert das `&&` (und) in `||` (oder). Sowohl der Denial of Service als auch die SQL-Injection wurden von Anthropic gemeldet.
Die letzte Korrektur betrifft eine Hook-Namenskollision. WordPress erstellt einige Aktionsnamen aus den Daten eines Beitrags. Wenn sich der Status eines Beitrags ändert, feuert `wp_transition_post_status()` `${new_status}_{$post_type}`, sodass das Veröffentlichen eines Beitrags `publish_post` auslöst. Nicht verwandte Aktionen folgen demselben Namensmuster: `delete_post` feuert, wenn ein Beitrag gelöscht wird, und `comment_post` feuert, wenn ein Kommentar hinzugefügt wird. Vor 7.1.2 prüfte WordPress nie, ob Status und Beitragstyp registriert waren, bevor der Name erstellt wurde. Ein Beitrag, der mit dem Status `delete` und dem Typ `post` gespeichert wurde, würde `delete_post` auslösen, dieselbe Aktion wie eine echte Löschung, und jeder daran gehängte Callback würde ausgeführt, als ob gerade ein Beitrag gelöscht worden wäre. Die Korrektur feuert diese Hooks nur, wenn Status und Beitragstyp registriert sind. Dies wurde von Alex Concha vom WordPress-Sicherheitsteam gemeldet.
WordPress 7.1.3 ist über das Dashboard unter Updates oder von WordPress.org verfügbar, und Websites mit automatischen Hintergrund-Updates erhalten es von selbst. Die Korrekturen wurden auf ältere Zweige bis mindestens zu den 6.6-Releases zurückportiert, aber zum Zeitpunkt der Veröffentlichung von Patchstack waren die Zweige 4.7 bis 6.5 noch nicht gepatcht. Patchstack hat die veröffentlichten Schwachstellen noch am selben Tag in seine Datenbank aufgenommen. Beim Aktualisieren sollten Website-Betreiber prüfen, wer Contributor- oder höhere Rollen innehat, da viele dieser Korrekturen damit zusammenhängen, worauf diese Rollen zugreifen können. Für Website-Betreiber auf verwaltetem WordPress-Hosting wie AEU Hosting erleichtern automatische Core-Updates, Staging-Umgebungen und Sicherheitshärtung das Einspielen eines Releases wie 7.1.3, das Leeren von Caches nach dem Patchen und die Überprüfung, welche Konten Contributor- oder höhere Rollen innehaben, bevor ein ausstehender Kommentar überhaupt einen Moderator erreicht.