WordPress 7.1.4 im Diff: Was die 13 Fixes wirklich schließen

Von Patrick Schlesinger · Aktualisiert am 28. Oktober 2026

Veröffentlicht: 28.10.2026 · Letzte Aktualisierung: 28.10.2026

Was ist passiert

WordPress 7.1.4 erschien am 28. Oktober 2026 und schließt 13 Sicherheitslücken. Das WordPress-Projekt stuft die Version als Security-Release ein und empfiehlt, Websites sofort zu aktualisieren.

Es handelt sich um einen Short-Cycle-Release, der nur 22 Tage nach WordPress 7.1.3 vom 6. Oktober 2026 kommt. Unsere Einordnung der Vorgängerversion finden Sie im Beitrag zum Sicherheitsupdate WordPress 7.1.3. Der offizielle Release-Post auf wordpress.org listet die 13 Punkte jeweils in einem Satz und nennt die Melder. Technische Details, CVE-IDs oder Schweregrade hat WordPress nicht veröffentlicht.

Dieser Artikel wertet deshalb den Code selbst aus. Zur Methodik: Wir haben die offiziellen Release-Pakete wordpress-7.1.3.zip und wordpress-7.1.4.zip von wordpress.org verglichen. Der Vergleich ergibt 49 geänderte Dateien. Alle Codezitate unten stammen aus diesem Vergleich. Wo wir aus dem Code auf einen Angriffsweg schließen, ist das als Schlussfolgerung gekennzeichnet und nicht als bestätigte Tatsache.

Zwischenfazit: 7.1.4 ist ein reines Sicherheitsupdate mit 13 Fixes. Zwei davon können nach unserer Analyse am Ende zu Codeausführung führen. Keiner ist ein Angriff ohne jede Vorbedingung.

Der Upgrade-RCE: zwei Fixes, eine Kette

Der schwerste Fund betrifft den Update-Prozess von WordPress selbst. Im Release-Post ist es Punkt 1, gemeldet von Umut Bayram, mit dem Wortlaut „A weakness in the WordPress upgrade process which can lead to remote code execution during the upgrade window“.

Im Diff zeigt sich dieser Punkt als zwei getrennte Änderungen in zwei Dateien. Die erste begrenzt die Wirkung, die zweite entzieht dem Angriff die Vorbedingung. Beide zusammen ergeben ein Bild davon, wie die Kette nach unserer Lesart aussah.

Fix A: wp-config.php wird nicht mehr kopiert

In wp-admin/includes/update-core.php steht wp-config.php jetzt auf der Liste der Dateien, die beim Core-Update nie kopiert werden. Der Diff:

/*
 * Don't copy wp-content, we'll deal with that below.
 * We also copy version.php last so failed updates report their old version.
+ * Never copy a wp-config.php, which could have been written to the working directory.
 */
- $skip = array( 'wp-content', 'wp-includes/version.php' );
+ $skip = array( 'wp-content', 'wp-includes/version.php', 'wp-config.php' );

Beim Core-Update entpackt WordPress das neue Paket in ein Arbeitsverzeichnis und kopiert dessen Inhalt anschließend in das Webroot. Bis 7.1.3 war wp-config.php davon nicht ausgenommen. Der neue Code-Kommentar sagt selbst, warum das ein Problem ist: Eine wp-config.php „could have been written to the working directory“, also könnte im Arbeitsverzeichnis landen, ohne Teil des offiziellen Pakets zu sein.

Daraus lässt sich ableiten, warum genau diese Datei geschützt wird. wp-config.php wird bei jedem Seitenaufruf geladen, bevor Plugins und Themes überhaupt starten. Eine untergeschobene Version dort wäre persistente Codeausführung mit vollem Zugriff auf Datenbank und Dateisystem. Sie würde auch das Entfernen verdächtiger Plugins überstehen, weil sie gar nicht im Plugin-Verzeichnis liegt.

Fix B: unvorhersagbarer Pfad und Verzeichnisschutz

Die zweite Änderung steckt in wp-admin/includes/class-wp-upgrader.php. Sie sorgt dafür, dass niemand den Namen des Arbeitsverzeichnisses vorab kennt. Neu ist diese private Methode mit @since 7.1.4:

private function get_working_dir_name( $package ) {
	// Strip off any .tmp or .zip suffixes.
	$name = basename( basename( $package, '.tmp' ), '.zip' );

	return $name . '-' . wp_generate_password( 16, false );
}

Bis 7.1.3 lautete die entsprechende Zeile in unpack_package():

// We need a working directory - strip off any .tmp or .zip suffixes.
$working_dir = $upgrade_folder . basename( basename( $package, '.tmp' ), '.zip' );

Der Name des Arbeitsverzeichnisses unter wp-content/upgrade/ leitete sich also allein aus dem Paketnamen ab und war damit vorhersagbar. Jetzt hängt WordPress 16 zufällige alphanumerische Zeichen an. Wer in dieses Verzeichnis schreiben will, muss seinen Namen zuerst kennen.

Damit der Name nicht über eine Verzeichnisauflistung herausfindbar ist, legt 7.1.4 im selben Zug eine leere index.php an. Der Code-Kommentar dazu ist ungewöhnlich deutlich:

/*
 * The upgrade directory is web-served. Keep it from being listed, as core does
 * for wp-content and its plugins and themes directories, so the name of the
 * working directory created below cannot be discovered from a directory index.
 */
if ( ! $wp_filesystem->exists( $upgrade_folder . 'index.php' ) ) {
	$wp_filesystem->put_contents( $upgrade_folder . 'index.php', "<?php\n// Silence is golden.\n", FS_CHMOD_FILE );
}

WordPress räumt also offen ein, dass das Upgrade-Verzeichnis über den Webserver erreichbar ist. Die Aufräumroutine, die vor jedem Entpacken den Inhalt von wp-content/upgrade/ löscht, überspringt diese index.php seit 7.1.4 ausdrücklich, damit der Schutz nicht beim nächsten Update wieder verschwindet.

Ergänzend haben wir den Dateibaum des Release-Pakets 7.1.3 geprüft. Dieser Befund stammt nicht aus dem Diff, sondern aus unserer eigenen Prüfung: In wp-content/, wp-content/plugins/ und wp-content/themes/ liegt jeweils eine index.php. Das Verzeichnis wp-content/upgrade/ ist im Paket nicht enthalten, es entsteht erst zur Laufzeit, und zwar bis 7.1.3 ohne diese Datei. Auf Servern mit aktiver Verzeichnisauflistung (Autoindex) war sein Inhalt damit grundsätzlich einsehbar.

Was ein Angreifer dafür bräuchte

Die entscheidende Vorbedingung ist Schreibzugriff in das Arbeitsverzeichnis während des Update-Fensters. Ohne diese Möglichkeit greift keiner der beiden Fixes, und das allein ist kein Massenexploit, den jemand ohne weiteres gegen beliebige Websites richten kann.

Zwei Faktoren erhöhen die Relevanz trotzdem. Erstens, so lässt sich aus dem Code ableiten: In Kombination mit einer Upload- oder Pfad-Traversal-Schwäche in einem beliebigen Plugin wäre aus dieser Kette eine vollständige Übernahme der Website geworden, weil die untergeschobene Konfigurationsdatei vom Updater selbst an ihren Platz gebracht wird. Zweitens ist bei aktivierten automatischen Hintergrund-Updates der Zeitpunkt eines Updates nicht zufällig, sondern in gewissem Rahmen planbar.

Offen und zu prüfen bleibt der konkrete Schreibweg in das Upgrade-Verzeichnis. Der Release-Post nennt ihn nicht, und der Diff zeigt nur die Gegenmaßnahmen. Ebenfalls offen ist, ob einer der beiden Fixes allein die Kette bereits bricht oder ob WordPress bewusst beide Ebenen absichert. Eine Ausnutzung ist Stand 28. Oktober 2026 nicht bekannt.

Zwischenfazit: Der Update-Prozess selbst war ein Angriffspunkt. Die Hürde ist hoch, aber wer bereits eine Schreibmöglichkeit über ein anderes Plugin hat, hätte sie hier in dauerhafte Kontrolle umwandeln können.

Der KSES-Bypass: wenn die Sanitisierung zu früh prüft

Der zweite schwere Fund betrifft KSES, die zentrale Filterschicht von WordPress für Beitragsinhalte. Im Release-Post steht er unter Punkt 4 nur als „Multiple stored XSS issues in the Interactivity API“. Der Diff zeigt 91 geänderte Zeilen in wp-includes/kses.php und zwei neue Funktionen.

KSES säubert die Inhalte aller Nutzer, die nicht das Recht unfiltered_html haben. Auf einer normalen Einzelinstallation sind das die Rollen Mitarbeiter und Autor. Auf Multisite-Netzwerken fehlt dieses Recht sogar den Administratoren einzelner Websites, nur Super-Admins haben es.

Gemeldet wurde Punkt 4 von mehreren Personen unabhängig voneinander: AnC und DatNLQ von VietSunshine Cyber Security, rekter0 und Anas cherni, Marcel Karlsson (whoismarcel) sowie Weston Ruter, Jon Surrell, Alex Concha und Luis Herranz vom WordPress Security Team. Welcher Melder welchen Teilbefund geliefert hat, geht aus dem Release-Post nicht hervor und ist offen.

Bindings greifen nach der Prüfung

Das Problem ist eine Frage der Reihenfolge: KSES prüft beim Speichern, die Interactivity API setzt Werte erst beim Ausgeben ein. Neu in der Attributprüfung von kses.php ist dieser Block:

/*
 * An Interactivity API binding replaces an attribute value when the content is rendered,
 * after KSES has checked it. Where KSES restricts attribute values on an element, only
 * bindings of attributes it allows there with any value are kept.
 */
if (
	str_starts_with( $name_low, 'data-wp-bind--' ) &&
	_wp_kses_directive_binds_value_restricted_attribute( $name_low, $allowed_attr )
) {

Ein Attribut wie data-wp-bind--href enthält für KSES nur einen harmlosen Verweis auf einen Zustand der Interactivity API, keinen echten Link. Den eigentlichen Wert setzt die Interactivity API erst beim Rendern ein, also nach der Prüfung. Aus dem Code lässt sich ableiten, dass ein Nutzer ohne unfiltered_html damit Attributwerte erzeugen konnte, die KSES direkt nie zugelassen hätte, ohne jemals ein verbotenes Attribut zu speichern.

Die Entscheidung treffen zwei neue Hilfsfunktionen, beide mit @since 7.1.4 und als privat markiert. _wp_kses_restricts_attribute_values() prüft, ob KSES auf dem jeweiligen Element überhaupt Attributwerte einschränkt, etwa über Regeln wie values oder value_callback. _wp_kses_directive_binds_value_restricted_attribute() prüft, ob das Binding genau ein solches eingeschränktes Attribut betrifft. Nur dann wird es verworfen.

foreach ( $bound_attributes as $attribute_name ) {
	if ( isset( $allowed_attributes[ $attribute_name ] ) ) {
		$rules = $allowed_attributes[ $attribute_name ];
	} elseif ( 1 === preg_match( '/^data-[a-z0-9_-]+$/', $attribute_name ) && isset( $allowed_attributes['data-*'] ) ) {
		$rules = $allowed_attributes['data-*'];
	} else {
		return true;
	}

Ein Binding bleibt also nur erhalten, wenn KSES das gebundene Attribut auf diesem Element ohnehin mit beliebigem Wert erlaubt.

Der object-Sonderfall

Für das HTML-Element object führt 7.1.4 eine eigene, strengere Regel ein. In wp-includes/interactivity-api/class-wp-interactivity-api.php entfernt WordPress beim Rendern jedes Binding, das ein nicht ausdrücklich erlaubtes Attribut eines object-Elements verändern würde:

/*
 * Remove a binding that would change an `object` attribute whose value KSES checks,
 * so that a client runtime without this check does not apply it either.
 */
if ( 'OBJECT' === $p->get_tag() && ! self::is_bindable_object_attribute( $entry['suffix'] ) ) {
	$p->remove_attribute( $entry['attribute_name'] );

Die neue Methode is_bindable_object_attribute() lässt auf einem object-Element nur noch diese Attribute zu: aria-*, data-* außer data-wp-* sowie class, dir, height, hidden, id, lang, role, style, tabindex, title und width.

Der Code-Kommentar begründet das selbst. KSES erlaubt ein object-Element im Beitragsinhalt nur nach Prüfung der Attribute data und type, und diese Prüfung kann für einen gebundenen Wert weder der Server noch der Client wiederholen. Daraus lässt sich ableiten, dass vor 7.1.4 über ein object-Element mit Binding das Attribut data veränderbar war, also genau das, was das Element lädt. Laut Kommentar wird ein data-wp-*-Attribut abgelehnt, weil es selbst eine Direktive ist, die nach dem Rendern wiederum data oder type binden könnte. Die JavaScript-Laufzeit im Browser setzt laut Kommentar dieselbe Liste durch.

Offen und zu prüfen bleibt, welche konkreten Elemente und Attribute außer object vom KSES-Bypass betroffen waren. Der Diff zeigt eine generische Regel für alle Elemente mit eingeschränkten Attributwerten, benennt aber keine Einzelfälle.

Warum das Mehrautoren-Sites besonders trifft

Die Vorbedingung ist ein Konto mit Schreibrecht auf Beitragsinhalte, also mindestens die Rolle Mitarbeiter oder Autor. Betroffen sind damit vor allem Websites, auf denen mehr als eine Person Inhalte anlegt.

Dazu zählen Redaktionen mit mehreren Autoren, Websites mit Gastbeiträgen, Membership-Plattformen und Multisite-Netzwerke. Besonders aufmerksam sollten Betreiber von Installationen sein, deren Plugins Formulareingaben in Beiträge oder Blockinhalte umwandeln, weil dort die Grenze zwischen Besucher und Autor verschwimmt.

Die Wirkungskette ist bei dieser Lückenklasse bekannt. Ein gespeichertes XSS, das im Browser eines Administrators ausgeführt wird, kann Aktionen in dessen Namen auslösen. Wo der Plugin- oder Theme-Editor erreichbar ist oder neue Administratorkonten angelegt werden können, endet das in Codeausführung auf dem Server. Wie Sie Rollen, Rechte und Editoren grundsätzlich absichern, beschreiben wir auf unserer Seite zur WordPress-Sicherheit.

Zwischenfazit: Wer Autoren, Mitarbeiter oder Gastbeiträge auf der Website hat, sollte den KSES-Fix genauso ernst nehmen wie die Upgrade-Lücke. Er betrifft deutlich mehr Websites.

Die weiteren Fixes im Diff

Neben den beiden schweren Funden enthält der Diff mehrere kleinere, aber lehrreiche Korrekturen. Die folgenden fünf lassen sich direkt im Code nachvollziehen.

Parser-Differential im Block-Parser

Release-Post Punkt 2, gemeldet von Rafie Muhammad (Awesome Motive, Inc.), betrifft einen „stored XSS with specially crafted block markup“. In wp-includes/class-wp-block-parser.php ändert sich genau eine Zeile, der reguläre Ausdruck, der Blockkommentare wie <!-- wp:paragraph --> erkennt. Gekürzt auf den Anfang:

// 7.1.3
'/<!--\s+(?P<closer>\/)?wp:(?P<namespace>[a-z][a-z0-9_-]*\/)?(?P<name>[a-z][a-z0-9_-]*)\s+ ...'

// 7.1.4
'/<!--[ \t\f\r\n]+(?P<closer>\/)?wp:(?P<namespace>[a-z][a-z0-9_-]*\/)?(?P<name>[a-z][a-z0-9_-]*)[ \t\f\r\n]+ ...'

Die allgemeine Zeichenklasse \s für Leerraum wurde an vier Stellen des Ausdrucks durch die explizite Liste [ \t\f\r\n] ersetzt. Das entspricht genau den Zeichen, die der HTML-Standard als Leerraum definiert: Leerzeichen, Tabulator, Seitenvorschub, Wagenrücklauf und Zeilenumbruch. Dieselbe Änderung findet sich im JavaScript-Parser des Block-Editors (block-serialization-default-parser.js).

Warum das eine Sicherheitslücke sein kann, lässt sich aus dem Code ableiten. \s umfasst je nach Sprache und Modus unterschiedliche Zeichen, etwa den vertikalen Tabulator oder in JavaScript zusätzlich Unicode-Leerzeichen. Der PHP-Parser auf dem Server, der JavaScript-Parser im Editor und der HTML-Parser des Browsers konnten denselben Kommentar damit unterschiedlich einordnen. Markup, das eine Seite für einen Blockkommentar hält und die andere nicht, umgeht Prüfungen, die nur auf einer Seite greifen.

Fachleute nennen dieses Muster Parser-Differential: Zwei Komponenten lesen dieselben Daten unterschiedlich, und die Sicherheitsprüfung sitzt in der falschen. Die Ursache liegt hier in einer einzigen Zeichenklasse. Der genaue Angriffsweg ist im Release-Post nicht beschrieben und bleibt offen.

Playlist-Block

Release-Post Punkt 10 nennt einen „Stored XSS in Playlist and image blocks“, gemeldet von Ben Bidner vom WordPress Security Team. In wp-includes/blocks/playlist.php sind 54 Zeilen geändert. Die alte Implementierung fügte den Player per regulärem Ausdruck in das HTML ein:

$figure = null;
preg_match( '/<figure[^>]*>/', $content, $figure );
if ( ! empty( $figure[0] ) ) {
	$content = preg_replace( '/(<figure[^>]*>)/', '$1' . $html, $content, 1 );
}

7.1.4 ersetzt das durch eine anonyme Klasse, die WP_HTML_Tag_Processor erweitert und das HTML per Bookmark exakt hinter dem tatsächlich gefundenen figure-Tag einfügt. Einfügen und Attribute setzen geschehen jetzt an derselben, vom HTML-Parser ermittelten Stelle und nur dann, wenn ein figure-Element gefunden wurde:

if ( $processor->next_tag( 'figure' ) ) {
	$processor->block_core_playlist_insert_after( $html );
	$processor->set_attribute( 'data-wp-interactive', 'core/playlist' );

Ein regulärer Ausdruck wie <figure[^>]*> versteht kein HTML. Er findet auch Zeichenfolgen, die gar kein echtes figure-Tag sind, und er endet beim ersten >, selbst wenn das innerhalb eines Attributwerts steht. Daraus schließen wir, dass Einfügeposition und tatsächliches Element auseinanderfallen konnten, auch das ein Parser-Differential. Nicht belegt ist dagegen die Annahme, dass Attribute auf einem fremden Element landeten: Der Tag-Prozessor setzt ohne gefundenes Tag keine Attribute. Welche Änderung in blocks/image.php zu Punkt 10 gehört, haben wir nicht im Detail analysiert.

Customizer-Changesets

Release-Post Punkt 9, gemeldet von Antonio Lorensius Silaban: Unveröffentlichte Customizer-Changesets konnten von nicht angemeldeten Besuchern eingesehen werden. In wp-includes/class-wp-customize-manager.php kommt eine Rechteprüfung hinzu:

- if ( ! $this->branching() && $this->is_theme_active() ) {
+ if ( ! $this->branching() && $this->is_theme_active() && current_user_can( 'customize' ) ) {

Der begleitende Code-Kommentar erklärt das Problem ungewöhnlich offen. Eine nicht authentifizierte Vorschau-Anfrage ohne UUID konnte das jüngste unveröffentlichte Changeset eines anderen Nutzers übernehmen und dessen Zustand offenlegen, weil die UUID als geheimer Schlüssel für die Vorschau dient. Seit 7.1.4 bekommen solche Anfragen eine neue UUID, die zu keinem Changeset passt.

Das ist reiner Informationsabfluss, aber ohne Anmeldung möglich. Relevant ist es für alle, die Relaunches, neue Designs oder noch nicht freigegebene Inhalte im Customizer vorbereiten.

Notizen

Release-Post Punkt 12, gemeldet von Ramon vom WordPress Security Team: Notizen konnten von privilegierten Nutzern gelesen werden, die keinen Bearbeitungszugriff auf den zugehörigen Beitrag haben. In class-wp-rest-comments-controller.php gilt für Notizen jetzt eine eigene Regel:

/*
 * Notes are editorial content, so require edit access to the note's post
 * rather than the moderate_comments capability.
 */
if ( 'note' === strtolower( $comment->comment_type ) ) {
	return current_user_can( 'edit_comment', $comment->comment_ID );
}

Bisher reichte das Recht moderate_comments, um Notizen über die REST-API zu lesen. Jetzt braucht es Bearbeitungsrechte am Beitrag. Niedrige Priorität, aber relevant für Redaktionen.

Root-Zertifikate

Release-Post Punkt 13 ist keine Lücke, sondern eine Aktualisierung der mitgelieferten Root-Zertifikate wegen des Widerrufs von eMudhra. Die Datei wp-includes/certificates/ca-bundle.crt wurde ausgetauscht.

Unser Abgleich der Zertifikatsnamen zeigt: Entfernt wurden unter anderem emSign Root CA - C1, emSign ECC Root CA - G3 und emSign ECC Root CA - C3 (emSign ist die Zertifikatsmarke von eMudhra) sowie ePKI Root Certification Authority und Atos TrustedRoot 2011. Neu hinzugekommen sind zwei SECOM- und zwei Telia-Wurzeln. Das Bundle enthält jetzt 118 statt 119 Zertifikate.

Das Bundle nutzt WordPress für ausgehende HTTPS-Verbindungen, etwa zu Update-Servern, Lizenz- oder Zahlungsdiensten. Welche Dienste der Widerruf praktisch betrifft, ist aus dem Diff nicht ableitbar und bleibt zu prüfen.

Die übrigen Fixes

Die restlichen Punkte des Release-Posts sind im Diff gepatcht, wir haben sie aber nicht im Detail analysiert:

• Stored XSS über Anträge auf Datenlöschung (Privacy Data Removal Requests), gemeldet von Anthropic.
• Stored DoS in der Interactivity API, gemeldet von Jon Surrell vom WordPress Security Team.
• Stored XSS im Customizer Selective Refresh, gemeldet von Rafie Muhammad (Awesome Motive, Inc.).
• Stored XSS im Kategorien-Block (blocks/categories.php), gemeldet von Ben Bidner vom WordPress Security Team.
• Stored XSS über speziell gestaltete Benutzernamen (User Logins), gemeldet von Anthropic. Dazu passen Änderungen an den Benutzerlisten-Tabellen, users.php, user-edit.php und admin-bar.php.
• Stored XSS in den Blöcken core/comments-pagination-next und core/comments-pagination-previous, gemeldet von Alex Concha vom WordPress Security Team.

Wie kritisch ist das wirklich

Nach Auswirkung ist WordPress 7.1.4 hoch einzustufen, nach Ausnutzbarkeit mittel. Zwei Funde sind Bausteine, an deren Ende Codeausführung stehen kann, aber keiner ist ein Angriff, der ohne jede Vorbedingung funktioniert.

Zur Auswirkung: Die Upgrade-Lücke kann nach unserer Analyse in eine dauerhafte Kontrolle über die Website münden. Der KSES-Bypass führt über gespeichertes XSS im Administratorkontext typischerweise zu denselben Folgen.

Zur Ausnutzbarkeit: Nichts im Diff deutet auf einen nicht authentifizierten Einzeiler hin. Der eine Fund braucht Schreibzugriff im Update-Fenster, der andere ein Konto mit mindestens Mitarbeiterrechten. Die einzige Lücke ohne Anmeldung, die Customizer-Changesets, ist reiner Informationsabfluss.

Die eigentliche Dringlichkeit kommt aus einer anderen Richtung. Der Diff ist öffentlich und lässt sich in wenigen Minuten aus zwei Release-Paketen erzeugen. WordPress hat bewusst keine technischen Details veröffentlicht, doch die Code-Kommentare im Patch beschreiben die Probleme teils sehr genau. Der Release ist damit selbst die Vorlage für jeden, der Angriffe entwickeln will. Nach unserer Einschätzung liegt das Zeitfenster bis zu ersten funktionierenden Angriffen eher bei Tagen als bei Wochen.

Zum Stand am 28. Oktober 2026: WordPress hat keine CVE-IDs und keine Schweregrade vergeben. In den Datenbanken von Patchstack und der NVD fanden wir zum Redaktionszeitpunkt keine Einträge zu 7.1.4, eine Advisory von Patchstack oder Wordfence lag uns nicht vor. Eine Ausnutzung ist nicht bekannt.

Zwischenfazit: Kein Grund zur Panik, aber ein klarer Grund, innerhalb von 24 bis 48 Stunden zu aktualisieren.

Wer ist betroffen

Betroffen sind alle WordPress-Installationen vor Version 7.1.4. Websites mit aktivierten automatischen Hintergrund-Updates werden automatisch versorgt, alle anderen müssen manuell aktualisieren.

Laut Release-Post werden die Fixes aus Kulanz in alle Branches zurückportiert, die noch Sicherheitsfixes erhalten, derzeit bis einschließlich 4.7. Die Backports laufen noch und erscheinen schrittweise, sobald sie fertig sind. Offiziell aktiv unterstützt ist nur die jeweils neueste Version. Wer auf einem älteren Branch bleibt, wartet also auf einen Backport, der zum Redaktionszeitpunkt noch nicht überall verfügbar ist. Welche Branches bereits versorgt sind, ist zu prüfen. Ob Ihre Umgebung PHP-Versionen und Update-Pfade für den aktuellen Zweig bietet, ist eine Frage an Ihr Hosting.

Die nächste Hauptversion WordPress 7.2 ist laut Release-Post für den 8. Dezember 2026 geplant. WordPress 7.2 Beta 3 ist gleichzeitig erschienen und enthält alle anwendbaren Fixes. Das ist kein Grund, 7.1.4 zu überspringen: Bis zum 8. Dezember vergehen sechs Wochen, in denen ungepatchte Installationen offen bleiben.

Sofortmaßnahmen

Diese acht Schritte sollten Sie jetzt umsetzen, in dieser Reihenfolge:

1. Version prüfen. Im Dashboard unter Werkzeuge und Website-Zustand oder per WP-CLI mit wp core version.
2. Auf 7.1.4 aktualisieren. Sites mit automatischen Hintergrund-Updates werden automatisch versorgt. Wenn Sie Updates nicht selbst einspielen möchten, übernimmt das unsere WordPress-Wartung.
3. Nach dem Update verifizieren, dass 7.1.4 aktiv ist. Wegen der Lücke im Update-Prozess selbst reicht ein unverifiziertes Update nicht. Prüfen Sie die Version erneut und stellen Sie sicher, dass wp-content/upgrade/ keine Altlasten enthält.
4. Objekt-Cache, Page-Cache und CDN leeren. Die Fixes an Interactivity API und Blöcken wirken beim Rendern. Bereits zwischengespeicherte Seiten werden dadurch nicht nachträglich bereinigt.
5. Benutzerliste prüfen. Achten Sie auf unbekannte Konten, besonders mit Administratorrechten.
6. Rollen und Rechte nachsehen. Bei Mehrautoren-Sites prüfen Sie, wer Beitragsinhalte und Blockmarkup speichern darf und ob alle diese Konten noch gebraucht werden.
7. Ausgehende Verbindungen testen. Falls nach dem Update Zertifikatsfehler bei Lizenzprüfungen, Zahlungsdiensten oder anderen Schnittstellen auftreten, hängt das möglicherweise mit dem neuen Zertifikats-Bundle zusammen.
8. Bei Verdacht nicht nur aktualisieren, sondern bereinigen lassen. Ein Update schließt die Lücke, entfernt aber keinen bereits eingeschleusten Code. Wenn Sie Anzeichen einer Kompromittierung sehen, hilft Ihnen unser Notfall-Service WordPress gehackt.

Einschätzung von CMS ADMINS

Die Upgrade-Lücke verschiebt die Perspektive auf Updates. Ein Update ist nicht automatisch der Moment, in dem eine Website sicher wird. Es ist ein Vorgang, der selbst abgesichert gehört, über Staging, Monitoring und eine Verifikation danach.

Für Agenturen mit vielen Kundeninstallationen wird der Unterschied genau hier messbar. Ein zentral gesteuerter Update-Prozess mit Prüfung nach jedem Lauf erkennt Abweichungen. 40 einzelne Dashboards, in denen jemand auf „Jetzt aktualisieren“ klickt, tun das nicht. Wie wir Agenturen dabei entlasten, beschreiben wir auf der Seite für Digital- und Marketing-Agenturen.

Parallel läuft mit PHP2Shell eine zweite Baustelle auf derselben Infrastruktur. Sie betrifft PHP selbst und nicht WordPress, beide Updates sind unabhängig voneinander nötig. Unsere Einordnung finden Sie im Beitrag zu PHP2Shell und den kritischen PHP-Sicherheitslücken.

FAQ

Was wurde in WordPress 7.1.4 behoben?

WordPress 7.1.4 vom 28. Oktober 2026 behebt 13 Sicherheitsprobleme. Darunter sind eine Schwäche im Update-Prozess mit möglicher Codeausführung, mehrere Stored-XSS-Lücken in der Interactivity API, im Block-Parser und in mehreren Blöcken, ein Informationsabfluss über Customizer-Changesets und ein Rechteproblem bei Notizen. Dazu kommt ein aktualisiertes Root-Zertifikats-Bundle wegen des eMudhra-Widerrufs. Das Release-Paket ändert 49 Dateien.

Wie kritisch ist die Lücke im Upgrade-Prozess wirklich?

Die Upgrade-Lücke in WordPress vor 7.1.4 hat hohen Impact, ist aber nur mittel ausnutzbar. Ein Angreifer bräuchte Schreibzugriff in das Arbeitsverzeichnis unter wp-content/upgrade/ während eines Updates, etwa über eine Schwäche in einem Plugin. Dann hätte er eine eigene wp-config.php vom Updater einspielen lassen können. Dringend ist das Update vor allem, weil der öffentliche Diff zwischen 7.1.3 und 7.1.4 die Schwachstelle offenlegt.

Reicht ein Update, oder muss ich danach noch etwas tun?

Ein Update auf WordPress 7.1.4 allein reicht nicht ganz. Prüfen Sie danach erstens, ob wirklich Version 7.1.4 aktiv ist, zweitens leeren Sie Objekt-Cache, Page-Cache und CDN, und drittens kontrollieren Sie die Benutzerliste auf unbekannte Administratorkonten. Bei Verdacht auf eine Kompromittierung sollte die Website zusätzlich bereinigt werden.

Gibt es CVE-Nummern und Schweregrade zu WordPress 7.1.4?

Nein, Stand 28. Oktober 2026 gibt es zu WordPress 7.1.4 keine CVE-Nummern und keine offiziellen Schweregrade. WordPress hat nur eine Kurzbeschreibung der 13 Punkte veröffentlicht, und eine Advisory von Patchstack oder Wordfence lag zum Redaktionszeitpunkt nicht vor. Das ist keine Entwarnung, sondern ein Zeitstand: CVE-Vergabe und Bewertung folgen erfahrungsgemäß oft erst Tage nach dem Release.

Welche Websites sind durch den KSES-Bypass besonders gefährdet?

Der KSES-Bypass in WordPress vor 7.1.4 gefährdet vor allem Websites, auf denen Nutzer mit den Rollen Mitarbeiter oder Autor Inhalte speichern. Dazu gehören Mehrautoren-Redaktionen, Websites mit Gastbeiträgen und Membership-Plattformen, außerdem Multisite-Netzwerke und Installationen mit Plugins, die Formulareingaben in Beiträge umwandeln. Über gespeichertes XSS im Browser eines Administrators kann der Angriff bis zur Codeausführung auf dem Server führen.

Was bedeutet der eMudhra-Zertifikatswiderruf für meine Website?

Der eMudhra-Widerruf betrifft das Root-Zertifikats-Bundle, das WordPress für ausgehende HTTPS-Verbindungen nutzt, nicht das SSL-Zertifikat Ihrer eigenen Website. WordPress 7.1.4 entfernt unter anderem drei emSign-Wurzeln von eMudhra und ergänzt neue Wurzeln von SECOM und Telia, insgesamt enthält das Bundle 118 Zertifikate. Treten nach dem Update Verbindungsfehler zu externen Diensten auf, sollten Sie die Zertifikatskette des betroffenen Dienstes prüfen lassen.

Fazit

Aktualisieren Sie Ihre WordPress-Installationen innerhalb von 24 bis 48 Stunden auf Version 7.1.4 und prüfen Sie danach, dass die neue Version tatsächlich aktiv ist. Leeren Sie anschließend alle Caches und kontrollieren Sie die Benutzerkonten. Bei Verdacht auf eine Kompromittierung lassen Sie die Website bereinigen, statt nur das Update einzuspielen. Wer Updates, Hosting und Daten dauerhaft unter eigener Kontrolle betreiben möchte, findet bei uns den Ansatz der digitalen Souveränität.

Quellen: WordPress 7.1.4 Release Post (28. Oktober 2026), WordPress 7.1.3 Release Post (6. Oktober 2026), eigener Vergleich der Release-Pakete wordpress-7.1.3.zip und wordpress-7.1.4.zip.