Zwei Vorfälle, ein Muster

Im Juli wurden zwei verkettete Schwachstellen im WordPress-Core öffentlich, die unauthentifizierte Codeausführung erlaubten. Zwischen Veröffentlichung und massenhafter Ausnutzung lagen Stunden, nicht Wochen. Wer monatlich patcht, war zu langsam. Die Details stehen in WP2Shell: Die kritische WordPress-Core-Lücke.

Im August erschien WordPress 7.1 und legte Websites lahm, die WP Rocket einsetzten. Nicht wegen eines Fehlers im Core und nicht wegen eines Fehlers im Plugin allein, sondern wegen einer Annahme über undokumentiertes Verhalten, die jahrelang zutraf. Betroffen war laut Hersteller rund ein Viertel der Nutzerbasis. Auch dazu gibt es einen eigenen Artikel: WP Rocket Fatal Error nach WordPress 7.1.

Das erste Ereignis bestraft langsames Updaten. Das zweite bestraft schnelles Updaten. Genau in diesem Widerspruch liegt das eigentliche Problem.

Die falsche Frage

Die übliche Diskussion lautet „automatische Updates: ja oder nein“. Das ist die falsche Frage, weil beide Antworten in einem der beiden Szenarien falsch sind.

Die richtige Frage lautet: Welche Art von Update bekommt welche Behandlung?

Risikobewertung nach Update-Typ
Update-Typ	Risiko bei sofortigem Einspielen	Risiko beim Warten	Empfehlung
Core Security-Release (7.0.1 auf 7.0.2)	sehr gering	sehr hoch	automatisch, sofort
Core Minor	gering	mittel	automatisch, kurze Verzögerung
Core Major (7.0 auf 7.1)	hoch	gering	Staging, manuell, mit Abstand
Plugin Security-Fix	gering	hoch	automatisch oder binnen 24 Stunden
Plugin Feature-Update	mittel bis hoch	gering	gebündelt, mit Test
Theme / Page Builder	hoch	gering	immer Staging

Diese Differenzierung ist der Kern. Alles andere ist Werkzeugfrage.

Der Prozess in fünf Stufen

1. Inventar

Du kannst nicht verwalten, was du nicht kennst. Für jede betreute Installation muss jederzeit abrufbar sein: Core-Version, PHP-Version, installierte Plugins mit Version und Lizenzstatus, eingesetztes Theme, Hoster, Backup-Ziel.

Ohne dieses Inventar dauert die Frage „Welche meiner Websites nutzen GiveWP in einer verwundbaren Version?“ einen halben Tag statt dreißig Sekunden. Mit WP-CLI und einer Schleife über die Installationsverzeichnisse ist die Antwort ein Einzeiler:

for dir in /var/www/*/; do
  [ -f "$dir/wp-config.php" ] || continue
  printf '%-36s %s\n' \
    "$(basename "$dir")" \
    "$(wp plugin get give --field=version --path="$dir" --skip-plugins --skip-themes 2>/dev/null)"
done

Die Schleife funktioniert allerdings nur, solange alle Installationen auf demselben Server liegen. Sobald die Websites über verschiedene Hoster verteilt sind, und das ist bei betreuten Kundenprojekten die Regel, braucht es ein Werkzeug, das von außen auf jede Installation schaut.

Ich nutze dafür MainWP. Auf jeder betreuten Website läuft ein Child-Plugin, das sich beim Dashboard meldet. Das Inventar ist damit eine Ansicht statt einer Abfrage: Core-Version, PHP-Version, jedes Plugin mit Version und verfügbarem Update, Theme, Lizenzstatus, letzter Backup-Lauf, und das über alle Hoster hinweg in einer Tabelle.

Der praktische Wert zeigt sich genau in den Momenten, um die es in diesem Artikel geht. Wird eine Lücke wie die in GiveWP bekannt, ist die Frage „Welche meiner Websites nutzen GiveWP in einer Version unter 4.16.7.2?“ eine Suche im Plugin-Überblick statt einer Runde durch vierzig Backends. Die konkrete Liste der fünf Erweiterungen, für die das zwischen Mitte August und Anfang September 2026 akut war, steht in Kritische WordPress-Plugin-Lücken 2026.

Entscheidend ist dabei nicht MainWP als Produkt. ManageWP, InfiniteWP oder das Dashboard deines Hosters leisten Vergleichbares. Entscheidend ist, dass die Frage in Sekunden beantwortbar ist und nicht davon abhängt, ob sich jemand an eine Installation erinnert.

2. Frühwarnung

Schwachstellen-Benachrichtigungen für die tatsächlich eingesetzten Plugins, nicht ein allgemeiner Newsletter. Patchstack und Wordfence bieten das, WPScan pflegt eine offene Datenbank.

Zusätzlich: die Release-Ankündigungen von WordPress selbst und, bei Major-Releases, den Field Guide auf make.wordpress.org. Der Field Guide zu 7.1 stand am 5. August online, zwei Wochen vor dem Release, und benannte den erzwungenen iframed Editor als Änderung mit Bruchpotenzial.

Die Einschränkung gehört dazu: Die Umstellung der Hook-IDs, an der WP Rocket zerbrach, stand nicht im Field Guide. Frühwarnung senkt das Risiko, sie beseitigt es nicht. Genau deshalb ersetzt sie die nächste Stufe nicht.

3. Staging mit echter Konfiguration

Der häufigste Fehler beim Staging ist, dass dort eine bereinigte Version läuft. Genau die Plugin-Kombination, die den Fehler auslöst, fehlt dann im Test.

WP Rocket hat das im eigenen Post-Mortem eingeräumt: Die Testsuite war über Jahre gewachsen und bildete nicht ab, was Nutzer tatsächlich einsetzen. Elementor Pro, eines der verbreitetsten Plugins überhaupt, war nicht in den automatisierten Tests.

Staging muss ein Klon der Produktion sein, inklusive Daten, inklusive aller Plugins, inklusive der Lizenzen. Eine Staging-Umgebung, in der die Avada-Lizenz fehlt, testet nicht das System, das später live geht.

4. Testprotokoll statt Bauchgefühl

„Sieht gut aus“ ist kein Test. Ein Minimalprotokoll pro Website:

Startseite lädt, HTTP-Status 200
Ein Beitrag und eine Seite im Editor öffnen und speichern
Jeden selbst gebauten Block auf einer Testseite einfügen
Kontaktformular absenden und Zustellung prüfen, auch im Spam-Ordner
Bei Shops: Produkt in den Warenkorb, Checkout bis zur Zahlungsauswahl
Login und Logout
debug.log nach dem Durchlauf prüfen

Das dauert pro Website wenige Minuten und fängt den Großteil dessen ab, was in der Praxis schiefgeht. Der Punkt zum Kontaktformular steht nicht zufällig auf der Liste: Ein Formular, das stillschweigend nicht mehr zustellt, fällt oft erst Wochen später auf, und dann fehlen die Anfragen aus diesen Wochen bereits.

Dieses Protokoll gibt es als druckbare WordPress-Update-Checkliste, zusammen mit den Vorbereitungsschritten und der Einordnung nach Update-Typ. Gedacht zum Abhaken, pro Website eine Seite.

Der Statuscode-Test lässt sich vorab automatisieren, was bei zwanzig oder mehr Installationen den Einstieg spart:

# Alle betreuten Domains auf HTTP 200 prüfen, eine Domain pro Zeile in domains.txt
while read -r domain; do
  code=$(curl -s -o /dev/null -w '%{http_code}' --max-time 15 "https://$domain/")
  [ "$code" = "200" ] || printf 'PRÜFEN  %-36s HTTP %s\n' "$domain" "$code"
done < domains.txt

5. Rollback-Plan, bevor er gebraucht wird

Ein Backup, das nie zurückgespielt wurde, ist eine Vermutung. Vor jedem Major-Update: Backup ziehen, Wiederherstellungsweg kennen, Zugang zu SFTP und Datenbank griffbereit haben.

Der WP-Rocket-Fall hat gezeigt, warum: Wenn das Backend nicht mehr erreichbar ist, nützt der schönste Update-Button nichts. Wer dann erst die Zugangsdaten sucht, verliert Stunden. Fehlende und ungetestete Backups stehen aus gutem Grund auf Platz eins der häufigsten WordPress-Fehler.

Was das in der Praxis kostet

Für eine einzelne Website ist dieser Prozess Overhead. Für fünf Websites ist er lästig. Ab etwa zehn Installationen ist er die einzige Variante, die funktioniert, weil der manuelle Weg schlicht nicht mehr in den Tag passt. Bei den rund 40 Installationen, die ich betreue, entscheidet das Inventar darüber, ob eine kritische Lücke ein Vorgang von Minuten ist oder die Tagesplanung sprengt: Betroffene finden, Updates gebündelt ausrollen, Ergebnis gegenprüfen. Ohne zentrale Übersicht ist allein der erste dieser drei Schritte der längste.

Und das ist der Punkt, an dem die meisten Betreiber landen: nicht bei der Frage, ob der Prozess sinnvoll ist, sondern bei der Frage, wer ihn macht.

Fazit

Updates sind kein Risiko, das man durch Nichtstun vermeidet. Nichtstun ist das größere Risiko, es wirkt nur langsamer. Was Websites schützt, ist nicht die Entscheidung zwischen schnell und vorsichtig, sondern ein Prozess, der beides differenziert: Security-Patches sofort, alles andere getestet.

Wer den Prozess selbst aufsetzen will, nimmt die Update-Checkliste als Ablaufplan und die WordPress-Sicherheits-Checkliste für die Hardening-Seite desselben Themas. Wer wissen will, was beim nächsten Major-Release konkret ansteht, findet die Breaking Changes in WordPress 7.1: Was sich ändert.

Warum WordPress-Updates Websites zerlegen und wie ein Prozess aussieht, der das verhindert