TL;DR. WordPress 7.1.3 schließt sieben Sicherheitslücken im Core, darunter ein Stored XSS über unmoderierte Kommentare und eine SQL-Injection im Export. Aktualisieren Sie umgehend.
| Release | WordPress 7.1.3 vom 06.10.2026, Sicherheits- und Wartungsrelease mit 7 Security-Fixes und 4 Bugfixes. Drittes Security-Release innerhalb von 19 Tagen. |
| Gefährlichste Lücke | Stored XSS auf der Kommentar-Verwaltungsseite: Schadcode in einem unmoderierten Kommentar wird ausgeführt, sobald ein Administrator die Moderationsliste öffnet. |
| Lage | Stand 06.10.2026 keine bekannten aktiven Angriffe und kein öffentlicher Exploit-Code. CVE-Nummern und CVSS-Einstufungen stehen noch aus. |
| Besonderheit | Drei der sieben Lücken wurden von Anthropic gemeldet, einem KI-Unternehmen. KI-gestützte Schwachstellensuche erreicht damit sichtbar den WordPress-Core. |
| Sofortmaßnahme | Update auf 7.1.3 über Dashboard → Aktualisierungen, vorher Backup. Im Wartungsvertrag von CMS ADMINS übernehmen wir Prüfung und Update für Sie. |
Veröffentlicht: 06.10.2026 · Letzte Aktualisierung: 06.10.2026
Was ist passiert
Am 6. Oktober 2026 hat das WordPress-Team Version 7.1.3 veröffentlicht, ein kombiniertes Sicherheits- und Wartungsrelease. Es schließt sieben Sicherheitslücken im WordPress-Core und behebt vier weitere Fehler. Die offizielle Release-Ankündigung empfiehlt ausdrücklich, Websites sofort zu aktualisieren. Installationen mit aktivierten automatischen Hintergrund-Updates erhalten die neue Version von selbst.
Bemerkenswert ist der Takt: 7.1.3 ist bereits das dritte Security-Release innerhalb von 19 Tagen, nach 7.1.1 am 17. September und 7.1.2 am 22. September 2026. Das ist kein Zeichen für ein unsicheres WordPress, sondern eher für eine aktuell sehr aktive Schwachstellensuche, dazu unten mehr.
Die Sicherheitsfixes werden wie üblich auf ältere Versionszweige zurückportiert, derzeit bis hinunter zu Version 4.7. Diese Backports waren zum Release-Zeitpunkt noch in Arbeit. Wer auf einem älteren Zweig unterwegs ist, bleibt also noch etwas länger verwundbar als Nutzer der aktuellen Version.
Die sieben Lücken im Überblick
WordPress nennt in der Ankündigung wie gewohnt nur Kurzbeschreibungen, keine technischen Details, um unachtsame Seitenbetreiber nicht unnötig zu gefährden. CVE-Nummern und CVSS-Bewertungen lagen am Veröffentlichungstag noch nicht vor. Das ist der bekannte Ablauf: Die Einträge werden von den CVE-Vergabestellen in den Tagen nach dem Release nachgereicht.
Wir wollten es genauer wissen und haben den Quellcode von WordPress 7.1.2 und 7.1.3 Datei für Datei verglichen. Die Patches zeigen präzise, wo die Probleme lagen, und erlauben eine fundiertere Risikobewertung, als es die Kurzbeschreibungen hergeben.
1. Stored XSS auf der Kommentar-Verwaltungsseite
Die aus unserer Sicht relevanteste Lücke, gemeldet von Thomas Chauchefoin von Trail of Bits. Ein Angreifer kann über einen noch nicht freigegebenen Kommentar Schadcode hinterlegen. Der Code wird ausgeführt, sobald ein Administrator oder Moderator die Kommentar-Verwaltungsseite im Backend öffnet, also genau dann, wenn er den verdächtigen Kommentar prüfen will. Der Angreifer braucht dafür kein Benutzerkonto, es genügt die Möglichkeit, einen Kommentar abzusenden.
Blick in den Code: Der Patch ändert in der Admin-Skriptdatei wp-admin/js/common.js eine einzige Zeile: aus $( link.attr('href') ) wird $( document ).find( link.attr('href') ). Das ist das Lehrbuchmuster einer jQuery-Selektor-Injektion. Der alte Code übergab den Inhalt eines href-Attributs direkt an die jQuery-Funktion $(). Die interpretiert ihr Argument aber nicht nur als Suchselektor, sondern baut daraus fertiges HTML, sobald der Wert wie Markup aussieht, zum Beispiel ein <img>-Tag mit einem onerror-Attribut. Gelangt also ein angreiferkontrollierter Wert in dieses href, wird aus einer harmlosen Link-Auswertung Codeausführung im Browser des angemeldeten Administrators. Die neue Variante .find() kann ausschließlich suchen und nichts erzeugen, damit ist der Weg versperrt.
wp-admin/js/common.js — der komplette Fix der Kommentar-XSS-Lücke:
- panel = $( link.attr('href') );
+ panel = $( document ).find( link.attr('href') );Dass der Fix im zentralen Admin-JavaScript liegt, erklärt auch die Tragweite: Stored XSS im Admin-Kontext ist der klassische Weg zur vollständigen Übernahme einer Website, etwa durch das unbemerkte Anlegen eines zusätzlichen Administrator-Kontos im Hintergrund, während der Admin nur eine Kommentarliste betrachtet.
2. Second-Order SQL-Injection im WXR-Export
Gemeldet von Anthropic. Hier wird eine manipulierte Eingabe zunächst harmlos in der Datenbank gespeichert und entfaltet ihre Wirkung erst später, wenn jemand die Export-Funktion von WordPress nutzt (Werkzeuge → Daten exportieren, das WXR-Format).
Blick in den Code: In wp-admin/includes/export.php sammelte der Export unter anderem die IDs von Beitragsbildern aus der Postmeta-Tabelle ein und fügte sie unmaskiert in eine SQL-Abfrage der Form WHERE ID IN (…) ein. Wer es schaffte, in diese Meta-Werte etwas anderes als eine Zahl zu schreiben, etwa über ein nachlässiges Plugin oder einen Import, hatte damit einen Injektionspunkt, der erst beim nächsten Export zündete. Der Patch erzwingt an drei Stellen mit absint(), dass ausschließlich positive Ganzzahlen in die Abfrage gelangen, inklusive ausdrücklicher Defense-in-Depth-Kommentare der Core-Entwickler:
wp-admin/includes/export.php — einer der drei neuen Schutz-Casts (Original-Kommentar der Core-Entwickler):
+ // Cast thumbnail IDs to integers to prevent second-order
+ // SQL injection via user-controlled meta values.
+ $thumbnails_ids = array_filter( array_map( 'absint', $thumbnails_ids ) );Der Angriff setzt voraus, dass ein berechtigter Nutzer den Export tatsächlich ausführt, und braucht einen Weg, die präparierten Werte in die Datenbank zu bekommen — ein Baustein für Angriffsketten, kein Selbstläufer.
3. Denial of Service in WP_Http::make_absolute_url()
Ebenfalls von Anthropic gemeldet. Die Methode wandelt relative URLs in absolute um, zum Beispiel beim Verfolgen von Weiterleitungen in ausgehenden HTTP-Anfragen.
Blick in den Code: Beim Auflösen von ../-Bestandteilen im URL-Pfad lief in wp-includes/class-wp-http.php eine Ersetzungsschleife, die bei bestimmten präparierten Pfaden nie zum Ende kam: Die reguläre Ersetzung griff nicht mehr, die Abbruchbedingung aber auch nicht — eine Endlosschleife, die einen PHP-Prozess zu 100 Prozent auslastet. Der Patch zählt jetzt die tatsächlich ausgeführten Ersetzungen mit und bricht ab, sobald nichts mehr ersetzt wird. Kein Datenabfluss, aber ein Verfügbarkeitsrisiko: Wer den Server dazu bringen kann, eine solche URL zu verarbeiten, bindet pro Aufruf einen Worker-Prozess.
4. Autoren können Beiträge als „sticky“ markieren
Die dritte Anthropic-Meldung, und im Code die vielleicht lehrreichste: In der REST-API-Rechteprüfung (class-wp-rest-posts-controller.php) war schlicht die Logik verdreht. Geprüft wurde, ob dem Nutzer beide Berechtigungen fehlen (&&), bevor die Aktion verweigert wurde — korrekt ist, zu verweigern, sobald eine der beiden fehlt (||). Ein Autor, der eigene Beiträge veröffentlichen darf, rutschte so durch die Prüfung und konnte Beiträge oben auf der Startseite anpinnen, obwohl das Redakteuren und Administratoren vorbehalten ist. Ein einzelner verwechselter Operator, jahrelang unbemerkt:
wp-includes/rest-api/endpoints/class-wp-rest-posts-controller.php — der verdrehte Operator:
- ! current_user_can( …edit_others_posts ) && ! current_user_can( …publish_posts )
+ ! current_user_can( …edit_others_posts ) || ! current_user_can( …publish_posts )Das Schadpotenzial ist begrenzt und betrifft vor allem Mehrautoren-Blogs und Portale.
5. Kommentare privater Beiträge ohne Anmeldung lesbar
Gemeldet von Ananda Dhakal von Patchstack. Kommentare unter privaten oder noch unveröffentlichten Beiträgen konnten von nicht angemeldeten Besuchern ausgelesen werden, der naheliegende Kanal dafür sind die Kommentar-Feeds, die WordPress für jeden Beitrag bereitstellt.
Blick in den Code: In wp-includes/class-wp-query.php wurde der komplette Block, der die Kommentarliste für einen Beitrags-Feed aus der Datenbank lädt, im Verarbeitungsablauf nach hinten verschoben — hinter die Stelle, an der WordPress entscheidet, ob der Besucher den Beitrag überhaupt sehen darf. Vorher wurden die Kommentare geladen, bevor diese Sichtbarkeitsprüfung abgeschlossen war. Ein Informationsleck, dessen Brisanz davon abhängt, was in solchen Kommentaren steht; in Redaktionen sind das nicht selten interne Abstimmungen zu unveröffentlichten Inhalten.
6. XSS über Imgur-Einbettungen
Gemeldet von Zhengyu Liu, Jingcheng Yang und Gavin Zhong. Die Antwort des Core-Teams ist bemerkenswert rigoros: Imgur wurde nicht repariert, sondern komplett aus der Liste der vertrauenswürdigen oEmbed-Anbieter entfernt (ebenso Someecards). Die Lücke lag also im Zusammenspiel mit dem externen Dienst, dem WordPress beim Einbetten vertraute. Praktische Folge für Redaktionen: Bereits eingebettete Imgur-Inhalte werden nach dem Update nicht mehr als Vorschau gerendert, sondern als einfacher Link angezeigt. Wer Imgur-Embeds im Einsatz hat, sollte die betroffenen Beiträge prüfen.
7. Action-Namen-Kollision im {status}_{type}-Hook
Gemeldet von Alex Concha aus dem WordPress-Security-Team selbst. WordPress löst bei jedem Statuswechsel eines Beitrags interne Hooks aus, deren Name sich dynamisch aus Status und Inhaltstyp zusammensetzt, etwa publish_post. Da Status- und Typnamen teils aus fälschbaren Parametern stammen konnten, ließen sich Hook-Namen konstruieren, die mit ganz anderen, legitimen Actions kollidieren. Der Patch in wp-includes/post.php validiert Status und Inhaltstyp jetzt gegen die tatsächlich registrierten Objekte, bevor der Hook-Name gebaut wird. Für sich genommen harmlos, als Baustein in Angriffsketten mit unsauber programmierten Plugins aber durchaus relevant.
Wie kritisch ist das Release?
Unsere Einschätzung nach dem Blick in den Code: ernst nehmen und zügig patchen, aber kein Grund zur Panik. Keine der sieben Lücken erlaubt für sich genommen die direkte Codeausführung ohne Anmeldung, und zum Veröffentlichungszeitpunkt sind weder aktive Angriffe noch öffentlicher Exploit-Code bekannt.
Zwei Punkte sprechen trotzdem für Eile. Erstens ist das Stored XSS über Kommentare massenhaft automatisierbar: Ein Angreifer muss nur Kommentare an viele WordPress-Seiten verschicken und warten, bis irgendwo ein Administrator die Moderationsliste öffnet. Sites mit offener Kommentarfunktion sind das bevorzugte Ziel. Zweitens beginnt mit jedem Security-Release ein Wettlauf: Sicherheitsforscher und Angreifer vergleichen den Code der alten und der neuen Version und rekonstruieren daraus die Lücken. Bei Core-Schwachstellen dauert das erfahrungsgemäß Tage, nicht Wochen.
Die eigentliche Story: KI findet Lücken im WordPress-Core
Ein Detail dieser Ankündigung verdient besondere Aufmerksamkeit: Drei der sieben Schwachstellen wurden von Anthropic gemeldet, dem Unternehmen hinter dem KI-Modell Claude. KI-gestützte Schwachstellenanalyse durchsucht damit nachweislich und erfolgreich eine der meistgeprüften Codebasen der Welt, und findet dort Fehler, die jahrelang übersehen wurden.
Für Seitenbetreiber hat das zwei Seiten. Die gute: Lücken werden schneller gefunden und verantwortungsvoll gemeldet, bevor Kriminelle sie entdecken. Die unbequeme: Dieselbe Technologie steht grundsätzlich auch Angreifern zur Verfügung, und sie verkürzt die Zeit zwischen Patch-Veröffentlichung und funktionierendem Exploit. Der dichte Release-Takt der letzten Wochen, drei Security-Releases in 19 Tagen, dürfte auch eine Folge dieser neuen Dynamik sein. Die praktische Konsequenz ist unspektakulär, aber wichtiger denn je: Updates zeitnah einspielen, am besten automatisiert und überwacht.
Was Sie jetzt tun sollten
- Version prüfen: Dashboard → Aktualisierungen zeigt die installierte Version. Steht dort bereits 7.1.3, hat das automatische Hintergrund-Update gegriffen.
- Backup erstellen: Vor jedem Core-Update ein vollständiges Backup von Dateien und Datenbank anlegen.
- Update einspielen: Per Klick auf „Jetzt aktualisieren“ oder via WP-CLI. Das Update von 7.1.x auf 7.1.3 ist ein Minor-Release und in der Praxis unkritisch für Themes und Plugins.
- Kommentar-Moderation mit Vorsicht: Bis das Update eingespielt ist, die Kommentar-Verwaltungsseite nur zurückhaltend öffnen, genau dort schlägt die XSS-Lücke zu. Auf Sites ohne Kommentarbedarf die Kommentarfunktion ohnehin deaktivieren.
- Alte Installationen prüfen: Websites auf älteren Versionszweigen erhalten Backports verzögert. Besser: auf den aktuellen Zweig migrieren.
Für Kunden mit WordPress-Wartungsvertrag bei CMS ADMINS ist dieses Update Teil der laufenden Betreuung: Wir prüfen die betreuten Websites und spielen das Release inklusive Backup zeitnah ein. Wenn Sie unsicher sind, ob Ihre Website betroffen ist, sprechen Sie uns an.
Häufige Fragen
Muss ich sofort auf WordPress 7.1.3 aktualisieren?
Ja. WordPress stuft das Release selbst als Security-Release ein und empfiehlt das sofortige Update. Auch wenn noch keine aktiven Angriffe bekannt sind, beginnt mit der Veröffentlichung der Fixes der Wettlauf zwischen Patchen und Exploit-Entwicklung.
Ist meine Website akut gefährdet?
Stand 6. Oktober 2026 sind keine aktiven Angriffe und kein öffentlicher Exploit-Code bekannt. Das höchste Risiko tragen Websites mit offener Kommentarfunktion, denn die gefährlichste Lücke wird über unmoderierte Kommentare ausgelöst.
Gibt es schon CVE-Nummern zu den Lücken?
Nein. WordPress veröffentlicht in der Release-Ankündigung nur Kurzbeschreibungen. CVE-Nummern und CVSS-Bewertungen werden von den Vergabestellen erfahrungsgemäß in den Tagen nach dem Release nachgereicht.
Ich nutze eine ältere WordPress-Version. Bin ich geschützt?
Die Fixes werden bis Version 4.7 zurückportiert, waren zum Release-Zeitpunkt aber noch in Arbeit. Offiziell aktiv unterstützt ist ohnehin nur die jeweils aktuelle Version. Planen Sie die Migration auf den aktuellen Zweig.
Warum werden meine Imgur-Einbettungen nach dem Update nicht mehr angezeigt?
WordPress 7.1.3 hat Imgur wegen einer XSS-Schwachstelle vollständig aus der Liste der vertrauenswürdigen oEmbed-Anbieter entfernt. Bestehende Imgur-Embeds werden deshalb nur noch als einfacher Link dargestellt. Prüfen Sie betroffene Beiträge und ersetzen Sie die Einbettungen bei Bedarf durch lokal hochgeladene Bilder.
Was ist ein Stored XSS und warum ist die Kommentar-Lücke so gefährlich?
Stored XSS (gespeichertes Cross-Site-Scripting) bedeutet, dass Schadcode dauerhaft in der Website gespeichert wird und bei jedem Aufruf der betroffenen Seite im Browser des Betrachters ausgeführt wird. Bei dieser Lücke ist der Betrachter ausgerechnet der Administrator in der Kommentar-Moderation, der Schadcode läuft also mit vollen Admin-Rechten im Backend und kann dort zum Beispiel unbemerkt neue Administrator-Konten anlegen.
Übernimmt CMS ADMINS das Update für mich?
Ja. Im Rahmen der WordPress-Wartung prüfen wir Ihre Website, erstellen ein Backup und spielen Sicherheitsupdates wie dieses zeitnah ein.