WordPress 7.1.4 & EU Cyber Resilience Act: Was die 22 geschlossenen Sicherheitslücken jetzt für Ihre Website bedeuten

1. Der heiße Sicherheits-Herbst 2026: Warum WordPress-Betreiber jetzt doppelt gefordert sind

Wer im Oktober und November 2026 eine Unternehmenswebsite auf Basis von WordPress betreibt, erlebt gerade eine sicherheitstechnische Ausnahmesituation, wie wir sie in über 15 Jahren Agenturpraxis selten gesehen haben: Kaum mussten Server-Administratoren Ende Oktober die kritische PHP-Laufzeitlücke „php2shell“ (CVE-2026-109618 & CVE-2026-109619) patchen, legte das offizielle WordPress-Core-Team kurz nach Version 7.1.3 am 28. Oktober 2026 mit dem Notfall- und Wartungs-Release WordPress 7.1.4 nach – und schloss auf einen Schlag 22 Sicherheitsmängel und Systemfehler.

Doch das eigentliche Erdbeben findet nicht allein im Programmcode statt, sondern im Zusammenspiel aus KI-gestützten Angriffs-Bots und einem neuen europäischen Gesetz, dessen erste scharfe Stufe seit September 2026 in Kraft ist: dem EU Cyber Resilience Act (CRA – Verordnung (EU) 2024/2847).

2. WordPress 7.1.4 im Detail: Diese 22 Sicherheitsmängel und Bugs wurden behoben

Nachdem Anfang Oktober bereits WordPress 7.1.3 erschienen war, stufte das WordPress-Sicherheitsteam Ende Oktober ein weiteres schnelles Punkt-Release (WordPress 7.1.4) als zwingend erforderlich ein. Insgesamt flossen 22 Korrekturen (12 Core-Tickets und 10 Block-Editor-/Gutenberg-Fixes) sowie mehrere direkte Security-Patches in die Veröffentlichung ein, die gleichzeitig bis in ältere Versionszweige rückportiert wurden.

Die geschlossenen Schwachstellen lassen sich in vier zentrale Risikobereiche unterteilen:

1. Race Condition im Core- & Plugin-Updater (High Severity): Eine Zeitfenster-Schwachstelle beim Entpacken und Kopieren von Aktualisierungspaketen im Verzeichnis /wp-content/upgrade/.
2. Cross-Site Scripting (Stored XSS) in wp_kses() und Block-Attributen: Fehlerhafte Bereinigung manipulierter HTML-Attribute und Shortcode-Parameter im Gutenberg-Editor.
3. Autorisierungs- & REST-API-Lecks (/wp-json/wp/v2/): Unzureichende Rechteprüfung bei bestimmten Metadaten-Abfragen und Passwort-Zurücksetzungs-Flows.
4. Stabilitäts- & PHP-8.4/8.5-Kompatibilitäts-Fixes: Behebung von Fehlern bei der Medienverarbeitung, den responsiven Block-Styles und der Vorbereitung auf das kommende Major-Release WordPress 7.2.

3. Besonders brisant: Die Race-Condition-Schwachstelle im WordPress-Update-Prozess

Unter allen in WordPress 7.1.4 geschlossenen Lücken sticht eine Schwachstelle besonders hervor, weil Sicherheitsforscher (unter anderem das Threat-Intelligence-Team von Wordfence) bereits unmittelbar nach Veröffentlichung des Patches massive automatisierte Angriffsversuche auf genau diesen Vektor registrierten: eine Race Condition im Update-Mechanismus.

Wie funktioniert eine „Race Condition“ (TOCTOU) beim WordPress-Update?

Wenn WordPress ein Plugin, ein Theme oder sich selbst aktualisiert, lädt der Server zunächst ein .zip-Archiv von wordpress.org herunter und entpackt die Dateien vorübergehend in den öffentlich im Webroot liegenden Ordner /wp-content/upgrade/<paketname>/. Dort prüft WordPress die Struktur (Time of Check), bevor es den alten Plugin-Ordner löscht und die neuen Dateien an die endgültige Stelle verschiebt (Time of Use).

• Das kritische Zeitfenster: Auf langsameren Shared-Hosting-Servern (insbesondere bei hoher I/O-Last, wie wir sie in unserem großen Webhosting-Test zu IONOS, Strato, All-Inkl & Hetzner gemessen haben) kann dieser Entpack- und Prüfvorgang bei großen Plugins wie WooCommerce oder Elementor mehrere Sekunden dauern.
• Der Angriff: In ungepatchten Versionen vor WordPress 7.1.4 konnten Angreifer dieses kurze Zeitfenster oder fehlerhaft gesetzte Dateiberechtigungen während eines laufenden (oder abgebrochenen) Update-Prozesses ausnutzen, um parallel gezielte HTTP-Anfragen an die temporären Upgrade-Pfade zu feuern, den Update-Prozess in einen inkonsistenten Zustand zu zwingen oder ungeschützte Initialisierungs-Skripte direkt aufzurufen.
• Der Patch in 7.1.4: WordPress 7.1.4 härtet die atomare Prüfung und Verzeichnis-Isolierung während des gesamten Entpack-Zyklus ab, sodass kein externer Zugriff auf halb entpackte Upgrade-Artefakte mehr möglich ist.

4. Stored XSS & wp_kses()-Umgehung: Wie Angreifer über harmlose Blöcke Schadcode einschleusen

Der zweite große Schwerpunkt in WordPress 7.1.4 (und auch ein Hauptthema für das kommende WordPress 7.2) betrifft die interne Sicherheitsfunktion wp_kses() („KSES Strips Evil Scripts“). Diese Funktion ist der zentrale Türsteher in WordPress: Immer wenn ein Kommentar, ein Formularfeld, ein Gastbeitrag oder ein Gutenberg-Block gespeichert wird, filtert wp_kses() gefährlichen JavaScript-Code (<script>, onload=, onerror=) heraus.

Was war das Problem vor Version 7.1.4?

Durch geschickt verschachtelte HTML-Entitäten und speziell formatierte CSS-/Block-Attribute gelang es Sicherheitsforschern, den Parser von wp_kses() auszutricksen. Das Ergebnis ist sogenanntes Stored Cross-Site Scripting (Stored XSS):

1. Ein Angreifer schleust über ein kompromittiertes Autoren-Konto, eine Kommentar-Funktion oder ein Drittanbieter-Formular-Plugin einen präparierten Textbaustein in die WordPress-Datenbank ein.
2. wp_kses() erkennt den versteckten Payload in der ungepatchten Version nicht und speichert ihn als vermeintlich harmlosen Formatierungs-Code ab.
3. Sobald Sie sich als Administrator ins WordPress-Backend einloggen und den Beitrag oder die Übersicht betrachten, wird das versteckte JavaScript im Kontext Ihrer Administrator-Sitzung im Browser ausgeführt – und legt im Hintergrund unbemerkt ein neues Admin-Konto für den Angreifer an oder schreibt eine Backdoor in den Theme-Editor!

5. Übersichtstabelle: Alle kritischen Komponenten in WordPress 7.1.4 & Rückportierungen

Damit Sie die Auswirkungen auf Ihr System auf einen Blick einschätzen können, haben wir die wichtigsten Sicherheits- und Wartungsbereiche von WordPress 7.1.4 zusammengefasst:

6. EU Cyber Resilience Act (CRA): Was die seit September 2026 geltende 24-Stunden-Meldepflicht verändert

Warum erscheinen Sicherheitsupdates für WordPress, PHP und Plugins im Herbst 2026 plötzlich in einer so atemberaubenden Taktfrequenz? Ein wesentlicher Grund liegt in Brüssel: Mit dem EU Cyber Resilience Act (CRA – Verordnung (EU) 2024/2847) hat die Europäische Union das schärfste IT-Sicherheitsgesetz für Software und digitale Produkte weltweit geschaffen.

Während die allgemeinen CE-Kennzeichnungs- und Designpflichten des CRA eine Übergangsfrist bis Dezember 2027 haben, ist die entscheidende erste Stufe bereits seit dem 11. September 2026 rechtsverbindlich in Kraft: die 24-Stunden-Meldepflicht nach Artikel 14 CRA!

Was besagt Artikel 14 des Cyber Resilience Act konkret?

• Frühwarnung binnen 24 Stunden: Jeder Hersteller eines „Produkts mit digitalen Elementen“, das auf dem europäischen Markt kommerziell bereitgestellt wird (wozu neben Betriebssystemen und Routern auch kommerzielle WordPress-Plugins, Pro-Themes, WooCommerce-Erweiterungen und Agentur-Software gehören!), muss eine aktiv ausgenutzte Schwachstelle innerhalb von 24 Stunden nach Kenntnisnahme über die zentrale Meldeplattform der ENISA sowie an das zuständige nationale CSIRT (in Deutschland das BSI) melden.
• Vollständige Schwachstellenmeldung binnen 72 Stunden: Innerhalb von drei Tagen müssen detaillierte technische Informationen zur Schwachstelle und zu den ergriffenen Abhilfemaßnahmen (Patches) nachgereicht werden.
• Information der Nutzer: Gleichzeitig sind Hersteller gesetzlich verpflichtet, ihre Nutzer unverzüglich und transparent über das Sicherheitsrisiko und das bereitgestellte Sicherheitsupdate zu informieren.

Für die Open-Source-Community (wie den nicht-kommerziellen WordPress-Core selbst) gelten im CRA zwar Privilegierungen für gemeinnützige Open-Source-Stewards – doch fast jedes zweite populäre WordPress-Plugin (Elementor Pro, WP Rocket, Yoast Premium, Gravity Forms, ACF Pro, Germanized Pro, Borlabs Cookie, Real Cookie Banner) wird von einem kommerziellen Unternehmen mit Gewinnerzielungsabsicht vertrieben und fällt damit voll unter die neuen Transparenz- und Meldeprozesse!

7. KI-Patch-Diffing: Warum zwischen Update-Release und Hack-Welle heute nur noch 4 Stunden liegen

So richtig und wichtig der EU Cyber Resilience Act für ehrliche Transparenz ist: Für kleine und mittlere Unternehmen (KMU), die ihre Website „nebenbei“ betreuen, hat die neue Transparenz in Kombination mit moderner Künstlicher Intelligenz einen gefährlichen Nebeneffekt.

Noch vor drei oder vier Jahren galt im Website-Betrieb eine entspannte Faustregel: Wenn mittwochs ein WordPress- oder Plugin-Update erschien, dauerte es oft ein bis zwei Wochen, bis Hacker den Fehler analysiert und erste Angriffs-Skripte programmiert hatten. Wer einmal im Monat seine Updates einspielte, kam meistens mit einem blauen Auge davon.

Im November 2026 ist diese Komfortzone endgültig Geschichte:

1. In der Sekunde, in der ein neues Sicherheitsupdate wie WordPress 7.1.4 oder ein Plugin-Patch im öffentlichen GitHub- oder SVN-Repository veröffentlicht wird, laden automatisierte Bots von Cyberkriminellen den alten und den neuen Programmcode herunter.
2. Spezialisierte Large Language Models (LLMs) führen ein sogenanntes KI-Patch-Diffing durch: Die KI vergleicht die geänderten Codezeilen, erkennt in unter 90 Sekunden, welcher Sicherheitsfehler dort geschlossen wurde (z. B. die fehlende Prüfung im Updater oder in wp_kses()), und schreibt vollautomatisch den passenden Angriffs-Code (Exploit).
3. Schon 2 bis 4 Stunden nach Erscheinen des Updates scannen zehntausende verteilte Server weltweit das gesamte Internet nach Websites, auf denen noch die alte Versionsnummer läuft!

8. NIS-2-Umsetzungsgesetz & Art. 32 DSGVO: Wann haften Geschäftsführer persönlich für veraltete Websites?

Spätestens an dieser Stelle wird aus dem technischen Update-Thema ein handfestes juristisches Chef-Thema. Denn wer im Jahr 2026 eine gewerbliche Website betreibt, unterliegt in Deutschland gleich mehreren gesetzlichen Sorgfaltspflichten:

• 1. Art. 32 DSGVO (Sicherheit der Verarbeitung nach dem Stand der Technik): Dieser Artikel gilt für jedes Unternehmen – vom Solo-Selbstständigen über die Zahnarztpraxis bis zur mittelständischen GmbH –, sobald über die Website personenbezogene Daten (IP-Adressen, Kontaktformulare, Bewerbungen, Terminbuchungen) erfasst werden. Wird Ihre Website über eine seit Wochen bekannte WordPress- oder PHP-Lücke gehackt, werten Datenschutzbehörden das Nicht-Einspielen von Sicherheitsupdates regelmäßig als Verstoß gegen Art. 32 DSGVO.
• 2. NIS-2-Umsetzungsgesetz (BSIG-neu): Für rund 30.000 deutsche Unternehmen in wichtigen und besonders wichtigen Sektoren (und über die Lieferketten-Anforderungen indirekt auch für deren IT-Dienstleister, Zulieferer und Agenturen!) schreibt NIS-2 ein lückenloses Schwachstellen-Management und unverzügliches Patching gesetzlich vor – verbunden mit einer ausdrücklichen, nicht delegierbaren Organisations- und Haftungspflicht der Geschäftsführung.
• 3. Verlust des Cyber-Versicherungsschutzes: Haben Sie für Ihr Unternehmen eine Betriebshaftpflicht- oder Cyber-Versicherung abgeschlossen? Fast jede moderne Cyber-Police enthält in den Versicherungsbedingungen eine Patch-Obliegenheitsklausel: Werden kritische Sicherheitsupdates nicht innerhalb einer definierten Frist (oft 7 bis 14 Tage) eingespielt, kann der Versicherer die Übernahme der Forensik-, Wiederherstellungs- und Schadensersatzkosten wegen grober Fahrlässigkeit kürzen oder komplett verweigern!

9. Ausblick auf WordPress 7.2 (Dezember 2026): Welche Neuerungen jetzt vor der Tür stehen

Während WordPress 7.1.4 die aktuellen Sicherheitslücken abdichtet, laufen im Hintergrund bereits die letzten Vorbereitungen für das letzte große Funktions-Update des Jahres: WordPress 7.2.

Nach der Veröffentlichung der Beta 1 am 20. Oktober 2026 und den Release Candidates im November ist das finale Release von WordPress 7.2 für Anfang Dezember 2026 terminiert. Auf diese technischen Neuerungen sollten Sie und Ihre Agentur vorbereitet sein:

• Grundlegende Überarbeitung der wp_kses()-Architektur: Um zukünftige XSS-Umgehungen konstruktiv auszuschließen, modernisiert WordPress 7.2 das Zusammenspiel zwischen der HTML-API (HTML Tag Processor) und der Inhaltsbereinigung. Ältere Plugins, die eigene unsaubere Shortcodes oder ungefilterte Inline-Skripte in Blöcke injizieren, müssen vor dem Update auf 7.2 zwingend auf Kompatibilität geprüft werden.
• Erweiterte responsive Design-Steuerelemente für Blöcke: Im Site-Editor (Full Site Editing) bringt WordPress 7.2 endlich feinere native Einstellmöglichkeiten für Abstände, Typografie und Sichtbarkeiten auf Mobilgeräten und Tablets, ohne dass dafür eigene CSS-Klassen geschrieben werden müssen.
• Verbesserte Template-Verwaltung & DataViews: Die bereits in den Vorversionen eingeführte moderne Listen- und Tabellenansicht (DataViews) im Admin-Bereich wird weiter ausgebaut und beschleunigt die Verwaltung großer Seiten- und Medienbestände spürbar.
• Volle Optimierung auf PHP 8.4 & PHP 8.5: WordPress 7.2 bereinigt weitere veraltete Funktionsaufrufe (Deprecations), um unter den aktuellsten, gegen php2shell gehärteten PHP-Versionen (8.4.27+ und 8.5.12+) mit maximaler Geschwindigkeit zu laufen.

10. Das 3-Schichten-Sicherheitsmodell: Warum WordPress 7.1.4 UND das PHP-Update zusammengehören

Wenn Sie unsere letzten drei großen Technik-Analysen im Zusammenhang betrachten, erkennen Sie sofort, warum Website-Sicherheit im Jahr 2026 niemals nur an einer einzigen Schraube gedreht werden kann. Eine sichere Unternehmenswebsite ruht immer auf drei untrennbaren Säulen:

11. Praxis-Anleitung: So spielen Sie WordPress 7.1.4 fehlerfrei ein (Auto-Update vs. Staging)

Wie stellen Sie sicher, dass Ihre Website noch heute auf WordPress 7.1.4 läuft, ohne dass es zu Darstellungsfehlern kommt?

1. Versionsstand im Dashboard prüfen: Loggen Sie sich unter /wp-admin/ ein und schauen Sie unten rechts in die Fußzeile des Admin-Bereichs oder unter Dashboard → Aktualisierungen. Steht dort bereits Version 7.1.4, hat das automatische Hintergrund-Update für Minor-Releases bereits gegriffen.
2. Falls Auto-Updates deaktiviert sind (z. B. durch WP_AUTO_UPDATE_CORE in der wp-config.php oder durch ein Sicherheits-Plugin): Erstellen Sie zunächst ein vollständiges Datenbank- und Datei-Backup.
3. Zuerst Plugins aktualisieren, dann den WordPress-Core: Aktualisieren Sie vor oder unmittelbar mit dem Core-Update auch Ihre eingesetzten Page-Builder (Elementor, Divi, WPBakery) und Sicherheitsplugins, damit keine Konflikte mit den verschärften wp_kses()-Regeln auftreten.
4. Upload- & Upgrade-Verzeichnis aufräumen: Prüfen Sie per FTP oder Dateimanager den Ordner /wp-content/upgrade/. Dieser Ordner muss im Normalzustand (wenn gerade kein Update läuft) komplett leer sein! Liegen dort noch alte, abgebrochene Unterordner aus früheren Monaten, löschen Sie diese sofort, um jegliche Angriffsfläche für die in 7.1.4 behobene Race Condition restlos zu beseitigen.

12. Ehrliche Systemfrage: Braucht Ihr Unternehmen diesen endlosen Update-Marathon überhaupt?

Lassen Sie uns an dieser Stelle die wichtigste strategische Frage für jedes kleine und mittlere Unternehmen stellen:

Wenn WordPress allein im Oktober 2026 zwei Sicherheits-Releases (7.1.3 und 7.1.4 mit 22 Fixes) brauchte, im Dezember schon WordPress 7.2 folgt und parallel jede Woche neue Plugin- und PHP-Lücken gemeldet werden – warum tut sich ein normaler Handwerksbetrieb, eine Arztpraxis, eine Kanzlei oder ein lokales Dienstleistungsunternehmen diesen Dauerstress überhaupt an?

Die ehrliche Antwort lautet: Aus reiner Gewohnheit! Weil viele traditionelle Agenturen jede noch so kleine 5-Seiten-Firmenwebsite blind mit WordPress und 25 Plugins zusammenklicken – und den Kunden danach mit der monatlichen Update-Lawine allein lassen.

Jetzt wartungsfreie Website oder WordPress-Betreuung im Kostenrechner kalkulieren

13. 10-Punkte-Sicherheits-Checkliste für den Jahresendspurt 2026

Mit diesen 10 Prüfpunkten machen Sie Ihre Website im November und Dezember 2026 unangreifbar für automatisierte Botnetze und erfüllen gleichzeitig alle Sorgfaltspflichten nach DSGVO und CRA/NIS-2:

1. WordPress-Version kontrollieren: Prüfen, dass mindestens WordPress 7.1.4 (bzw. das neueste Sicherheits-Release Ihres Zweigs) installiert ist.
2. Ordner /wp-content/upgrade/ leeren: Sicherstellen, dass keine verwaisten temporären Entpack-Ordner aus alten Update-Vorgängen auf dem Server liegen.
3. PHP-Version auf Ende-Oktober-Patch heben: Kontrollieren, dass auf Server-Ebene mindestens PHP 8.4.27 oder PHP 8.3.36 aktiv ist (Schutz gegen php2shell).
4. Inaktive Plugins & Standard-Themes löschen: Jedes ungenutzte Plugin und jedes alte Standard-Theme (bis auf ein einziges Fallback-Theme) komplett vom Server entfernen.
5. Benutzerkonten & Autoren-Rechte prüfen: Alte Redakteurs-, Autoren- oder Agentur-Zugänge löschen, die nicht mehr benötigt werden (Schutz vor wp_kses()-Privilege-Escalation).
6. Zwei-Faktor-Authentifizierung (2FA) für alle Admins aktivieren: Kein Administrator-Login ohne zweiten Faktor oder Passkey.
7. Automatische Minor-Updates aktiv halten: Sicherstellen, dass in der wp-config.php Sicherheits-Zwischenupdates (wie 7.1.3 → 7.1.4) nicht durch WP_AUTO_UPDATE_CORE = false blockiert werden, sofern keine tägliche Agentur-Wartung besteht.
8. Externe tägliche Backups prüfen: Ein Backup, das im selben /wp-content/-Ordner liegt wie die Website selbst, wird bei einem Hack vom Angreifer sofort mitgelöscht! Backups gehören zwingend auf einen externen Speicher.
9. Vorbereitung auf WordPress 7.2 (Anfang Dezember 2026): Vor dem großen Major-Update im Dezember prüfen, ob alle eingesetzten Custom-Blöcke und Plugins mit den verschärften wp_kses()-Regeln von WordPress 7.2 kompatibel sind.
10. Verantwortlichkeit klar regeln: Entscheiden Sie sich bewusst zwischen einer wartungsfreien Highspeed-Website im All-Inclusive-Mietmodell oder einer fest betreuten WordPress-Wartung durch Hauptstadt Homepage.

14. Häufig gestellte Fragen (FAQ zu WordPress 7.1.4, WordPress 7.2 & EU Cyber Resilience Act)