WordPress-Version prüfen und Sicherheitsupdate sicher einspielen: Ablauf für Unternehmen

Die Meldung kommt oft montags morgens: WordPress hat ein neues Sicherheitsupdate veröffentlicht, die Fachpresse schreibt von einer kritischen Lücke, und die Website läuft noch auf der alten Version. Wer eine Standard-Installation ohne individuelle Anpassungen betreibt, klickt auf „Aktualisieren" und ist fertig. Wer aber ein Theme verwendet, das ein Agentur vor drei Jahren gebaut hat, WooCommerce-Erweiterungen mit individuellen Zahlungsflüssen einsetzt oder ein Kontaktformular nutzt, das an ein CRM angebunden ist, steht vor einer anderen Frage: Wie spiele ich das WordPress Sicherheitsupdate ein, ohne dass danach die Website oder der Shop nicht mehr funktioniert?

Dieser Artikel beschreibt den vollständigen Ablauf — von der Versionsprüfung über das Backup bis zum Funktionstest. Er erklärt außerdem, was hinter den aktuellen Sicherheitslücken steckt, warum automatische Updates allein keine vollständige Antwort sind und wann eine Website auf einem nicht mehr unterstützten Versionszweig dringend geprüft werden sollte.

---

Warum das Update vom 28. Oktober 2026 nicht aufgeschoben werden sollte

Am 28. Oktober 2026 hat WordPress Version 7.1.4 veröffentlicht. Das Release behebt laut offizieller WordPress-Dokumentation 22 Sicherheitslücken. Die schwerste davon — CVE-2026-119977, gemeldet von Umut Bayram — betrifft den Update-Prozess selbst.

Konkret: Beim Core-Update mit dem vollständigen Paket entpackt WordPress die neuen Dateien in ein Verzeichnis unterhalb von wp-content/upgrade/, dessen Name vorhersagbar ist und das auf vielen Servern aus dem Web erreichbar ist. Dieses temporäre Verzeichnis enthält eine Kopie des WordPress-Installers. Ein nicht angemeldeter Angreifer, der genau in diesem Moment zugreift, kann unter bestimmten Voraussetzungen bis zur Ausführung von PHP-Code gelangen.

Die Einschätzung zur Schwere der Lücke ist uneinheitlich — das sollte man so stehen lassen:

Quelle	Einstufung
Wordfence (CNA)	CVSS 3.1 Basiswert 8.1 „High" (AV:N/AC:H/PR:N/UI:N)
WordPress GitHub Advisory (GHSA-4w3m-c66w-69mg)	„Low", keine CVE
NVD (Stand 03.11.2026)	Status „Deferred", keine eigene Bewertung

Die Angriffskomplexität ist hoch: Das Zeitfenster bestand in Laborumgebungen laut Wordfence nur Sekunden. Nötig sind ein Update mit dem Vollpaket, öffentlicher Web- und PHP-Zugriff auf das Staging-Verzeichnis sowie ein vorhersagbarer oder gefundener Pfad. Patchstack hält die Lücke für nicht praktikabel ausnutzbar, weist aber darauf hin, dass sich das Fenster bei jedem Update öffnet — auch bei unbeaufsichtigten automatischen Updates — und dass der betroffene Code auf WordPress 2.8 zurückgeht.

Wordfence hat laut eigener Angabe am 28. Oktober 2026 ab 20:30 UTC eine Firewall-Regel für Premium-Kunden ausgerollt. In den ersten 21 Stunden registrierte Wordfence mehr als 18.500 Anfragen auf Pfade des zwischengespeicherten Installers. Bestätigte erfolgreiche Angriffe nennt Wordfence nicht. Die kostenlose Wordfence-Version erhält die Regel erst am 27. November 2026.

Ebenfalls relevant: Nur wenige Wochen zuvor, am 22. September 2026, hatte WordPress mit Version 7.1.2 eine als kritisch eingestufte Pfad-Traversal-Lücke (CVE-2026-87902, CVSS v4.0: 9.2) geschlossen. Diese Lücke wurde von CISA am 25. September 2026 in den Katalog der bekannt ausgenutzten Schwachstellen (KEV) aufgenommen. Wer heute auf 7.1.4 aktualisiert, schließt beide Lücken gleichzeitig — falls er noch auf einer älteren Version läuft.

Das CERT-FR hat am 29. Oktober 2026 die Meldung CERTFR-2026-AVI-1420 veröffentlicht und unter anderem Codeausführung aus der Ferne als Risiko genannt.

---

WordPress-Version prüfen: Wo und wie

Bevor ein Update eingespielt wird, muss klar sein, auf welcher Version die Website läuft. Der schnellste Weg führt ins WordPress-Dashboard unter Dashboard → Aktualisierungen. Dort zeigt WordPress die installierte Version und — sofern ein Update verfügbar ist — die aktuelle Version an.

Alternativ findet sich die Version in der Datei wp-includes/version.php in der Variable $wp_version. Wer keinen Datei-Zugriff hat, kann die Version oft auch über das Quellcode-Tag <meta name="generator" content="WordPress X.X.X" /> erkennen, sofern dieser Tag nicht manuell entfernt wurde. Für Sicherheitszwecke empfiehlt es sich, diesen Tag zu entfernen, damit die Versionsangabe nicht öffentlich lesbar ist.

Welche Backport-Version passt zu Ihrer Installation?

WordPress unterstützt aktiv nur die jeweils neueste Version. Backports für ältere Zweige sind ein Entgegenkommen, keine zugesagte Leistung. Für das Release vom 28. Oktober 2026 (CVE-2026-119977) wurden folgende Backport-Versionen veröffentlicht:

Zweig	Gepatchte Version
7.1	7.1.4
7.0	7.0.8
6.9	6.9.11
6.8	6.8.12
6.7	6.7.11
6.6	6.6.11
6.5	6.5.14
6.4	6.4.14
6.3	6.3.14
6.2	6.2.15
6.1	6.1.16
6.0	6.0.18
5.x	z. B. 5.9.20 bis 5.0.31
4.9–4.7	z. B. 4.9.35, 4.8.34, 4.7.39

WordPress 4.6 und älter erhalten keine Sicherheitsupdates mehr. Läuft eine Website auf einem dieser Zweige, schützt kein Patch mehr — dort ist ein vollständiges Upgrade auf einen unterstützten Zweig notwendig, was eine eigene Planung erfordert.

---

Automatische Hintergrund-Updates: zuverlässig, aber nicht unkritisch

WordPress kann Minor-Updates — dazu gehören Sicherheitsreleases — automatisch im Hintergrund einspielen. Für viele Standard-Websites ist das die richtige Einstellung: Sie schließt Lücken, ohne dass jemand eingreifen muss.

Das Problem beginnt, wenn niemand prüft, ob das Update tatsächlich durchgelaufen ist. Häufige Ursachen dafür, dass automatische Updates stillschweigend scheitern: Dateirechte auf dem Server lassen keine Änderungen zu, ein Cache-Plugin blockiert den Update-Prozess, oder ein Hosting-Provider hat Schreibrechte eingeschränkt. Das Ergebnis ist eine Website, die aussieht als wäre sie aktuell, es aber nicht ist.

Wer sich auf automatische Updates verlässt, sollte deshalb nach jedem Sicherheitsrelease kurz im Dashboard unter Dashboard → Aktualisierungen prüfen, ob die aktuelle Version tatsächlich installiert ist. Ein Blick in die Update-Logs des Servers — sofern zugänglich — gibt zusätzliche Sicherheit.

Ein weiterer Aspekt: Die oben beschriebene Race-Condition-Lücke (CVE-2026-119977) öffnet ihr Zeitfenster auch bei automatischen Updates. Eine Firewall auf Plugin-Ebene (wie Wordfence) wirkt in diesem Fall laut Wordfence nur mit „Extended Protection" (vorgelagerter Schutz), weil die Anfrage direkt eine PHP-Datei aufruft, ohne WordPress zu laden.

---

Der sichere Ablauf: WordPress Sicherheitsupdate einspielen

Schritt 1: Ist-Zustand dokumentieren

Bevor irgendetwas verändert wird, lohnt sich ein kurzes Protokoll: Welche WordPress-Version läuft? Welche Plugins und Themes sind aktiv und in welcher Version? Ein Screenshot der Versionsliste unter Dashboard → Aktualisierungen reicht als Ausgangspunkt. Wer regelmäßig aktualisiert, hat diesen Stand ohnehin in einem Deployment-Log.

Schritt 2: Vollständiges Backup erstellen

Ein Backup vor dem Update ist keine Vorsichtsmaßnahme für Vorsichtige — es ist die Grundlage für einen kontrollierten Rollback. Das Backup muss zwei Bestandteile umfassen:

• Datenbankexport (alle WordPress-Tabellen, idealerweise als SQL-Dump)
• Vollständige Dateisicherung (WordPress-Kern, wp-content mit Themes, Plugins, Uploads)

Das Backup muss auf einem externen Speicher liegen, nicht nur auf demselben Server. Liegt das Backup nur auf dem Webserver, ist es bei einem Serverausfall nach dem Update wertlos.

Plugins wie UpdraftPlus, BackupBuddy oder All-in-One WP Migration können Backups direkt in Cloud-Speicher (Google Drive, S3, FTP) übertragen. Professionelle Hosting-Umgebungen bieten serverseitige Snapshots an, die unabhängig vom WordPress-Plugin-System arbeiten.

Wichtig für CVE-2026-119977: Wordfence empfiehlt außerdem, den Webzugriff auf wp-content/upgrade/ auf Webserver-Ebene zu sperren und sicherzustellen, dass das Verzeichnis nicht auflistbar ist. Das lässt sich in der .htaccess (Apache) oder in der Nginx-Konfiguration umsetzen und ist unabhängig vom Update-Ablauf eine sinnvolle Härtungsmaßnahme.

Schritt 3: Staging-Umgebung nutzen — bei individuell angepassten Websites

Für eine Standard-WordPress-Installation mit einem öffentlichen Theme und üblichen Plugins ist das Staging optional, aber empfohlen. Für eine individuell angepasste Website — eigenes Theme, maßgeschneiderte Plugins, WooCommerce mit angepassten Zahlungsflüssen, Formulare mit CRM-Anbindung — ist eine Staging-Umgebung praktisch obligatorisch.

Eine Staging-Umgebung ist eine 1:1-Kopie der Produktivwebsite auf einem separaten Server oder Subdomain, die für Besucher nicht erreichbar ist. Das Update wird zunächst dort eingespielt und getestet.

Wichtig: Die Staging-Umgebung muss aktuell sein. Wer auf einem veralteten Stand testet, testet nicht die Situation, die er auf der Produktivwebsite antreffen wird. Viele Hosting-Anbieter (z. B. Raidboxes, Kinsta, WP Engine) bieten eingebettete Staging-Funktionen an, mit denen sich die Produktivumgebung per Knopfdruck klonen lässt.

Schritt 4: Update einspielen

Auf der Staging-Umgebung (oder direkt auf der Produktivseite bei einfachen Installationen) wird das Update eingespielt:

1. Dashboard → Aktualisierungen aufrufen
2. WordPress-Core-Update auswählen und bestätigen
3. Warten, bis der Prozess abgeschlossen ist — kein Fenster schließen
4. Versionsanzeige prüfen: Stimmt sie mit der gepatchten Version überein?

Wer den Update-Prozess per WP-CLI oder über das Hosting-Panel auslöst, erhält in der Regel aussagekräftigere Logs als über das Dashboard-Interface.

Schritt 5: Funktionstest wichtiger Wege

Nach dem Update muss geprüft werden, ob die Website noch korrekt funktioniert. Das ist kein vollständiger QA-Test aller Seiten, sondern ein gezielter Check der geschäftskritischen Wege:

• Kontaktformular: Formular ausfüllen, absenden, prüfen ob die Bestätigungs-E-Mail ankommt und ob ein Eintrag im CRM erscheint
• Shop / WooCommerce: Produkt in den Warenkorb legen, Checkout durchlaufen (Testzahlung), Bestellbestätigung prüfen
• Login-Bereiche: Mitglieder- oder Kundenbereiche aufrufen, Login testen
• Wichtige Formularintegrationen: Newsletter-Anmeldung, Terminbuchungs-Widget o. Ä.
• Visuelle Prüfung auf mobilen Geräten: Gelegentlich erzeugt ein Core-Update minimale CSS-Änderungen, die zusammen mit einem individuellen Theme unerwartete Darstellungsprobleme erzeugen

Treten Fehler auf, wird das Update auf der Staging-Umgebung untersucht und nicht auf der Produktivwebsite eingespielt.

Schritt 6: Update auf Produktivwebsite übertragen und dokumentieren

Wurden alle Tests auf der Staging-Umgebung bestanden, wird das Update auf der Produktivwebsite nachgezogen — idealerweise in einem Wartungsfenster mit geringem Traffic. Nach dem Update auf Produktiv: denselben Funktionstest erneut durchführen.

Abschließend wird der Vorgang dokumentiert: Datum, eingespieltes Update, getestete Funktionen, Ergebnis, Name der Person. Diese Dokumentation ist bei späteren Supportfällen hilfreich und zeigt gegenüber Kunden, Partnern oder Versicherungen, dass Updates strukturiert behandelt werden.

---

Praxisbeispiel: Update-Ablauf für einen WooCommerce-Shop

Hypothetisches Beispiel zur Veranschaulichung:

Ein mittelständischer Händler betreibt einen WooCommerce-Shop mit einem individuellen Theme, das seine Agentur 2023 entwickelt hat. Die Shop-Software ist an ein ERP-System angebunden. Nach Veröffentlichung von WordPress 7.1.4 prüft der verantwortliche IT-Mitarbeiter das Dashboard: Die Website läuft noch auf 7.1.1.

Da das Theme individuell angepasst ist, entscheidet er sich für einen Staging-Test. Das Hosting-Panel erlaubt einen Staging-Clone per Klick. Das Update wird auf Staging eingespielt. Beim Funktionstest stellt er fest, dass das Kontaktformular im Checkout nach dem Update keine Bestätigungs-E-Mail mehr sendet — ein Konflikt mit einem Formular-Plugin, das selbst noch nicht auf die neue Core-Version aktualisiert wurde.

Er hält das Plugin-Update an, informiert den Plugin-Anbieter und spielt zunächst nur das Core-Update ein. Der Checkout-Funktionstest läuft sauber durch. Das Update wird auf Produktiv übertragen. Das Plugin-Problem wird separat verfolgt. Die gesamte Dokumentation dauert 30 Minuten — der geregelten Vorbereitung wegen.

Ohne Staging wäre das Formular-Problem direkt auf der Produktivwebsite aufgetaucht, bei laufendem Betrieb.

---

Was nach dem Update noch zu tun ist

Konten und Zugriffsberechtigungen prüfen

Für CVE-2026-119977 empfehlen Wordfence und Patchstack, Konten mit Mitarbeiter-Rechten oder höher zu überprüfen. Viele WordPress-Installationen haben im Laufe der Zeit Konten angesammelt, die nicht mehr aktiv genutzt werden. Nach einem Sicherheitsrelease ist ein guter Zeitpunkt, die Benutzerliste unter Benutzer → Alle Benutzer durchzugehen und inaktive Konten zu deaktivieren oder zu löschen.

Nach Hinweisen auf vorherige Kompromittierung suchen

Wer das Update verspätet einspielt oder nicht sicher ist, ob automatische Updates durchgelaufen sind, sollte nach den von Wordfence beschriebenen Indikatoren suchen:

• Unerwartete Zugriffe auf PHP-Dateien unter wp-content/upgrade/ in den Server-Logs
• Unbekannte Administratorkonten
• Unerwartete oder unbekannte Plugins
• Fremde PHP-Dateien im wp-content-Verzeichnis

Das ist keine vollständige Forensik, aber ein erster Hinweis-Check, der sich in wenigen Minuten durchführen lässt.

Update der Backport-Versionen 5.x und 4.7–4.9

Wer auf einem älteren Zweig wie 5.x oder 4.9.x läuft, erhält mit den Backport-Versionen denselben Patch. Das Update-Verfahren ist identisch. Jedoch sollte ein Upgrade auf einen aktuellen Hauptzweig mittelfristig eingeplant werden — Backports sind ein Entgegenkommen, keine dauerhafte Lösung.

WordPress 4.6 und älter: kein Patch verfügbar

Läuft eine Website noch auf WordPress 4.6 oder älter, gibt es für CVE-2026-119977 keinen Patch. Die einzige Lösung ist ein vollständiges Upgrade auf einen unterstützten Zweig. Das erfordert eine eigene Planung, weil solche Installationen oft stark veraltete Plugins und Themes mitbringen, die nicht einfach aktualisiert werden können. Im Zweifel ist eine komplette Migration auf eine neue WordPress-Installation mit aktuellen Themes und Plugins der sicherere Weg.

Wer an dieser Stelle grundsätzlich überlegt, ob WordPress das richtige System für die nächsten Jahre ist, findet in unserem Artikel zu Next.js vs. WordPress eine ehrliche Abwägung der Systemalternativen.

---

Wann externe Begleitung sinnvoll ist — und wann nicht

Wer eine einfache WordPress-Website ohne individuelle Programmierung betreibt und regelmäßig aktualisiert, kann Updates selbst einspielen. Das Dashboard-Update reicht aus, ein Backup davor ist Pflicht.

Externe Begleitung ist sinnvoll, wenn:

• Die Website individuell angepasst wurde — eigenes Theme, maßgeschneiderte Plugins oder Funktionserweiterungen
• WooCommerce oder ein anderes transaktionales System im Einsatz ist, das nach einem Update weiter korrekt funktionieren muss
• Keine Staging-Umgebung vorhanden ist und der Traffic keine spontanen Ausfälle erlaubt
• Die letzte Aktualisierung länger zurückliegt und mehrere Updates gleichzeitig nachgeholt werden müssen
• Ein früheres Update einen Fehler erzeugt hat, der nicht vollständig aufgeklärt wurde

Nicht jedes Update benötigt eine externe Begleitung — aber wenn der Funktionstest nach einem Update nicht systematisch durchgeführt wird, fehlt die Gewissheit, dass die Website noch so läuft wie vor dem Update.

---

WordPress-Sicherheit als laufender Prozess

Ein einzelnes Update schließt eine bekannte Lücke. Was danach folgt, entscheidet, ob die Website auch bei der nächsten Lücke sicher behandelt wird.

Für Unternehmen, die ihre WordPress-Website nicht intern betreuen wollen oder können, sind Managed IT-Services eine strukturierte Alternative: Backup-Routinen, Update-Management, Monitoring und ein definierter Eskalationsweg bei Sicherheitsvorfällen sind dann Teil des laufenden Betriebs statt reaktiver Aufwand.

Wer die aktuelle Lückenlandschaft rund um WordPress 7.1.4 und den Kontext der Vorversionen vertiefen möchte, findet in unserem Artikel zu den WordPress-Sicherheitslücken 2026 eine vollständige technische Einordnung.

Ein Blick auf die eigene WordPress-Sicherheit im Gesamten — Zugriffsrechte, Plugin-Hygiene, Hosting-Konfiguration — lohnt sich parallel zum Update-Ablauf.

Und für alle, die ihr WordPress Sicherheitsupdate einspielen lassen möchten, ohne sich um Backup, Staging-Test und Rollback selbst kümmern zu müssen: SW Business Solutions plant und begleitet WordPress-Updates mit Backup, Staging-Test, Abnahme und Dokumentation. Erstgespräch buchen — kostenlos und unverbindlich.

---

Zusammenfassung: Ablauf auf einen Blick

Schritt	Was zu tun ist	Wann nötig
Version prüfen	Dashboard → Aktualisierungen	Immer
Backup anlegen	Datenbank + Dateien, extern gespeichert	Immer vor Update
Staging-Test	Update auf Klon-Umgebung einspielen	Individuell angepasste Websites
Update einspielen	Dashboard, WP-CLI oder Hosting-Panel	Immer
Funktionstest	Kontaktformular, Shop, Login, mobile Ansicht	Immer nach Update
Dokumentation	Datum, Version, Testergebnis, Verantwortlicher	Empfohlen
Konten prüfen	Inaktive Nutzer entfernen, Rechte prüfen	Nach jedem Sicherheitsrelease
Upgrade planen	Bei veralteter Version (4.6 oder älter)	Dringend bei Betroffen