Am 19. August ist WordPress 7.1 erschienen, benannt nach der Jazzpianistin Mary Lou Williams. Über 800 Menschen haben daran mitgearbeitet, 170 davon zum ersten Mal, und mehr als 1500 Verbesserungen und Fehlerbehebungen sind eingeflossen.
Die interessantere Zahl steht aber woanders. Sie lautet: fünf.
Sechs Wochen, fünf Releases
So sah die 7er-Reihe seit Anfang Juli aus. Am 9. Juli erschien 7.0.1, ein reines Wartungsrelease. Acht Tage später, am 17. Juli, folgte 7.0.2 — mit einer kritischen und einer hoch eingestuften Lücke. Am 6. August kam 7.0.3 mit gleich zwölf Lücken, am 12. August 7.0.4 mit einer, über die sich fremder Code ausführen liess. Und am 19. August dann 7.1.
Drei Sicherheitsreleases in vier Wochen. Bei 7.0.2 war die Lage so ernst, dass wordpress.org erzwungene Updates aktivierte — betroffene Installationen wurden ohne Zutun der Betreiber aktualisiert. Das ist ein Werkzeug, das das Projekt nur selten einsetzt.
Die einzelnen Lücken haben wir jeweils beschrieben: die zwölf Lücken in 7.0.3, die Imagick-Lücke in 7.0.4 und die aktive Ausnutzung von XSS2Shell. Hier geht es um etwas anderes: um das Muster.
Warum so dicht?
Drei Dinge kommen zusammen, und keines davon ist ein Grund zur Panik.
7.0 war ein grosser Umbau. Die Hauptversion erschien im Mai, nachdem sie mehrfach verschoben worden war. Sie brachte tiefgreifende Änderungen mit — Block-Themes laufen im Editor jetzt in einem iframe, dazu kamen Vorarbeiten für den Wechsel auf React 19. Je grösser der Eingriff ins Fundament, desto mehr findet sich danach. Das ist keine WordPress-Eigenheit, das gilt für jede Software.
Die drei Lücken hatten nichts miteinander zu tun. Die eine sass auf der Anmeldeseite, die nächste in der Bildverarbeitung über Imagick und Ghostscript, die dritte in einer ganz anderen Ecke. Es war also nicht eine Ursache, die mehrfach nachgebessert werden musste, sondern drei unabhängige Funde in kurzer Folge.
7.1 war ohnehin geplant. Die neue Hauptversion kam zum Abschluss der WordCamp US in Phoenix — ein Termin, der lange feststand. Sie ist kein Notfall-Release, sondern der reguläre Rhythmus.
Bleibt die unangenehme Frage: Wird WordPress unsicherer? Die ehrliche Antwort lautet: Das lässt sich aus sechs Wochen nicht ablesen. Dass Lücken gefunden und binnen Tagen geschlossen werden, ist das Gegenteil eines schlechten Zeichens. Beunruhigend wäre eine Lücke, die monatelang offen bleibt — und ausgerechnet das ist hier nicht passiert.
Was 7.1 bringt
Für die tägliche Arbeit sind vier Dinge relevant:
Responsives Gestalten ohne CSS. Layouts lassen sich jetzt direkt im Site-Editor für verschiedene Bildschirmgrössen einstellen. Wer bisher für jede Anpassung an der mobilen Ansicht eigenes CSS brauchte, kommt in vielen Fällen ohne aus.
Die Adminleiste bleibt sichtbar. In allen Editoren, durchgehend. Klingt nach einer Kleinigkeit, spart aber im Alltag viele Klicks.
Ein eigener Medien-Editor. Zuschneiden nach Seitenverhältnis oder frei, spiegeln, drehen, Metadaten bearbeiten — in einem Arbeitsschritt statt über drei Umwege.
Notizen mit Erwähnungen. Wer zu mehreren an Inhalten arbeitet, kann Anmerkungen an bestimmte Textstellen hängen und Kolleginnen direkt ansprechen.
Dazu kommen zwei neue Blöcke, Playlist und Tabs.
Der Punkt, auf den es ankommt
Und hier wird es für Betreiber praktisch. Die drei Sicherheitsupdates der letzten Wochen sind auf den meisten Installationen von allein eingespielt worden — WordPress aktualisiert Minor-Releases standardmässig automatisch, also den Schritt von 7.0.3 auf 7.0.4.
Bei 7.1 ist das anders. Der Sprung von 7.0.x auf 7.1 ist eine neue Hauptversion, und die übergeht die automatische Aktualisierung, sofern sie nicht ausdrücklich dafür freigeschaltet wurde. Wer also darauf vertraut, dass sich WordPress schon selbst aktuell hält, bleibt auf 7.0.4 stehen — bis jemand hingeht und den Knopf drückt.
Solange 7.0.4 Sicherheitsupdates bekommt, ist das kein Notfall. Aber es ist der Moment, in dem aus «läuft von selbst» wieder «jemand muss hinschauen» wird. Und genau an dieser Stelle bleiben Installationen jahrelang zurück, ohne dass es jemand merkt.
Was jetzt zu tun ist
Nachsehen, auf welcher Version Sie stehen. Im Backend unter *Dashboard → Aktualisierungen*. Steht dort 7.0.4, haben die automatischen Updates funktioniert — der Schritt auf 7.1 fehlt aber noch.
Vor dem Sprung auf 7.1 die Erweiterungen prüfen. Hauptversionen ändern mehr als Fehlerbehebungen. Der iframe-Modus für Block-Themes und die Vorarbeiten für React 19 erhöhen das Risiko, dass ältere Plugins oder eigene Blöcke stolpern. Ein Blick in die Plugin-Liste und ein Test in einer Kopie sind hier gut investierte halbe Stunde.
Nicht ewig warten. Jede Hauptversion, die man auslässt, macht den nächsten Schritt grösser. Wer bei WordPress 5 hängengeblieben ist, weiss, wie das endet.
Klären, wer zuständig ist. Das ist die Frage, an der es in der Praxis am häufigsten scheitert. Nicht weil niemand könnte, sondern weil alle annehmen, jemand anderes tue es.
Wie wir das handhaben
Für Websites, die bei uns in Wartung sind, verfolgen wir die Releases, spielen Sicherheitsupdates zeitnah ein und prüfen Hauptversionen vorher in einer Kopie, statt sie direkt auf die Live-Seite zu lassen. Das ist Teil des Wartungsvertrags mit Monitoring.
Ohne Wartungsvertrag gilt der Rat von oben: einmal nachsehen, welche Version läuft. Die sechs Wochen seit Anfang Juli haben gezeigt, wie schnell sich das Bild ändern kann — und der aktuelle Befund zu ungepatchten Lücken zeigt, dass genau daran heute die meisten Angriffe ansetzen.