WordPress 7.1.3 behebt sieben Sicherheitslücken
WordPress 7.1.3 behebt sieben Sicherheitslücken und vier Softwarefehler in einem am 6. Oktober 2026 veröffentlichten Wartungs- und Sicherheitsrelease. Zu den Schwachstellen gehören offengelegte Kommentare zu privaten Inhalten, zwei Angriffswege für cross-site scripting (XSS), ein denial of service, ein mit dem Export zusammenhängendes SQL injection-Problem, falsche Berechtigungen für sticky posts und eine Kollision zwischen internen Aktionsnamen. Das Release sollte zeitnah installiert werden, obwohl es nicht als unmittelbarer Notfall eingestuft wird, bei dem alles andere liegen bleiben sollte, da die meisten Angriffe bestimmte Zugriffsrechte und Interaktionen voraussetzen.
Dies unterscheidet sich von WordPress 7.1.2, das zwei Wochen zuvor veröffentlicht wurde. Dieses Update behob CVE-2026-87902, ein Problem, durch das ein nicht authentifizierter Besucher, also jemand ohne Benutzerkonto, local file inclusion auslösen und den Server möglicherweise dazu bringen konnte, eine unbeabsichtigte lokale Datei zu laden. Bei einer entsprechenden PHP-Konfiguration konnte dies zu remote code execution führen, also dazu, dass von einem anderen Ort aus Befehle auf dem Server ausgeführt werden. In 7.1.3 beginnen zwei Schwachstellen bei einem nicht authentifizierten Besucher, drei erfordern ein Contributor- oder Author-Konto, eine setzt voraus, dass ein Administrator einen Export ausführt, und eine hängt davon ab, wie ein Plugin Beitragsdaten bereitstellt.
Einer der nicht authentifizierten Angriffswege ist stored cross-site scripting (XSS), bei dem schädlicher Browsercode von einer Website gespeichert und später an einen anderen Benutzer ausgeliefert wird. Der Handler des Help-Tabs in wp-admin/js/common.js übergab den href-Wert eines Links an die $()-Funktion von jQuery, die HTML erzeugen kann, wenn eine Zeichenfolge HTML ähnelt. Ein Angreifer konnte einen solchen Link innerhalb eines ausstehenden Kommentars platzieren, eingebettet in ein Element mit der Klasse contextual-help-tabs. Für den Angriff war dennoch erforderlich, dass ein Editor oder ein anderer Moderator bei der Prüfung des Kommentars auf den Link klickte.
Vor WordPress 7.1.0 konnten Besucherkommentare die erforderliche Klasse nicht enthalten. Diese Version führte die Unterstützung der span-Klasse für Erwähnungen in Notizen ein und beschränkte den Wert beim Speichern. Patchstack grenzt das Angriffsfenster für ausstehende Kommentare daher auf die Versionen 7.1.0 bis 7.1.2 ein. WordPress 7.1.3 ersetzt den riskanten Vorgang durch .find(), das den übergebenen Wert ausschließlich als selector interpretiert, also als Muster zum Auffinden eines bereits vorhandenen Seitenelements. Ältere backported Updates härten denselben Code ab.
Eine separate denial of service-Schwachstelle betraf WP_Http::make_absolute_url(). Ein denial of service macht ein System nicht verfügbar oder lässt es nicht mehr reagieren. Die Funktion enthielt eine Schleife, die Pfadsegmente mit segment/../ zusammenfassen sollte, doch bei einem relativen Pfad wie a//../b fand die Abgleichsregel keine Übereinstimmung. Da der Pfad unverändert blieb, endete die Schleife nie. Ein Benutzer mit einem Contributor-Konto konnte die Schwachstelle über die Linkvorschau des Block-Editors erreichen, indem er auf eine Seite unter seiner Kontrolle verlinkte. Der korrigierte Code beendet die Schleife, wenn bei einem Durchlauf keine Ersetzung erfolgt.
Die WXR-Exportfunktion enthielt außerdem ein second-order SQL injection-Problem. SQL injection bezeichnet das Einfügen manipulierter Daten in einen Datenbankbefehl; second-order bedeutet, dass der gefährliche Wert zunächst gespeichert und erst später verwendet wird. WordPress übernahm IDs von Beitragsbildern direkt aus den _thumbnail_id-Metadaten und fügte sie in einer Datenbankabfrage zusammen, ohne zuvor sicherzustellen, dass es sich um Ganzzahlen handelte. Version 7.1.3 wendet an drei Stellen absint() an, wodurch ein Wert in eine nicht negative Ganzzahl umgewandelt wird. Der verwundbare Code existiert seit 6.5.0 und wird nur erreicht, wenn ein Administrator einen einzelnen Inhaltstyp exportiert. Der standardmäßige Export All content verwendet ihn nicht.
Authors konnten Beiträge außerdem über die REST API als sticky markieren, eine Schnittstelle, über die Software Anfragen an WordPress sendet. Die Berechtigungsprüfung lehnte eine Anfrage nur dann ab, wenn dem Benutzer sowohl die Fähigkeiten edit_others_posts als auch publish_posts fehlten. Authors verfügen über publish_posts und bestanden daher diese Prüfung. Die Korrektur ändert die logische Bedingung von &&, also und, zu ||, also oder, sodass bereits das Fehlen einer der erforderlichen Berechtigungen ausreicht, um die Anfrage zu stoppen.
Das zweite nicht authentifizierte Problem legte Kommentare offen, die privaten oder unveröffentlichten Beiträgen zugeordnet waren. Bei einem Kommentar-Feed für einen einzelnen Beitrag rief WP_Query die Kommentare ab, bevor geprüft wurde, ob der Besucher den Beitrag sehen durfte. WordPress entfernte anschließend den Beitrag aus dem Ergebnis, ließ dessen Kommentare jedoch bestehen. Da Feeds in dieser Situation keine 404-Antwort zurückgeben, wurden die Kommentare ausgegeben. Version 7.1.3 führt die Kommentarabfrage erst nach der Sichtbarkeitsprüfung aus.
Eine weitere XSS-Schwachstelle betraf Imgur-Einbettungen. WordPress leitet HTML von nicht vertrauenswürdigen oEmbed-Anbietern normalerweise durch einen Filter, der es auf ein sandboxed iframe beschränkt, also auf einen isolierten Frame innerhalb der Seite. Imgur stand auf der Liste vertrauenswürdiger Anbieter, weshalb die API-Antwort den Filter umging und direkt angezeigt wurde. Diese Antworten können Text enthalten, der vom Uploader eines Bildes oder Albums bereitgestellt wurde, sodass vom Angreifer kontrollierte Inhalte ungefiltert auf eine Seite gelangen konnten. Die Korrektur entfernt Imgur aus der Liste vertrauenswürdiger Anbieter, sodass dessen URLs nicht mehr ohne diesen Schutz eingebettet werden. Für die Ausnutzung sind ein Contributor-Konto oder höhere Berechtigungen sowie eine Zielperson erforderlich, die den betroffenen Inhalt aufruft.
Durch das Update werden zuvor im Cache gespeicherte Imgur-oEmbed-Inhalte nicht entfernt. Vorhandene _oembed_*-Beitragsmetadaten und oembed_cache-Beiträge können daher weiterhin eine schädliche Einbettung anzeigen. Patchstack empfiehlt, nach der Installation des Releases den Cache der Website zu leeren, damit diese gespeicherten Inhalte nicht weiter dargestellt werden.
Die letzte Sicherheitsänderung verhindert Kollisionen zwischen Namen von action hooks. Action hooks sind benannte Stellen, an denen Plugins ihren eigenen Code ausführen können. Wenn sich der Status eines Beitrags ändert, erstellt wp_transition_post_status() einen hook, dessen Name aus dem neuen Status und dem Beitragstyp gebildet wird; beim Veröffentlichen eines normalen Beitrags entsteht somit publish_post. Andere WordPress-Vorgänge verwenden ähnliche Namen, darunter delete_post für das Löschen und comment_post beim Hinzufügen eines Kommentars.
WordPress 7.1.2 prüfte vor dem Erstellen dieses Namens nicht, ob der übergebene Status und Beitragstyp registriert waren. Ein Plugin, das Rohdaten an wp_insert_post() übergab, konnte einen Beitrag mit dem Status delete und dem Typ post speichern, wodurch delete_post ausgeführt wurde, obwohl keine tatsächliche Löschung stattgefunden hatte. Jeder mit dieser Aktion verbundene callback verhielt sich dann so, als sei ein Beitrag gelöscht worden. WordPress 7.1.3 löst diese dynamisch erstellten hooks nur aus, wenn sowohl der Status als auch der Beitragstyp registriert sind.
Als Mitwirkende an den sieben Korrekturen wurden Trail of Bits, Anthropic, Patchstack, das WordPress Security Team und mehrere einzelne Sicherheitsforscher genannt. WordPress 7.1.3 und backports bis zu den 6.6-Releases wurden am 6. Oktober verfügbar, und Patchstack nahm die veröffentlichten Schwachstellen noch am selben Tag in seine Datenbank auf. Zum Zeitpunkt der Veröffentlichung hatten die Branches 4.7 bis 6.5 noch keine Patches erhalten.
Administratoren können WordPress 7.1.3 über Dashboard und anschließend Updates installieren oder es von WordPress.org beziehen. Websites mit aktivierten automatischen Hintergrundupdates sollten es automatisch erhalten. Administratoren sollten außerdem überprüfen, wer über Contributor-, Author-, Editor- oder höhere Rollen verfügt, da mehrere dieser Schwachstellen von den Zugriffsrechten abhängen, die diese Konten gewähren.