← AEU Hosting Blog

WordPress 7.1.1 behebt gespeicherte XSS ohne Authentifizierung

2026-10-12

WordPress 7.1.1 behebt gespeicherte XSS ohne Authentifizierung

WordPress 7.1.1 erschien am 17. September 2026 mit 11 Sicherheitskorrekturen und 17 Core-Fehlerbehebungen. Im Mittelpunkt steht eine gespeicherte Cross-Site-Scripting-Schwachstelle in wpautop(), die ohne Authentifizierung ausgenutzt werden kann. Cross-Site-Scripting, oder XSS, bedeutet, dass ein Angreifer eine Website dazu bringen kann, unerwünschtes Skript im Browser eines Besuchers auszuführen. Gespeicherte XSS ist schwerwiegender als ein einmaliger Link, weil der schädliche Inhalt auf der Website gespeichert wird und später bei anderen Besuchern ausgeführt werden kann.

Patchstack zufolge betrifft die wichtigste Schwachstelle WordPress Core bis einschließlich 7.1 und wurde als CVE-2026-93485 zugewiesen. Sie hat einen CVSS-3.1-Wert von 7.1 mit dem Vektor AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:L. CVSS, das Common Vulnerability Scoring System, ist ein Standardverfahren zur Beschreibung des Schweregrads und der Angriffsbedingungen. Einfach ausgedrückt ist dieses Problem über das Netzwerk erreichbar, erfordert kein Konto, setzt aber eine Benutzerinteraktion voraus, etwa dass jemand die betroffene Seite ansieht.

Das wichtige Detail für Website-Betreiber ist der Einstiegspunkt. Patchstack beschreibt eine Payload, die von einem anonymen Besucher über das normale Kommentarformular in einen gewöhnlichen öffentlichen Kommentar eingefügt wird. Sie passiert wp_kses(), den WordPress-Kommentarbereiniger, der nicht erlaubtes Markup entfernt, weil der eingereichte Inhalt zunächst nicht wie die Art von HTML aussieht, für deren Entfernung der Filter ausgelegt ist. Die Gefahr entsteht später, wenn WordPress den Kommentar anzeigt und seine Anzeigefilter das Markup umformen.

Die anfällige Funktion ist wpautop(), die sich in wp-includes/formatting.php befindet. Dieser Core-Filter wandelt Zeilenumbrüche in vielen von WordPress gerenderten Inhalten in Absätze um. Patchstack weist darauf hin, dass wpautop() mit Text und regulären Ausdrücken arbeitet, statt HTML so zu parsen, wie es ein Browser tun würde. Ein Ausdruck, der Absatz-Tags um Blockquotes verschob, berücksichtigte keine in Anführungszeichen gesetzten Attributwerte. Er behandelte das erste Größer-als-Zeichen, auf das er traf, als Ende eines Tags, selbst wenn dieses Zeichen innerhalb eines in Anführungszeichen gesetzten Attributwerts stand.

Patchstacks Erklärung ist subtil, aber wichtig. Ein Angreifer musste dieses Größer-als-Zeichen nicht direkt liefern. Früher in wpautop() schützt WordPress Zeilenumbrüche innerhalb von Tags, indem es sie durch einen Platzhalter ersetzt. Dieser Platzhalter ist ein HTML-Kommentar, und ein HTML-Kommentar endet mit einer Sequenz, die ein Größer-als-Zeichen enthält. Die Kommentar-Allowlist von WordPress erlaubt ein blockquote mit einem cite-Attribut, und ein Zeilenumbruch innerhalb dieses cite-Werts ist nichts, was wp_kses() normalerweise entfernen würde. Der Anzeigeprozess liefert daher das Zeichen, das später hilft, die Tag-Struktur aufzubrechen.

Sobald das geschieht, kann das Tag an der falschen Stelle geteilt werden, das eigentliche schließende Anführungszeichen des Attributs bleibt an einer falschen Position zurück, und spätere Anzeigefilter schließen die Umwandlung ab. Patchstack sagt, dass vom Angreifer kontrollierter Text dort landen kann, wo Attribute hingehören, statt sicher innerhalb eines Attributwerts zu bleiben. Das Ergebnis ist Skriptausführung im eigenen Ursprung der Website für jeden Besucher, der die Seite lädt, unabhängig davon, ob dieser Besucher angemeldet ist oder nicht. Patchstack hat keine funktionierende Payload und nicht die vollständige Ausbruchskette veröffentlicht.

Die Korrektur in WordPress 7.1.1 ändert den betreffenden Ausdruck so, dass er in Anführungszeichen gesetzte Werte versteht. Das bedeutet, dass ein Größer-als-Zeichen innerhalb eines in Anführungszeichen gesetzten Attributs nicht mehr als Ende des Tags behandelt wird. Patchstack sagt, dass seine Kunden vor diesem gespeicherten XSS-Problem geschützt sind, empfiehlt Websites aber weiterhin, auf die neueste verfügbare WordPress-Version zu aktualisieren.

Es gibt eine praktische Grenze für die Ausnutzung: Der Kommentar muss veröffentlicht werden. In einer standardmäßigen WordPress-Installation hält comment_previously_approved einen erstmaligen Kommentator zur Moderation zurück, was bedeutet, dass die Payload in der Warteschlange bleibt, bis jemand sie freigibt. Moderation ist jedoch keine Sicherheitsgrenze. Kommentare freizugeben ist eine Routinetätigkeit, der schädliche Kommentar kann in der Moderationswarteschlange unauffällig aussehen, und Kommentatoren, die bereits zuvor freigegeben wurden, werden danach automatisch freigegeben. Websites mit öffentlichen Kommentaren sollten dies als die vorrangige Korrektur in der Veröffentlichung behandeln, insbesondere dort, wo Moderation delegiert wird oder wiederkehrende Kommentatoren automatisch durchgelassen werden.

Patchstacks Zeitachse besagt, dass das Problem am 15. September 2026 an das Patchstack Vulnerability Disclosure Program gemeldet, validiert und als an das WordPress-Team kommuniziert bestätigt wurde. WordPress 7.1.1 wurde am 17. September 2026 mit der Korrektur und Backports für ältere unterstützte Zweige veröffentlicht. Die Zeitachse enthält außerdem einen Eintrag vom 18. September 2026, der dieselbe Veröffentlichung und dieselben Backports beschreibt, und besagt, dass die Schwachstelle am 18. September 2026 in der Patchstack-Schwachstellendatenbank veröffentlicht wurde.

Auch der Rest der Sicherheitsveröffentlichung ist relevant, obwohl die meisten der anderen zehn Korrekturen ein Konto mit einem gewissen Berechtigungsniveau erfordern. Zugriff auf Contributor-Ebene reichte für ein beliebiges Überschreiben von Beiträgen und für Path Traversal im REST-API-Templates-Controller aus. Eine REST API ist eine Webschnittstelle, die Software nutzen kann, um Daten anzufordern oder zu ändern. Zugriff auf Contributor-Ebene reichte außerdem für die Offenlegung von Slugs für Entwürfe und ausstehende Beiträge aus, also der kurzen URL-freundlichen Namen, die in Beitragsadressen verwendet werden.

Weitere Korrekturen betrafen ein Problem, bei dem jeder authentifizierte Benutzer Kommentare, einschließlich Notizen, einem neuen übergeordneten Element zuordnen konnte, sowie ein XML-RPC-Problem auf Author-Ebene, das das Veröffentlichen von Changeset-Beiträgen erlaubte, während die Berechtigungsprüfung für benutzerdefiniertes CSS übersprungen wurde. XML-RPC ist eine ältere Fernsteuerungsschnittstelle, über die Software mit WordPress kommunizieren kann. Die Veröffentlichung behob außerdem gespeicherte XSS in benutzerdefinierten Header-Bildern bei einigen Themes, ein HTML-API-Problem, das veränderten Text aus einem HTML-Kommentar entkommen ließ, sowie eine präparierte URL, die ein Theme von WordPress.org installieren und in der Vorschau anzeigen konnte.

Multisite-Installationen waren ebenfalls von einer Korrektur betroffen. Multisite ist ein WordPress-Modus, bei dem eine Installation mehrere Websites betreiben kann. WordPress 7.1.1 schließt ein Problem, bei dem ein Website-Administrator ein nur für das Netzwerk bestimmtes Plugin netzwerkweit aktivieren konnte. Ein weiteres Problem der Informationsweitergabe legte den Titel eines privaten übergeordneten Beitrags offen.

WordPress 7.1.1 ist über Dashboard, Aktualisierungen, oder direkt von WordPress.org verfügbar. Websites mit aktivierten automatischen Hintergrundaktualisierungen sollten es automatisch erhalten. WordPress hat die Korrekturen bis zurück zu älteren Zweigen ab 4.7 zurückportiert, und die Versionshinweise beschreiben, welcher Zweig welche Korrektur erhalten hat. Patchstack weist jedoch darauf hin, dass nur die neueste WordPress-Version aktiv unterstützt wird und dass Websites diese Version verwenden sollten.

Für Betreiber, die WordPress-Sicherheit nicht allein verwalten möchten, ist AEU Hosting ein Managed-WordPress-Hosting, das durchgängig abgesichert ist und direkt dazu beiträgt, eine Unternehmenswebsite auf eine sicherere Grundlage zu stellen. Ob eine Website intern oder von einem Anbieter verwaltet wird: Die unmittelbare Maßnahme ist dieselbe: WordPress aktualisieren, Kommentareinstellungen prüfen und sicherstellen, dass die Moderation öffentlicher Kommentare nicht als einzige Verteidigung behandelt wird.