WordPress Sicherheitsupdate 7.1.2: Wer patcht deine Website?

Am 22. September 2026 ist WordPress 7.1.2 erschienen. Ein Security-Release, Schweregrad kritisch. Die interessante Frage ist aber nicht, was in dem Update steckt. Sondern ob irgendjemand in deinem Unternehmen sagen kann, wann es auf eurer Website gelandet ist. Und wer das überhaupt prüft.

Was im WordPress Sicherheitsupdate 7.1.2 steckt

Behoben wurde eine Schwachstelle, die unter CVE-2026-87902 geführt wird. Laut WordPress kann ein nicht authentifizierter Angreifer unter bestimmten Bedingungen dafür sorgen, dass beim Auflösen einer Seitenvorlage eine von ihm gewählte, lesbare lokale PHP-Datei außerhalb der aktiven Theme-Verzeichnisse eingebunden wird. Im ungünstigen Fall führt das zur Ausführung von fremdem Code auf deinem Server.

Zwei Worte daraus sind wichtig. Nicht authentifiziert heißt: kein Login, kein Passwort, keine Benutzerrolle nötig. Es reicht, dass die Website erreichbar ist. Und lokale PHP-Datei heißt: Es geht nicht um ein hübsches Defacement der Startseite, sondern um den Server darunter.

Gemeldet hat die Lücke Robert Ressl über den verantwortlichen Weg, der Fix wurde in alle Zweige zurückportiert, die noch Sicherheitsupdates bekommen, aktuell bis hinunter zu 4.7. Wer also noch eine ältere Installation betreibt, ist nicht automatisch außen vor. Aktiv gepflegt wird trotzdem nur die jeweils neueste Version.

Auto-Updates sind ein Sicherheitsnetz, keine Wartung

WordPress schreibt zum Release, dass der Update-Vorgang bei Websites mit automatischen Hintergrund-Updates von allein startet. Klingt beruhigend. In der Praxis ist es der Punkt, an dem die meisten Firmenwebsites durchrutschen.

Denn automatische Updates sind auf vielen Installationen deaktiviert. Meistens nicht aus Böswilligkeit, sondern weil vor zwei Jahren ein Update ein Plugin zerlegt hat und danach jemand entschieden hat: nie wieder automatisch. Die Entscheidung ist nachvollziehbar. Nur hat danach niemand den manuellen Ablauf definiert, der sie ersetzen müsste.

Dazu kommt: Managed Hosting patcht oft brav den Core und lässt Themes und Plugins liegen. Genau dort sitzt aber der größere Teil der Angriffsfläche, weil dort der Code steht, den niemand außerhalb deiner Website je geprüft hat. Ein Core-Update allein beweist also wenig.

Und selbst wenn alles automatisch läuft: Ein Update ist erst dann eingespielt, wenn es durchgelaufen ist. Bricht es ab, weil der Speicher knapp war oder Dateirechte im Weg standen, bleibt die Seite auf dem alten Stand. Gemeldet wird das in aller Regel niemandem. Deshalb gehört zu jedem automatischen Ablauf eine Stelle, an der jemand nachsieht, ob er getan hat, was er sollte.

Die eigentliche Frage lautet: Wer ist zuständig?

Ein Szenario, das wir häufiger sehen als uns lieb ist. Die Website wurde vor drei Jahren relauncht. Die damalige Agentur ist raus, freundlich, aber raus. Das Marketing hat einen Redakteurs-Zugang und kann Texte ändern. Den Admin-Zugang hat noch der Praktikant von damals in einem Passwort-Manager, den es nicht mehr gibt. Der Hoster verweist auf seine AGB, in denen steht, dass die Anwendungsebene Sache des Kunden ist.

Und jetzt erscheint ein kritisches Update. Niemand ist verantwortlich, also passiert nichts. Das ist kein technisches Problem, das ist ein Organisationsproblem. Technisch dauert so ein Update ein paar Minuten.

Wir würden deine Website ja loben. Aber wir lügen ungern: Wenn du auf die Frage, wer bei euch Updates einspielt, einen Namen nennen musst und keiner einfällt, ist die Antwort schon das Ergebnis.

Was ein brauchbarer Wartungsablauf enthält

Es braucht keinen Konzernprozess. Es braucht sieben Punkte, die aufgeschrieben sind und einen Namen tragen:

• Inventar. Welche Website läuft auf welchem System, in welcher Version, bei welchem Hoster. Eine Zeile pro Seite reicht.
• Ein Name. Eine Person, die zuständig ist. Kein Verteiler, keine Abteilung.
• Feste Fenster. Routine-Updates in einem festen Rhythmus, Security-Releases außer der Reihe innerhalb weniger Tage.
• Staging. Eine Kopie der Seite, auf der Updates zuerst laufen. Damit endet die Angst vor dem Update-Knopf.
• Backup mit Restore-Test. Ein Backup, das noch nie zurückgespielt wurde, ist eine Vermutung, kein Backup.
• Monitoring. Eine Benachrichtigung, wenn die Seite down ist oder sich Dateien ändern, die sich nicht ändern sollten.
• Protokoll. Was wann eingespielt wurde. Das kostet zwei Minuten und beantwortet im Ernstfall die teuerste Frage überhaupt.

Rechne es einmal gegen. Eine kompromittierte Website bedeutet im Minimum: Bereinigung, neu aufsetzen aus einem sauberen Backup, Passwörter tauschen, Suchmaschinen-Warnungen wieder loswerden, im Zweifel eine Meldung nach Artikel 33 DSGVO, wenn personenbezogene Daten betroffen sein könnten. Dazu die Tage, an denen dein wichtigster Vertriebskanal offline ist. Dagegen steht ein Wartungsablauf, der pro Monat unter einer Stunde braucht.

Sicherheit ist die unsichtbare Hälfte von Webdesign

Bei Websites wird fast nur über das gesprochen, was man sieht: Gestaltung, Texte, Ladezeit, Formulare. Der Betrieb danach ist unsichtbar und taucht deshalb in keinem Angebot auf, das jemand spannend findet. Bis er ausfällt.

Es ist derselbe Reflex, der auch beim Thema Barrierefreiheit lange gegriffen hat: Was nicht sofort weh tut, wandert nach hinten. Nur meldet sich die eine Baustelle irgendwann per Abmahnung und die andere per Anruf des Hosters am Sonntagabend.

Fazit

WordPress 7.1.2 ist schnell eingespielt. Der Punkt ist nicht dieses eine Update, sondern das nächste, das in ein paar Wochen kommt, und das danach. Wenn dafür kein Ablauf und keine zuständige Person existiert, ist jede einzelne Meldung Glückssache. Stand: September 2026, und der nächste kritische Fix ist nur eine Frage der Zeit.

Du weißt nicht, in welchem Zustand eure Website gerade ist? Wir schauen einmal drüber und sagen dir ehrlich, was wir finden: kostenlose Website-Analyse.