WordPress 7.1.3: Sicherheitsupdate für Kommentare und Export
WordPress 7.1.3 ist seit dem 6. Oktober verfügbar. Das Sicherheitsrelease korrigiert Probleme in Kommentaren, Export, HTTP-Verarbeitung und Rollenrechten. Das Projekt empfiehlt sofortige Updates, auch für ältere betroffene Zweige stehen Korrekturen bereit.

WordPress 7.1.3 ist seit dem 6. Oktober 2026 verfügbar. Das Sicherheitsrelease behebt unter anderem Cross-Site Scripting, eine SQL-Injection beim Export und die Offenlegung nicht öffentlicher Kommentare. Betreiber von WordPress-Websites sollten den tatsächlich installierten Core-Stand heute prüfen und das angebotene Sicherheitsupdate zeitnah einspielen. WordPress empfiehlt ausdrücklich eine sofortige Aktualisierung.
Die Meldung betrifft den WordPress-Kern, nicht nur ein bestimmtes Plugin. Installationen mit nachweislich eingespieltem 7.1.3 benötigen für diese Version kein weiteres Core-Update. Websites auf anderen CMS sind nicht betroffen. Für ältere WordPress-Zweige nennt das Projekt ebenfalls Sicherheitskorrekturen, veröffentlicht auf der Release-Seite aber keine vollständige Zuordnung der betroffenen Versionen. Ein alter Hauptzweig sollte deshalb nicht pauschal als sicher gelten.
Was ist neu in WordPress 7.1.3?
Die offizielle Versionsdokumentation bestätigt den öffentlichen Release am 6. Oktober. BornCity berichtet am selben Tag über das Update und übernimmt die Liste der Sicherheitsprobleme. Neue Editor-Funktionen stehen hier nicht im Mittelpunkt: Es geht um die Absicherung bestehender Websites und ihrer Verwaltungsfunktionen.
Die Primärquelle ist bei der Zahl der Korrekturen widersprüchlich: Im Einleitungssatz steht eine Sicherheitskorrektur, darunter folgen sieben Einträge. Entscheidend sind deshalb die konkret beschriebenen Fehler, nicht eine aus dem Einleitungssatz abgeleitete Gesamtzahl. Die Release-Seite nennt weder CVE-Kennungen noch CVSS-Werte. Eine belastbare Schweregradbewertung für jede einzelne Lücke lässt sich daraus nicht ableiten.
Welche Angriffsflächen werden geschlossen?
- Kommentarverwaltung: Gespeichertes Cross-Site Scripting kann laut Projekt über noch nicht freigegebene Kommentare ausgelöst werden. Die Moderationswarteschlange ist damit eine relevante Angriffsfläche, nicht nur der öffentlich sichtbare Kommentarbereich.
- HTTP-Verarbeitung: Ein Denial-of-Service-Problem betrifft
WP_Http::make_absolute_url(). Die Kurzbeschreibung legt nicht offen, welche konkreten Aufrufe oder Eingaben die Störung auslösen. - WXR-Export: WordPress nennt eine SQL-Injection zweiter Ordnung beim Export. Anders als eine unmittelbare Eingabeauswertung beschreibt diese Fehlerklasse eine spätere Verarbeitung bereits gespeicherter Daten; genaue Voraussetzungen bleiben in den Release Notes offen.
- Autorenrechte: Eine Schwäche erlaubt Benutzern mit der Rolle Autor, Beiträge als hervorgehoben zu markieren. Das betrifft die Rechteabgrenzung innerhalb der Redaktion und ist nicht gleichbedeutend mit einer vollständigen Administratorübernahme.
- Nicht öffentliche Kommentare: Kommentare zu privaten und unveröffentlichten Beiträgen können ohne Authentifizierung offengelegt werden. Hier steht die Vertraulichkeit im Vordergrund, nicht die Ausführung von Servercode.
- Imgur-Einbettungen: Die Release Notes beschreiben eine weitere XSS-Angriffsfläche bei eingebetteten Imgur-Inhalten. Daraus folgt keine pauschale Aussage über sämtliche externen Medienanbieter.
- Hook-Parameter: Manipulierbare Parameter für
{status}_{type}können zu einer Kollision von Aktionsnamen führen. Welche Erweiterungen davon praktisch betroffen sein können, erläutert die Kurzmeldung nicht.
Wie dringend ist das Update?
Die Herstellerempfehlung lautet sofort aktualisieren. Für öffentlich erreichbare Unternehmenswebsites ist das ein Anlass für ein kurzfristiges Sicherheitsfenster, nicht für das Warten auf den nächsten monatlichen Wartungstermin. Vorrang haben Bestände mit Kommentarfunktion, mehreren Redaktionskonten oder vertraulichen, noch nicht veröffentlichten Inhalten. Diese Priorisierung ersetzt jedoch keine Prüfung anderer WordPress-Installationen.
Die ausgewerteten Quellen liefern keinen Nachweis aktiver Ausnutzung und keine Aussage zu veröffentlichten Exploits. Ein fehlender Nachweis bedeutet nicht, dass Angriffe ausgeschlossen sind. Ebenso wäre es falsch, aus den XSS- und Exportproblemen eine belegte unauthentifizierte Remote Code Execution zu machen. Die Angriffswege unterscheiden sich: Kommentare können eine Verwaltungssitzung erreichen, die Offenlegung betrifft Daten, das DoS-Problem die Verfügbarkeit.
Das Projekt stellt Korrekturen auch für ältere betroffene Zweige bereit, erinnert aber ausdrücklich daran, dass nur die neueste WordPress-Version aktiv unterstützt wird. Solche Rückportierungen sind daher eine kurzfristige Entlastung für Altbestände, kein dauerhafter Ersatz für die Migration auf eine unterstützte Version.
Was sollten Admins jetzt prüfen?
- Bestand und Version erfassen: Alle produktiven Installationen, Testkopien und betreuten Kundenseiten auflisten. Im Dashboard oder mit
wp core versionden laufenden Stand feststellen und nicht allein auf eine Update-E-Mail vertrauen. - Passendes Update zuordnen: Für die Reihe 7.1 ist 7.1.3 das hier behandelte Ziel. Bei älteren Zweigen das tatsächlich angebotene Sicherheitsrelease kontrollieren und einen Wechsel auf die aktuelle Version gesondert planen.
- Sicherung und Rückweg klären: Vor dem Eingriff ein vollständiges Backup von Datenbank und Dateien bereithalten. Bei Shops und Buchungssystemen muss der Rückweg auch zwischenzeitliche Geschäftsdaten berücksichtigen.
- Core gezielt aktualisieren: Das Sicherheitsupdate über den bestehenden Wartungsprozess einspielen. Bei individuell erweiterten Websites einen kurzen Kompatibilitätscheck vorziehen, ohne den Patch auf unbestimmte Zeit zu verschieben.
- Ergebnis nachweisen: Versionsnummer erneut auslesen, Anmeldung, Kommentare, Export und wichtige Kundenabläufe prüfen. Datum, Zielversion, Verantwortliche und verbleibende Ausnahmen dokumentieren.
- Automatik kontrollieren: Wenn Hintergrundupdates vorgesehen sind, ihren tatsächlichen Erfolg bestätigen. Ein eingerichteter Automatismus ist kein Beleg, dass der neue Core auf jeder Installation angekommen ist.
Was das Release nicht ersetzt
Ein Core-Update aktualisiert keine veralteten Plugins oder Themes und bereinigt keine bereits kompromittierte Website. Bei auffälligen Dateiänderungen, unerwarteten Konten oder verdächtigen Kommentaren braucht es eine eigene Untersuchung. Umgekehrt rechtfertigt die Release-Meldung allein noch keine Behauptung, eine konkrete Website sei gehackt worden.
Für Dienstleister und kleine Unternehmen ist die wichtigste Entscheidung heute klar: Patchstand feststellen, Sicherheitsupdate kurzfristig durchführen und den Abschluss belegen. Ein größerer Funktionsausbau oder ein allgemeiner Relaunch gehört nicht in dieselbe Änderung. Die Trennung hält das Wartungsfenster überschaubar und erleichtert bei Problemen die Ursachenanalyse.
Passende Anleitungen auf S-EDV
- WordPress-Core-Updates sicher einspielen: Ablauf für Sicherung, kontrollierte Aktualisierung und Nachprüfung einer bestehenden Website.
- Automatische WordPress-Updates steuern: Einordnung der getrennten Update-Regeln für Core, Plugins und Themes sowie der notwendigen Erfolgskontrolle.
Quellen
- WordPress.org: Versionsdokumentation zu WordPress 7.1.3, Primärquelle, erstmals veröffentlicht am 6. Oktober 2026. Release-Datum, Fehlerliste und Update-Empfehlung.
- BornCity: WordPress 7.1.3 verfügbar, unabhängige Fachmeldung vom 6. Oktober 2026 mit der Liste der Sicherheitskorrekturen.


