Kurz und einfach erklärt
Für eine schwere Lücke in WordPress gab es ein Update. Auch viele ältere Fassungen bekamen eine Korrektur.
Der Beitrag erklärt, was ältere Fassungen noch bekommen und was nicht. Darauf kann man sich nicht verlassen. Wichtig ist auch, dass das Update wirklich auf Ihrer Seite ankommt.
Wer auf einer alten Fassung bleibt, sollte den Wechsel planen.
Wir prüfen nach jedem Update für die Sicherheit, ob es auf Ihren Seiten angekommen ist. Den Wechsel auf eine gepflegte Fassung planen wir mit Ihnen.
Am 22. September 2026 erschien WordPress 7.1.2 mit dem Fix für eine Lücke, die das Projekt selbst als kritisch einstuft (WordPress.org). Am selben Tag bekamen auch Seiten auf deutlich älteren Ständen ein Punkt-Release: 7.0.6, 6.9.9, 6.8.10 und so weiter bis hinunter zu 4.7.37, mit 7.1 zusammen 25 Zweige (Advisory GHSA-7hp8-65ch-5whp). Wer einen Shop oder eine Firmenseite auf WordPress 6.4 oder 5.9 betreibt, war damit geschützt, sofern das Update tatsächlich ankam. Dahinter steht eine Zweigpolitik, die selten erklärt wird: Offiziell aktiv unterstützt ist nur die jeweils neueste Version. Alles darunter erhält Sicherheitsfixes als Gefälligkeit, ohne Zusage für die nächste Lücke, und Zweige unter 4.7 erhalten seit Juli 2025 gar nichts mehr (WordPress Security Team). Dieser Beitrag ordnet ein, was ältere Zweige heute bekommen, warum ein Punkt-Update auf dem alten Zweig vorerst reicht, wo diese Rechnung endet und wann der Sprung auf 7.x in den Wartungsplan gehört.
Das Wichtigste in Kürze
- WordPress 7.1.2 vom 22. September 2026 schloss eine kritische Lücke mit CVSS 9,2 (Advisory GHSA-7hp8-65ch-5whp). Gepatcht wurden 25 Zweige (Advisory GHSA-7hp8-65ch-5whp) von 7.1 bis 4.7, davon 24 per Rückportierung.
- Offiziell aktiv unterstützt ist nur die jeweils neueste WordPress-Version (WordPress.org). Rückportierungen auf ältere Zweige sind eine Gefälligkeit des Sicherheitsteams, ohne Zusage für die nächste Lücke und ohne festen Termin.
- Zweige unter 4.7 erhalten keine Sicherheitsfixes mehr. Das letzte Release für 4.6 war 4.6.30 vom 17. Juli 2025 (WordPress.org Releases); angekündigt wurde das Ende im Juni 2025, einen knappen Monat vorher (WordPress Security Team).
- Der Zweig begrenzt auch PHP: WordPress 4.7 ist höchstens mit PHP 7.1 (Make WordPress Core) kompatibel, und PHP 7.1 bekommt seit dem 1. Dezember 2019 (The PHP Group) keine Sicherheitsupdates mehr.
- Backports erreichen eine Seite über die automatischen Minor-Updates. Wer sie abschaltet, muss jedes Sicherheitsrelease selbst einspielen und danach die tatsächlich installierte Version mit der gepatchten Version des eigenen Zweigs abgleichen.
- Spätestens wenn die höchste PHP-Version eines Zweigs aus der Pflege fällt, gehört der Sprung in den Wartungsplan: Für 6.1 bis 6.3 ist das PHP 8.2, dessen Sicherheitspflege am 31. Dezember 2026 (The PHP Group) endet.
Was am 22. September zurückportiert wurde
Die Lücke, die WordPress 7.1.2 schließt, sitzt in der Auflösung von Seitentemplates. Laut Release-Post kann ein nicht angemeldeter Angreifer unter bestimmten Bedingungen erreichen, dass WordPress eine lokale PHP-Datei außerhalb der Theme-Verzeichnisse einbindet; treffen weitere Voraussetzungen an Server und aktivem Theme zu, wird daraus Codeausführung aus der Ferne (WordPress.org). Das Advisory bewertet die Lücke mit 9,2 von 10 Punkten nach CVSS (Advisory GHSA-7hp8-65ch-5whp) und nennt die Voraussetzungen konkret: Das aktive Theme muss ein Verzeichnis enthalten, dessen Name mit „page-“ beginnt, was unter anderem die älteren Standard-Themes Twenty Twelve und Twenty Fourteen betrifft, und auf dem Server muss eine passende PHP-Datei für den Webserver lesbar sein.
Für die Wartung ist ein anderer Absatz des Release-Posts wichtiger als die technische Beschreibung. Unter der Überschrift „Backports“ steht, dass der Fix aus Kulanz auf alle Zweige übertragen wurde, die noch Sicherheitsfixes erhalten, derzeit bis einschließlich 4.7 (WordPress.org). Das Advisory listet die Ergebnisse auf: 25 gepatchte Versionen von 7.1.2 über 7.0.6, 6.9.9 und 6.8.10 bis zu 4.7.37 (Advisory GHSA-7hp8-65ch-5whp). Wer am 22. September eine Seite auf WordPress 5.4 betrieb, bekam also 5.4.23 und nicht 7.1.2. Der Zweig bleibt derselbe, nur die dritte Stelle der Versionsnummer zählt hoch. Funktionen, Abhängigkeiten und die Anforderungen an PHP bleiben dabei in der Regel unverändert.
As a courtesy, the security fix was backported to all branches eligible to receive security fixes (currently through 4.7). As a reminder, only the most recent version of WordPress is actively supported.
Der zweite Satz des Zitats ist der Kern dieses Beitrags. Aktiv unterstützt ist nur die neueste Version (WordPress.org), zum Zeitpunkt des Releases also 7.1. Alles, was der Fix sonst erreicht hat, ist eine freiwillige Leistung des Sicherheitsteams. Die Sicherheitsseite von WordPress.org beschreibt auch den Zweck dieser Leistung: Ältere Seiten sollen kritische Sicherheitsfixes über die automatischen Updates erhalten (WordPress.org). Daraus folgen zwei Fragen, die jeder Betreiber eines älteren Zweigs beantworten können sollte. Kommt das Update bei mir an? Und wie lange wird es noch geliefert?
Drei Zustände: unterstützt, zurückportiert, ausgelaufen
Aus Sicht eines Betreibers kann ein WordPress-Zweig in drei Zuständen sein. Die Grenzen zwischen ihnen verschieben sich mit jeder Hauptversion und mit jeder Entscheidung des Sicherheitsteams. Wie schnell das geht, zeigt der Zweig 7.0: Er erschien am 20. Mai 2026 und war mit dem Erscheinen von 7.1 am 19. August 2026 (WordPress.org Releases) nach nur drei Monaten nicht mehr der aktiv unterstützte Zweig. Die Tabelle zeigt den Stand nach dem Sicherheitsrelease vom 22. September 2026.
| Zustand | Zweige (Stand Oktober 2026) | Was ankommt | Was nicht ankommt |
|---|---|---|---|
| Aktiv unterstützt | nur 7.1 (WordPress.org) | Sicherheitsfixes, Fehlerbehebungen und alle weiteren Punkt-Releases des Zweigs | nichts Wesentliches, das ist der gepflegte Stand |
| Rückportierung als Gefälligkeit | 7.0 bis 4.7, zusammen 24 Zweige (Advisory GHSA-7hp8-65ch-5whp) | Sicherheitsfixes, soweit das Sicherheitsteam sie für den Zweig für nötig hält | in der Regel keine reinen Fehlerbehebungen, keine neuen Funktionen, keine Zusage für künftige Lücken |
| Ausgelaufen | 4.6 und älter (WordPress Security Team) | nichts mehr; das Dashboard zeigt einen Hinweis, der sich nicht ausblenden lässt | jeder Sicherheitsfix seit Juli 2025 |
Die mittlere Zeile ist die größte und die unbequemste. In ihr stehen Installationen, die heute geschützt sind, ohne dass jemand diesen Schutz zugesagt hätte. Ein Shop auf 6.2 ist nach dem Update auf 6.2.13 gegen die Template-Lücke genauso abgesichert wie einer auf 7.1.2. Er ist es aber nur, weil das Sicherheitsteam den Aufwand für diesen Zweig noch einmal getragen hat. Wer seinen Wartungsplan auf diese Zeile baut, plant mit einer Leistung, die ein Dritter einseitig einstellen kann.
Warum die Grenze heute bei 4.7 liegt
Die Grenze ist nicht fest, sie wurde schon zweimal nach oben verschoben. Bis Ende November 2022 reichten die Rückportierungen bis zum Zweig 3.7 zurück; dessen letztes Release war 3.7.41 vom 30. November 2022 (WordPress.org Releases). Seit Dezember 2022 gingen sie nur noch bis 4.1 (WordPress Security Team). Im Juni 2025 kündigte das Team dann an, die Updates für 4.1 bis 4.6 im Juli 2025 einzustellen (WordPress Security Team). Das Versionsarchiv zeigt, wie das endete: Das letzte Release für 4.6 war 4.6.30 vom 17. Juli 2025, für 4.1 war es 4.1.42 vom 15. Juli 2025 (WordPress.org Releases).
Die Begründung steht in derselben Ankündigung und ist nüchtern. Der Aufwand, alte Zweige samt den Werkzeugen für Rückportierung, Bau, Test und Veröffentlichung am Leben zu halten, überwog inzwischen den Nutzen. Deutlich unter 1 Prozent der Seiten liefen im Juni 2025 noch auf 4.1 bis 4.6 (WordPress Security Team). Bei einem Sicherheitsrelease verbrachte das Team den Großteil der Zeit mit Backports für eine Minderheit der Installationen (WordPress Security Team), und dieser Aufwand wächst mit jeder Hauptversion, weil ein weiterer Zweig dazukommt.
Die Grenze kann wieder wandern
Für Zweige ab 4.7 gibt es also derzeit Fixes, für alles darunter nicht. Seiten unter 4.7 zeigen laut Ankündigung im Dashboard einen Hinweis, der sich nicht wegklicken lässt; für die letzten Updates dieser Zweige war angekündigt, ihn auffälliger darzustellen und auf das Ende der Sicherheitsupdates hinzuweisen (WordPress Security Team). Wer einen solchen Hinweis in einem Kunden-Backend sieht, hat keinen Schönheitsfehler vor sich, sondern einen Zweig ohne jede Pflege. Für das Gegenstück bei anderen Systemen, die ihre Supportenden mit festem Datum veröffentlichen, lohnt der Blick auf die Supportfristen von TYPO3, Drupal und Joomla.
Was Gefälligkeit im Alltag bedeutet
Gefälligkeit klingt harmlos, hat aber drei praktische Folgen. Die erste: Rückportiert wird nur, wo es nötig ist. Zum Sicherheitsrelease 6.9.2 vom März 2026 hieß es ausdrücklich, die Fixes würden „where necessary“ auf alle Zweige bis 4.7 übertragen (WordPress.org). Betrifft eine Lücke Code, den ein alter Zweig gar nicht enthält, erscheint dort kein Release, und der Betreiber muss selbst erkennen, ob sein Zweig betroffen war.
Die zweite: Rückportierungen kommen nicht zwingend am selben Tag. Zu WordPress 6.9.2 vom 10. März 2026 hieß es, die Backports seien in Arbeit und würden ausgeliefert, sobald sie fertig sind (WordPress.org). Laut Versionsarchiv erschien von den älteren Zweigen am selben Tag nur 6.8.4, 6.7.5 bis 6.4.8 folgten am 11. März, die Zweige 6.3 bis 5.3 mit Ausnahme von 6.0 am 12. März und 5.2.24 bis 4.7.32 am 13. März 2026; für den Zweig 6.0 verzeichnet das Archiv das nächste Release erst am 8. April 2026 (WordPress.org Releases). Drei Tage zwischen neuestem und ältestem Zweig sind in dieser Lage viel, denn mit dem ersten Release ist öffentlich dokumentiert, welche Art von Lücken geschlossen wurde. Wie schnell aus einer veröffentlichten Lücke Angriffe werden, beschreibt der Beitrag zum Patch-Zeitfenster bei WordPress.
Die dritte: Der Aufwand für das Team wächst, und damit der Druck, die Grenze erneut zu verschieben. Der Zweig 4.7 erschien am 6. Dezember 2016 und hat seitdem 37 Punkt-Releases erhalten, sechs davon allein 2026 (WordPress.org Releases). Ende August 2026 berichtete das Sicherheitsteam zudem von deutlich mehr eingehenden Sicherheitsmeldungen im zurückliegenden Jahr, zu einem großen Teil, weil KI-Modelle die Codeanalyse erleichtern; im Zuge eines strafferen Release-Prozesses terminiert es künftige Sicherheitsreleases nun vorab (WordPress Security Team). Jeder dieser Termine bedeutet ein Release pro betroffenem Zweig, derzeit also bis zu 25 auf einmal.
Gefälligkeit ist keine Zusage
Der zweite Engpass: PHP unter dem alten Zweig
Ein älterer WordPress-Zweig legt nicht nur den eigenen Code fest, sondern auch, welche PHP-Versionen darunter laufen können. Das Handbuch des Kernteams führt dazu eine Kompatibilitätstabelle. Für WordPress 4.7 endet sie bei PHP 7.1 (Make WordPress Core), und PHP 7.1 bekommt seit dem 1. Dezember 2019 (The PHP Group) keine Sicherheitsupdates mehr. Ein Shop auf 4.7.37 hat also einen frisch gepatchten WordPress-Kern auf einer Laufzeitumgebung, die seit fast sieben Jahren nicht mehr gepflegt wird.
| WordPress-Zweig | Höchste kompatible PHP-Version (Make WordPress Core) | Sicherheitspflege dieser PHP-Version (The PHP Group) |
|---|---|---|
| 6.9 bis 7.1 | PHP 8.5 | bis 31. Dezember 2029 |
| 6.7 und 6.8 | PHP 8.4 | bis 31. Dezember 2028 |
| 6.4 bis 6.6 | PHP 8.3 | bis 31. Dezember 2027 |
| 6.1 bis 6.3 | PHP 8.2 | bis 31. Dezember 2026 |
| 5.9 und 6.0 | PHP 8.1 | beendet am 31. Dezember 2025 |
| 4.7 bis 5.8 | PHP 7.1 bis 8.0 | beendet, zuletzt am 26. November 2023 (PHP 8.0) |
Die Tabelle zeigt eine Grenze, die in keinem Release-Post vorkommt. Alle Zweige bis einschließlich 6.0 laufen nur auf PHP-Versionen, die keine Sicherheitsupdates mehr erhalten. Nach dem 31. Dezember 2026 kommen 6.1 bis 6.3 dazu, weil dann die Sicherheitspflege für PHP 8.2 endet (The PHP Group). Der WordPress-Kern ist auf diesen Zweigen gepatcht, die Ebene darunter nicht. Wie ein PHP-Wechsel geplant und getestet wird, beschreibt der Beitrag zum PHP-EOL-Management; welche Fristen für Betriebssystem und Datenbank dazukommen, steht im Überblick zum Supportende von Betriebssystem und Datenbank.
Plugins und Themes laufen eigene Wege
Automatische Updates: der Weg, auf dem Backports ankommen
Rückportierungen sind darauf ausgelegt, ohne Zutun anzukommen. Die automatischen Hintergrund-Updates gibt es seit WordPress 3.7 (WordPress Developer Resources). Bestehende Installationen erhalten standardmäßig die Minor-Updates, also Wartungs- und Sicherheitsreleases innerhalb des eigenen Zweigs. Neue Installationen ab WordPress 5.6 erhalten zusätzlich auch Hauptversionen automatisch, sofern WordPress keinen Versionskontroll-Checkout erkennt (WordPress Developer Resources). Eine Seite, die vor WordPress 5.6 eingerichtet und seitdem nicht umgestellt wurde, bleibt also auf ihrem Zweig und bekommt dort die Punkt-Releases.
Die Standardeinstellung lässt sich überschreiben, etwa von Hostern, Agenturen oder Deploy-Abläufen, die Updates kontrolliert einspielen wollen. Das ist ein nachvollziehbarer Grund, erzeugt aber eine Pflicht: Wer die Automatik abschaltet, muss jedes Sicherheitsrelease selbst nachziehen. Wer im Betrieb welche Ebene aktualisiert, klärt der Beitrag zu den Zuständigkeiten zwischen Hoster und Wartung. Gesteuert wird das Verhalten des Kerns in der wp-config.php über die Konstante WP_AUTO_UPDATE_CORE. Mit dem Wert minor bleiben Minor-Updates an und Hauptversionen aus (WordPress Developer Resources).
// Minor-Updates (Wartung und Sicherheit) automatisch, Hauptversionen nicht
define( 'WP_AUTO_UPDATE_CORE', 'minor' );
// Nur mit eigenem Ablauf für Sicherheitsreleases setzen: schaltet jede
// automatische Aktualisierung ab, auch die Rückportierungen auf den Zweig
// define( 'AUTOMATIC_UPDATER_DISABLED', true );Die Dokumentation rät ausdrücklich davon ab, die Minor-Updates abzuschalten (WordPress Developer Resources). Wer es trotzdem tut, etwa weil Änderungen ausschließlich aus einem Repository ausgerollt werden, braucht einen anderen Weg, der nach jedem Sicherheitsrelease nachweisbar dasselbe leistet. Umgekehrt gilt: Auch wenn die Automatik eingeschaltet ist, bleibt offen, ob sie gelaufen ist. Fehlende Schreibrechte im Dateisystem oder ein Filter in einem Plugin können ein Hintergrund-Update verhindern, ohne dass im Frontend etwas auffällt. Deshalb gehört nach jedem Sicherheitsrelease eine kurze Prüfung dazu.
- Die installierte Version nach jedem Sicherheitsrelease abfragen, etwa per WP-CLI mit wp core version, und mit der gepatchten Version des eigenen Zweigs aus Release-Post oder Advisory vergleichen.
- Prüfen, ob WP_AUTO_UPDATE_CORE oder AUTOMATIC_UPDATER_DISABLED gesetzt sind und ob ein Plugin die Filter für Kern-Updates verändert.
- Die Dateirechte so belassen, dass WordPress den Kern aktualisieren kann, oder bewusst einen Deploy-Weg betreiben, der Punkt-Releases zeitnah ausrollt.
- Bei gestaffelten Rückportierungen die Prüfung für ältere Zweige einige Tage später wiederholen.
- Das Ergebnis festhalten: Datum, Zweig, alte und neue Version. Bei einem Sicherheitsvorfall ist das der Nachweis, dass die Lücke geschlossen war.
Wann der Sprung auf 7.x fällig ist
Ein Punkt-Update auf dem alten Zweig reicht für die aktuelle Lücke. Für die Frage, wie lange ein Zweig noch tragfähig ist, helfen andere Kriterien. Ein festes Enddatum aus dem WordPress-Projekt gehört nicht dazu, denn für Zweige unterhalb der neuesten Version wird keines veröffentlicht. Die Entscheidung liegt deshalb beim Betreiber, und sie lässt sich an sechs Auslösern festmachen.
PHP-Frist des Zweigs
Fällt die höchste kompatible PHP-Version aus der Sicherheitspflege, lässt sich der Zweig nicht mehr auf gepflegtem PHP betreiben. Für 6.1 bis 6.3 ist das nach dem 31. Dezember 2026 der Fall.
Plugin-Voraussetzungen
Verlangt ein geschäftskritisches Plugin in seiner nächsten Version einen neueren Kern, hängt die Seite an der alten Plugin-Version fest, samt deren künftigen Lücken.
Abstand zum aktuellen Zweig
Je mehr Hauptversionen zwischen Seite und aktuellem Stand liegen, desto größer der Sprung. Bei mehr als zwei Hauptversionen rät die Dokumentation, ein schrittweises Vorgehen zu erwägen.
Nächste Grenzverschiebung
Bisher traf jede Einschränkung der Rückportierung die ältesten Zweige zuerst. Wer auf 4.7 bis 4.9 steht, hat das geringste Polster.
Kein Anspruch auf den Fix
Rückportiert wird als Gefälligkeit und nur dort, wo das Sicherheitsteam es für nötig hält. Eine verlässliche Zusage für die nächste Lücke gibt es für ältere Zweige nicht.
Ohnehin geplante Arbeiten
Steht ein Serverumzug, ein PHP-Wechsel oder eine Erneuerung des Themes an, lässt sich der Zweigwechsel in dasselbe Wartungsfenster legen und mit denselben Tests abnehmen.
Der Rat zum schrittweisen Vorgehen steht in der Update-Anleitung: Wer über mehr als zwei Hauptversionen hinweg aktualisieren will, sollte ein inkrementelles Vorgehen erwägen, um Konflikte zu vermeiden und das Risiko von Schäden an der Datenbank zu senken (WordPress Developer Resources). Als Faustregel bietet sich an: Spätestens wenn der Zweig nur noch auf einer PHP-Version ohne Sicherheitspflege läuft, gehört der Sprung in den nächsten Wartungsplan. Wer auf 6.1 bis 6.3 steht, hat dafür bis zum Jahresende Zeit; wer auf 6.0 oder älter steht, hat diese Grenze bereits überschritten. Jeder Zwischenschritt wird auf einer Staging-Umgebung geprobt, bevor er live geht.
Ein Wartungsplan für ältere Zweige
Aus den Abschnitten oben ergibt sich ein Ablauf in fünf Schritten. Er setzt nicht voraus, dass eine Seite sofort auf 7.x wechselt. Er sorgt dafür, dass sie auf ihrem Zweig nachweisbar gepatcht ist, solange Rückportierungen kommen, und dass der Wechsel rechtzeitig vor der nächsten harten Grenze stattfindet.
Versionsinventar
Für jede Seite festhalten: Zweig und genaue Version, PHP-Version, Datenbankversion und die Einstellung der automatischen Updates. Ohne diese Liste lässt sich nach einem Sicherheitsrelease nicht sagen, welche Seiten betroffen sind.
Zielversion je Zweig bestimmen
Nach jedem Sicherheitsrelease aus Release-Post oder Advisory die gepatchte Version des eigenen Zweigs ablesen. Am 22. September 2026 war das für 6.8 die Version 6.8.10 (Advisory GHSA-7hp8-65ch-5whp).
Ankunft nachweisen
In einem festgelegten Zeitfenster prüfen, ob jede Seite die Zielversion erreicht hat, und Abweichungen von Hand nachziehen. Kommen Backports gestaffelt, wird die Prüfung für ältere Zweige wiederholt.
PHP-Frist eintragen
Für jede Seite das Ende der Sicherheitspflege der laufenden PHP-Version und der höchsten PHP-Version, die der Zweig verträgt, im Wartungskalender vermerken.
Sprungtermin festlegen
Einen Termin für den Zweigwechsel setzen, der vor dieser PHP-Frist liegt, mit Bestandsaufnahme der Plugins, Test auf Staging, aktueller Sicherung und vorbereitetem Rückweg.
Für jede Seite festhalten: Zweig und genaue Version, PHP-Version, Datenbankversion und die Einstellung der automatischen Updates. Ohne diese Liste lässt sich nach einem Sicherheitsrelease nicht sagen, welche Seiten betroffen sind.
Nach jedem Sicherheitsrelease aus Release-Post oder Advisory die gepatchte Version des eigenen Zweigs ablesen. Am 22. September 2026 war das für 6.8 die Version 6.8.10 (Advisory GHSA-7hp8-65ch-5whp).
In einem festgelegten Zeitfenster prüfen, ob jede Seite die Zielversion erreicht hat, und Abweichungen von Hand nachziehen. Kommen Backports gestaffelt, wird die Prüfung für ältere Zweige wiederholt.
Für jede Seite das Ende der Sicherheitspflege der laufenden PHP-Version und der höchsten PHP-Version, die der Zweig verträgt, im Wartungskalender vermerken.
Einen Termin für den Zweigwechsel setzen, der vor dieser PHP-Frist liegt, mit Bestandsaufnahme der Plugins, Test auf Staging, aktueller Sicherung und vorbereitetem Rückweg.
Der Plan klingt nach Verwaltung, spart aber im Ernstfall die entscheidenden Stunden. Ohne Inventar beginnt die Reaktion auf ein Sicherheitsrelease mit der Frage, welche Seiten überhaupt betroffen sind. Mit Inventar beginnt sie mit der Prüfung, ob der Fix angekommen ist. Für die Sicherung vor dem Zweigwechsel gilt dasselbe wie bei jedem größeren Eingriff: Sie muss wiederherstellbar sein, nicht nur vorhanden, was ein Backup-Service mit getesteter Wiederherstellung abdeckt. Wie sich der Wechsel selbst in umsatzschwache Zeiten legen lässt, beschreibt der Beitrag zu Wartungsfenstern ohne Umsatzausfall.
Zweigpolitik als Teil der WordPress-Wartung
Die Zweigpolitik von WordPress verlagert zwei Aufgaben auf die Betreiber, die vielen nicht bewusst sind: den Nachweis, dass ein Fix angekommen ist, und die Entscheidung, wann ein Zweig verlassen wird. In unserer WordPress-Wartung gehören beide zum festen Ablauf. Wir unterscheiden zwischen Minor-Updates mit Sicherheitsbezug und Hauptversionen, führen je Seite den Stand von Zweig, PHP-Version und Update-Einstellung und gleichen nach jedem Sicherheitsrelease die tatsächlich installierte Version mit der Zielversion ab. Fehlende Updates ziehen wir nach, zuerst auf Staging, dann live. Die automatischen Minor-Updates ersetzen wir dabei in der Regel durch kontrollierte, getestete Updates; gerade deshalb ist der Abgleich nach jedem Sicherheitsrelease kein Zusatz, sondern Pflicht.
Für Seiten auf älteren Zweigen planen wir den Sprung als eigenes Vorhaben: Bestandsaufnahme der Plugins und ihrer Mindestanforderungen, PHP-Wechsel, schrittweises Update über Zwischenversionen, Test der Kernfunktionen und ein vorbereiteter Rückweg. Sicherheitsrelevante Aktualisierungen laufen über unsere Sicherheitsupdates mit Abgleich gegen die eingesetzten Komponenten, die Erreichbarkeit nach jedem Eingriff überwacht das Monitoring. Welche Reaktionszeiten dabei gelten, regelt der SLA-Wartungsvertrag.
Verwandte Artikel
Serverumzug ohne Bestellverlust: Ablauf für Shops
Resolver liefern alte DNS-Antworten teils 1 bis 3 Tage weiter aus. So zieht ein Shop um, ohne Bestellungen, Cronjobs oder Zahlungsmeldungen zu verlieren.
Hoster oder Wartung: Wer im Shop was aktualisiert
Wo die Zuständigkeit des Hosters endet und die Wartung beginnt: eine Matrix über alle Schichten des Shops, Fragen an den Hoster und klare Übergabepunkte.
Supportende im Unterbau: Betriebssystem und Datenbank
Debian 11, MariaDB 10.6 und MySQL 8.0 sind 2026 aus der Pflege gefallen. So erfassen Sie Distribution, Datenbank und PHP und planen die Sprünge mit Vorlauf.