Aktualisiert am 13 Min. Lesezeit
Sébastien Nobour
Gründer von DEVEDANOS
Soll WordPress seine Updates selbst installieren, oder schaltet man das besser ab? Bei Plugins und Themes raten wir von den automatischen Updates ab, die WordPress selbst und ohne jeden Test einspielt. Automatische Updates durch einen Hoster, der jedes Update testet, bevor er es einspielt, und auf die vorherige Version zurücksetzen kann, eignen sich dagegen: Aus unserer Sicht reichen diese Prüfungen bei WordPress in der Regel aus, um zu erkennen, dass etwas nicht stimmt. Ohne einen solchen Hoster aktualisieren Sie ein Plugin oder ein Theme nach dem anderen und prüfen danach, ob es eine Fehlfunktion verursacht; bei einem Problem kehren Sie zur vorherigen Version zurück.
Das NCSC, das nationale Cybersicherheitszentrum des Vereinigten Königreichs, fordert alle Organisationen auf, „Software-Updates so schnell wie möglich einzuspielen, idealerweise automatisch“, weil Angreifer oft eine geschlossene Lücke untersuchen, um einen Angriff zu schreiben, der sie ausnutzt; laut Amazon verringert KI den Aufwand für diese Arbeit. Das NCSC erinnert daran, dass der Hersteller seine Updates selbst testet, verlangt aber zugleich, sie auch auf den eigenen Systemen zu testen und schrittweise auszurollen. Für Software, die man installiert und unverändert nutzt (Windows, macOS, ein Smartphone, ein Browser, eine Office-Anwendung), raten wir daher, die automatischen Updates dieser Software zu aktivieren. Bei einem Onlinedienst spielt sein Anbieter die Patches ein. Eine WordPress-Website fällt in keine dieser beiden Kategorien: Ihr Betreiber entwickelt die Software nicht und nutzt sie auch nicht unverändert; er setzt sie zusammen und konfiguriert sie.
Der Hersteller eines Betriebssystems testet seine Updates für das gesamte System. Das Update eines WordPress-Plugins dagegen lässt sich nicht vorab mit allen anderen Plugins testen, die auf Ihrer Website installiert sind.
WordPress wird im Oktober 2026 von fast vier von zehn Websites verwendet, und der Großteil seiner Lücken steckt nicht in WordPress selbst. Laut Patchstack wurden 2025 im WordPress-Ökosystem 11.334 neue Lücken gefunden: 91 % in Plugins, 9 % in Themes und nur 6 im Kern von WordPress. Und 46 % dieser Lücken hatten zum Zeitpunkt ihrer Veröffentlichung keinen Patch von ihrem Entwickler erhalten (Patchstack). Diese Zahlen stammen von einem Unternehmen, das Schutz gegen solche Lücken verkauft.
Diese Updates installieren eine neue Version kurz nach ihrem Erscheinen, bevor jemand ein Problem damit melden konnte: bösartigen Code, der in eine gerade erst veröffentlichte Version eingeschleust wurde, oder eine neue Lücke. Besser geschützt ist die Website dadurch also nicht unbedingt. WordPress.org trägt dem Rechnung: Seit dem 5. Juni 2026 wartet jede neue Version eines Plugins aus seinem Verzeichnis bis zu 24 Stunden, bevor die automatischen Updates sie verteilen, damit alle Zeit haben, ihre Änderungen zu prüfen. Und eine WordPress-Website setzt sich aus dem WordPress-Kern, einer PHP-Version sowie Plugins und Themes zusammen, die Autoren unabhängig voneinander geschrieben haben. Nichts garantiert, dass die neue Version eines Plugins mit der Version eines anderen zusammenarbeitet, oder mit der PHP-Version des Servers. WordPress installiert sie trotzdem in der Produktion, ohne dass ein Test oder ein Mensch geprüft hätte, ob die Website noch funktioniert.
Ein Hoster, der jedes Update vor dem Einspielen testet und auf die vorherige Version zurücksetzen kann, kann das automatisch übernehmen (siehe weiter unten). Ohne einen solchen Hoster bleibt die Methode dieselbe, ob man sich selbst darum kümmert oder ein Dienstleister es tut. Sie beginnt mit einem Backup: WordPress verlangt, vor jedem Update, ob automatisch oder manuell, die Dateien und die Datenbank zu sichern. Danach aktualisiert man ein Plugin oder ein Theme nach dem anderen und prüft nach jedem, ob es eine Fehlfunktion verursacht. Bei einem Problem kehrt man zur vorherigen Version zurück, indem man das Backup wiederherstellt: zuerst die Dateien, dann die Datenbank.
Bei einer individuell entwickelten Anwendung tragen wir die exakte Version jeder Abhängigkeit ein, und jedes Update durchläuft, eines nach dem anderen, die Deployment-Pipeline und ihre automatisierten Tests, bevor es die Produktion erreicht. Diese Regel stammt aus Continuous Delivery von Jez Humble und Dave Farley und aus den Top-10-Listen der OWASP, der maßgeblichen Stiftung für die Sicherheit von Webanwendungen. Dave Farley ist der Erfinder der Deployment-Pipeline, die oft CI/CD-Pipeline genannt wird. Die Deployment-Pipeline ist die automatische Kette, die jede Codeänderung aufnimmt, testet, speichert und bereit macht, in Produktion zu gehen. Bei einer WordPress-Website lassen sich festgelegte Versionen, Pipeline und automatisierte Tests nur schwer umsetzen. Sie lohnen sich, wenn die Website einer Anwendung nahekommt, mit individuell geschriebenem Code: Das ist der Fall, der weiter unten beschrieben wird.
Standardmäßig installiert WordPress nur einen Teil seiner Updates selbst. Derzeit (Oktober 2026) werden seit WordPress 3.7 kleinere Updates des Kerns standardmäßig automatisch installiert (WordPress). Bei Plugins und Themes sind automatische Updates seit WordPress 5.5 einzeln zu aktivieren, und WordPress führt sie dann zweimal täglich aus. Bei den größeren Updates des Kerns hängt die Standardeinstellung davon ab, wann die Website installiert wurde (siehe weiter unten). Dieselbe WordPress-Seite beginnt mit diesem Satz: „Um Ihre WordPress-Website sicher zu halten, sollten Sie Ihre Plugins und Themes immer auf die neueste Version aktualisieren“ (WordPress).
Patchstack hat 2025 eine mediane Zeit von fünf Stunden zwischen der Veröffentlichung einer stark ausgenutzten Lücke und ihrer ersten Ausnutzung gemessen. Warnmeldungen lassen sich automatisieren; ob aktualisiert wird, entscheidet ein Mensch, und zwar sobald die Warnmeldung eingeht. Bei einer WordPress-Website startet der Administrator das Update eines Plugins mit einem Klick und prüft dann, ob die Website funktioniert. Hat das Unternehmen niemanden, der sich darum kümmert, kann ein Dienstleister das übernehmen, wie wir weiter unten beschreiben.
Zwei weitere Stellschrauben sind mindestens ebenso wichtig. Da 2025 fast die Hälfte der Lücken im WordPress-Ökosystem am Tag ihrer Veröffentlichung keinen Patch hatte, deckt an diesem Tag keine Update-Strategie sie ab, ob automatisch oder manuell. Weniger installierte Plugins bedeuten weniger mögliche Lücken, wie bei jeder Abhängigkeit einer Anwendung. Und ein Plugin, das sein Autor aufgegeben hat, erhält keinen Patch mehr: Es wird ersetzt.
Für Plugins und Themes raten wir, die automatischen Updates zu deaktivieren; für den WordPress-Kern, die kleineren Updates weiterhin automatisch installieren zu lassen.
Derzeit (Oktober 2026) werden die automatischen Updates von Plugins und Themes einzeln im Administrationsbereich eingestellt. Auf der Seite Plugins zeigt die Spalte „Automatische Aktualisierungen“ für jedes Plugin einen Link, der seine automatischen Updates einschaltet („Automatische Aktualisierungen aktivieren“) oder abschaltet („Automatische Aktualisierungen deaktivieren“); über die Mehrfachaktionen gilt die Einstellung für mehrere Plugins zugleich. Bei einem Theme steht der Link auf der Seite Design, in dem Fenster, das sich öffnet, wenn man auf seine Vorschau klickt. Fehlen diese Links, hat wahrscheinlich der Hoster oder ein Plugin die Funktion abgeschaltet.
Beim WordPress-Kern hängt die Standardeinstellung davon ab, wann die Website installiert wurde. Seit WordPress 5.6 erhalten neue Installationen automatisch kleinere und größere Updates; eine ältere Installation behält ihre Einstellung und erhält standardmäßig nur die kleineren Updates. Auf der Seite Aktualisierungen des Administrationsbereichs lässt sich diese Einstellung ändern.
Die kleineren Updates des Kerns schließen Lücken und dienen der Wartung, und von ihrer Deaktivierung wird laut WordPress „dringend abgeraten“. Die größeren Updates bringen neue Funktionen; aus unserer Sicht geht man bei ihnen vor wie bei den Updates von Plugins und Themes: eines nach dem anderen, und danach prüfen, ob die Website funktioniert.
In wp-config.php legt die Konstante WP_AUTO_UPDATE_CORE fest, was der Kern selbst installiert, und hat Vorrang vor der Einstellung auf der Seite Aktualisierungen: true für alle Updates, 'minor' nur für die kleineren, false für keines (WordPress). Die Konstante AUTOMATIC_UPDATER_DISABLED schaltet alle automatischen Updates ab, einschließlich Kern und Übersetzungen. Aus unserer Sicht ist sie nur gerechtfertigt, wenn jedes Update des Kerns anderweitig getestet wird, etwa mit Bedrock, weiter unten beschrieben.
// In wp-config.php: Der Kern installiert nur seine kleineren Updates selbst
define( 'WP_AUTO_UPDATE_CORE', 'minor' );
Bei Plugins und Themes entscheiden die Filter auto_update_plugin und auto_update_theme anstelle der Links im Administrationsbereich. WordPress rät, diese Filter in ein Must-Use-Plugin zu legen, nie direkt in wp-config.php. Ein Must-Use-Plugin liegt im Ordner wp-content/mu-plugins, ist von selbst aktiv und lässt sich im Administrationsbereich nicht deaktivieren.
<?php
// wp-content/mu-plugins/disable-plugin-theme-auto-updates.php
/**
* Plugin Name: Disable plugin and theme auto-updates
*/
defined( 'ABSPATH' ) || exit;
// Deaktiviert die automatischen Updates aller Plugins und aller Themes
add_filter( 'auto_update_plugin', '__return_false' );
add_filter( 'auto_update_theme', '__return_false' );
Während eines Updates versetzt WordPress die Website in den Wartungsmodus: Es legt eine Datei .maintenance im Stammverzeichnis der Website an, und Besucher sehen einen Hinweis auf geplante Wartungsarbeiten. Bricht das Update ab, bleibt die Datei liegen, und mit ihr der Hinweis. WordPress beschreibt das Vorgehen:
.maintenance im Stammverzeichnis der Website löschen, per FTP oder über den Dateimanager des Hosters. Der Hinweis verschwindet.Der letzte Schritt setzt ein aktuelles Backup voraus, dessen Wiederherstellung bereits ausprobiert wurde: WordPress verlangt, das vor dem Aktivieren der automatischen Updates von Plugins zu prüfen.
Wurden Plugins oder Themes automatisch aktualisiert, erhält der Betreiber der Website eine E-Mail, auch wenn einzelne Updates fehlgeschlagen sind. Beim Kern meldet ebenfalls eine E-Mail das Scheitern. Im Administrationsbereich erscheint das Scheitern so: „Eine automatische WordPress-Aktualisierung konnte nicht abgeschlossen werden. Versuche bitte, die Aktualisierung jetzt erneut zu starten.“
Starten die automatischen Updates nie, sehen Sie sich die Fehlermeldungen unter Werkzeuge > Website-Zustand an: Sie beruhen auf den geplanten Aufgaben von WordPress, die nicht auf jedem Server zuverlässig ausgeführt werden.
Die WordPress-Updates aktualisieren nur WordPress, nie PHP: Je nach Hosting spielt der Hoster die PHP-Patches ein, oder Sie tun es selbst. Wir empfehlen, einen Hoster zu wählen, der das übernimmt, und ihn vorher zu fragen, wer die Patches einspielt, in Ihrem Hosting-Tarif und wie schnell.
Bei einer WordPress-Website zwingt nichts dazu, diese Wartung selbst zu übernehmen. Auf WordPress spezialisierte Hoster übernehmen die Aktualisierung der Serversoftware, darunter PHP, und automatische Backups. Der Sicherheitsleitfaden von WordPress beschreibt den vertrauenswürdigen Hoster: Er „stellt die neuesten stabilen Versionen aller Serversoftware bereit“, bietet „zuverlässige Methoden für Backup und Wiederherstellung“ und spricht bereitwillig über die Sicherheitsmaßnahmen, die er anbietet.
Ein Managed-WordPress-Angebot aktualisiert in der Regel PHP und WordPress für Sie. Manche Angebote aktualisieren auch die Plugins automatisch. An der Methode ändert das nichts: Der Hoster aktualisiert ein Plugin nach dem anderen, prüft die Website nach jedem und kann zur vorherigen Version zurückkehren. Das ist die automatische Variante, die wir für vertretbar halten: Bei WordPress reichen diese Prüfungen in der Regel aus, um zu erkennen, dass etwas nicht stimmt.
Kostenpflichtige Plugins, Plugins mit Lizenzschlüssel und die für die Website geschriebenen Plugins bleiben in der Regel Ihre Sache. Jedes davon wird nach der weiter oben beschriebenen Methode aktualisiert: eines nach dem anderen, danach prüfen, ob die Funktion, die es der Website hinzufügt, noch wie vorher läuft, und zur vorherigen Version zurückkehren, wenn nicht.
Stellen Sie einem Hoster vor der Wahl auch diese Fragen:
Wenn Sie Plugins und Themes nicht selbst aktualisieren möchten, übertragen Sie diese Aufgabe jemandem, der die Website und ihren Server administriert. Die Methode bleibt dieselbe: ein Plugin nach dem anderen, eine Prüfung nach jedem, eine Rückkehr zur vorherigen Version bei einer Regression, und PHP wird aktualisiert, wenn der Hoster es nicht tut. Wir können das übernehmen: Kontaktieren Sie uns.
Auch eine individuell entwickelte Anwendung wird erst nach bewusster Entscheidung aktualisiert. Jedes Update, von PHP wie von einer Komponente, durchläuft die Deployment-Pipeline und ihre automatisierten Tests; der Patch für eine schwere Lücke geht noch am Tag seiner Veröffentlichung in Produktion.
Anders sieht es aus, sobald man den Code anfassen muss. Die erste Regel von WordPress gilt für alle: „Fassen Sie den WordPress-Kern nicht an“, weil jedes Update dessen Dateien überschreibt; was man hinzufügen oder ändern will, kommt in ein Plugin. Bei einem Theme erlaubt ein Child-Theme, es zu ändern, ohne seinen Code anzufassen, und weiterhin seine Updates zu erhalten. Dieser individuell geschriebene Code, Child-Theme oder Plugin, ist Software, die man entwickelt. In Continuous Delivery verlangen Jez Humble und Dave Farley, alles, was zum Bauen und Deployen der Software dient, unter Versionsverwaltung zu halten und jede Änderung durch die Deployment-Pipeline laufen zu lassen. Konkret liegt dieser Code in einem Git-Repository und geht über die Pipeline in Produktion, nie von Hand auf den Server kopiert.
Niemand muss den WordPress-Kern ändern. Was einer klassischen Installation fehlt, liegt woanders. Plugins werden über den Administrationsbereich installiert, ohne dass ihre Versionen irgendwo deklariert sind, und die Konfiguration steckt in einer einzigen Datei, für alle Umgebungen dieselbe. Man kann also die Website, die in Produktion ist, nicht exakt auf einer Testumgebung nachbauen, was Jez Humble und Dave Farley jedoch fordern. Diesen Mangel behebt Bedrock von Roots. Es verändert den WordPress-Kern nicht, sondern legt sich um ihn. WordPress, seine Plugins und Themes werden darin zu Abhängigkeiten, die Composer in einer bestimmten Version installiert und in composer.lock festschreibt. Die Konfiguration ändert sich je nach Umgebung (Entwicklung, Staging, Produktion) über Umgebungsvariablen. Das Git-Repository enthält nur noch den individuell geschriebenen Code, die Konfiguration und die Liste der Abhängigkeiten, und laut Roots lassen sich Kern und Plugins außerhalb der Entwicklungsumgebung nicht mehr ändern. Roots versteht diesen Aufbau als Anwendung der Methode „The Twelve-Factor App“ (die Zwölf-Faktoren-App) auf WordPress; diese Methode beschreibt, wie man Webanwendungen baut, die sich leicht deployen und warten lassen. Updates erfolgen dann im Code, ein Plugin nach dem anderen, und durchlaufen anschließend die Pipeline. Die Standardkonfiguration von Bedrock deaktiviert derzeit automatische Updates und die Installation von Plugins über den Administrationsbereich (config/application.php).
Aus unserer Sicht lohnt sich Bedrock, sobald eine WordPress-Website wie Software gepflegt wird: individueller Code, mehrere Umgebungen, ein Entwicklungsteam, eine Pipeline. Für eine Website, die man konfiguriert und der man ein Child-Theme oder ein Plugin hinzufügt, ist es nicht nötig. Und Bedrock organisiert das Projekt, mehr nicht: Die Qualität des individuell geschriebenen Codes bleibt Sache derer, die ihn entwickeln.
// config/application.php von Bedrock, Standardkonfiguration
// Deaktiviert die automatischen Updates von WordPress
Config::define('AUTOMATIC_UPDATER_DISABLED', true);
// Deaktiviert den Datei-Editor des Administrationsbereichs
Config::define('DISALLOW_FILE_EDIT', true);
// Verbietet, Plugins über den Administrationsbereich zu installieren oder zu aktualisieren
Config::define('DISALLOW_FILE_MODS', true);
# Mit Bedrock: ein einzelnes Plugin im Code aktualisieren, dann die Pipeline durchlaufen
composer update wp-plugin/plugin-name
Ohne Bedrock rät der WordPress-Leitfaden zur Härtung der Sicherheit, den Datei-Editor des Administrationsbereichs zu deaktivieren, mit dem sich standardmäßig der PHP-Code von Plugins und Themes ändern lässt; er stellt klar, dass das nicht alles verhindert, aber manche Angriffe stoppen kann (WordPress):
// In wp-config.php: deaktiviert den Datei-Editor des Administrationsbereichs
define( 'DISALLOW_FILE_EDIT', true );
Um ein Plugin nach dem anderen zu aktualisieren, behält man mit WP-CLI, dem Kommandozeilenwerkzeug von WordPress, die Kontrolle: wp plugin update akzeptiert --version, um eine bestimmte Version anzusteuern, --patch, um nur die Fehlerbehebungen zu übernehmen, und --dry-run, um zu sehen, was aktualisiert würde, ohne etwas zu ändern (WP-CLI). Die WordPress-Dokumentation selbst nennt Anpassungen und vorheriges Testen auf einer Staging-Umgebung als Gründe, automatische Updates zu deaktivieren, und setzt vor ihrer Aktivierung für Plugins voraus, zur vorherigen Version der Website zurückkehren zu können.
Auch bei einer WordPress-Website darf sich der Code über die Website nicht ändern lassen, und jedes Programm erhält nur die Rechte, die es braucht. WordPress sieht das vor: Nur das Verzeichnis für hochgeladene Inhalte (wp-content) muss für den Webserver beschreibbar sein, und der in den Administrationsbereich integrierte Code-Editor, laut WordPress oft „das erste Werkzeug, das ein Angreifer verwendet, wenn es ihm gelingt, sich anzumelden“, lässt sich deaktivieren.
Der Sicherheitsleitfaden von WordPress empfiehlt außerdem: MySQL-Benutzer auf Lesen und Schreiben von Daten beschränkt (die Rechte DROP, ALTER und GRANT können entzogen werden, wobei zu beachten ist, dass manche Updates das Schema ändern); wp-config.php mit den Berechtigungen 400 oder 440; DISALLOW_FILE_EDIT, weiter oben beschrieben; Web Application Firewall, wobei ModSecurity als die verbreitetste freie Option genannt wird.
Für die Anwendungen, die wir entwickeln, legen wir jede Abhängigkeit auf ihre exakte Version fest, prüfen täglich, ob eine bekannte Lücke die eingesetzten Komponenten betrifft, und überwachen die Server.
Eine WordPress-Website wird zur Anwendung, sobald ihre Nutzer dort eigene Daten anlegen, ändern und speichern und die Website auf diese Daten Geschäftsregeln anwendet: Bestellungen über WooCommerce, ein Mitgliederbereich, Buchungen nach Verfügbarkeit. Bei solchen Anwendungen gehören Updates und Sicherheitspatches, wie bei individuell entwickelten, zur Wartung, die in unserem Angebot inbegriffen ist: individuelle Software mit festem Monatsbudget, mit einer Null-Regressions-Garantie.
Am 21. Oktober 2026 hat das PHP-Team außerplanmäßig neue Versionen der Sprache veröffentlicht. Sie schließen zwei kritische Sicherheitslücken, die ihre Entdecker PHP2Shell getauft haben. Unser Artikel über PHP2Shell erklärt, wer betroffen ist, was Schritt für Schritt zu tun ist und wie sich der Schaden einer Ausnutzung begrenzen lässt.
Sie möchten eine Anwendung entwickeln lassen oder wieder in den Griff bekommen? Sprechen wir darüber?
DISALLOW_FILE_EDIT) und „Upgrading WordPress“.config/application.php.
Was ist Schatten-IT? Die Definition des britischen Cybersicherheitszentrums, Beispiele (Excel, KI-Werkzeuge), die Risiken für das Unternehmen und warum die Antwort ein Werkzeug ist, das zur Arbeit passt.
Eine Webanwendung schützen, in welcher Sprache sie auch geschrieben ist: begrenzen, was eine Lücke einem Angreifer zugänglich macht, sofort alarmiert werden, Abhängigkeiten prüfen, jeden kritischen Patch noch am Tag seiner Veröffentlichung einspielen.
Am 21. Oktober 2026 hat PHP zwei kritische Sicherheitslücken geschlossen, zeitgleich mit GitLab und Node.js. Wer betroffen ist, was noch am selben Tag zu tun ist, und wie sich der Schaden einer Lücke begrenzen lässt.