Das Update selbst ist die Lücke.
Themenstand: 05.11.2026 · Für den Blog aufbereitet am 06.11.2026. Auf Basis vorhandener Postingtexte neu ausgearbeitet.
Ein kurzlebiger Installationspfad reicht als Angriffsfläche. Was die WordPress-Lücke über sichere Wartung erzählt.
Ausgerechnet beim Reparieren.
Die unangenehme Pointe dieses Falls: Die verwundbare Phase gehört zum Update selbst. Wordfence führt CVE-2026-119977 als nicht authentifizierte Codeausführung während vollständiger WordPress-Core-Upgrades. Vorhersehbare, über das Web erreichbare Staging-Pfade schaffen dafür ein kurzes Zeitfenster.
Betroffen sind laut Advisory Versionen von 4.7 bis 7.1.3. WordPress veröffentlichte am 28. Oktober 2026 die Sicherheitsversion 7.1.4 und nennt ausdrücklich eine Schwäche im Upgrade-Prozess. Für ältere Versionszweige sind passende Sicherheitsreleases aufgeführt; daraus wird keine Empfehlung, alte Zweige dauerhaft weiterzubetreiben.
Eine Momentaufnahme übersieht den Übergang.
Im Alltag prüfen wir gern den Zustand vor und nach einer Änderung: alte Version, neue Version, Dienst erreichbar. Dazwischen entstehen jedoch temporäre Dateien, zusätzliche Rechte oder Hilfsendpunkte. Auch diese Übergangsphase braucht eine Sicherheitsbetrachtung.
Für mich ist das der übertragbare Punkt an diesem Fall. Eine Datei muss nicht lange liegen bleiben, um relevant zu sein. Wenn ein automatisierter Angreifer einen vorhersehbaren Pfad wiederholt prüft, ist ein kurzes Fenster keine belastbare Schutzmaßnahme.
Was ich vor einem Rollout klären würde.
Zuerst brauche ich ein Inventar der tatsächlichen Installationen und Upgrade-Wege. Welche Instanzen beziehen ein vollständiges Paket? Welche werden zentral ausgerollt? Welche Hintergrundaktualisierungen laufen eigenständig? Anschließend lässt sich der unterstützte Patchpfad für jede Instanz prüfen und in einer repräsentativen Testumgebung nachvollziehen.
Zusätzliche Webserver-Regeln für Wartungs- oder Staging-Pfade müssen zur jeweiligen Installation passen. Ich würde keine universelle Sperrregel aus einem Social-Post ungeprüft übernehmen. Entscheidend ist, ob sie die öffentliche Erreichbarkeit reduziert und der vorgesehene Update-Ablauf danach weiterhin funktioniert.
Nachher zählt mehr als die Versionsnummer.
Nach dem Rollout würde ich den erfolgreichen Versionswechsel und die Bereinigung temporärer Artefakte kontrollieren. Bei Hinweisen auf Ausnutzung gehören verfügbare Webserver-Protokolle, veränderte Dateien, Konfigurationen und privilegierte Konten in eine weitergehende Untersuchung. Die bloße Existenz einer install.php-Anfrage ist dabei noch kein vollständiger Kompromittierungsnachweis.
Updates abzuschalten wäre die falsche Schlussfolgerung. Die bessere Frage lautet: Wie gestalten wir Wartung so, dass auch ihre Zwischenzustände berücksichtigt werden? Ein Update ist ein Prozess mit überprüfbaren Schritten, kein magischer Sprung von unsicher zu sicher.
Aufbereitet von Maurizio Schmidt aus dem Posting-Archiv. Die damals erwähnten Angriffs-Zähler und Fristformulierungen werden hier bewusst nicht als heutige Lagewerte wiederholt.