WordPress-Plugins aktualisieren: was passiert, wenn du es nicht tust

In fast jedem WordPress-Backend steht eine kleine Zahl neben „Plugins". Sie stört niemanden. Man klickt sie weg, weil gerade etwas anderes dran ist, und beim nächsten Login ist die Zahl größer. Das Bemerkenswerte daran: Es passiert nichts. Die Seite lädt, das Kontaktformular verschickt, der Shop kassiert. Genau darin liegt das Problem. Die Kosten des Nichtstuns sind unsichtbar, bis sie es nicht mehr sind, und dann sind sie es auf einen Schlag.

Dieser Beitrag erklärt, was zwischen Update-Hinweis und Ernstfall tatsächlich passiert, und zwar aus der Perspektive derer, die diese Updates schreiben. Wir bauen selbst WordPress-Plugins, wir veröffentlichen die Aktualisierungen, um die es hier geht, und wir sehen, was danach passiert.

Warum ein Update-Hinweis keine Bitte um Ordnung ist

1. Ein Sicherheitsupdate macht die Lücke erst öffentlich

Das ist der Punkt, den kaum jemand kennt, und er dreht die Intuition um. Solange eine Sicherheitslücke unentdeckt in einem Plugin schlummert, weiß niemand von ihr. In dem Moment, in dem der Entwickler sie schließt und die neue Version veröffentlicht, entsteht etwas Neues: ein öffentlicher Vergleich zwischen vorher und nachher. WordPress-Plugins stehen unter der GPL, ihr Quelltext ist offen, und jede Version bleibt im Verzeichnis abrufbar. Zwei Fassungen nebeneinanderzulegen und zu sehen, welche Zeile sich geändert hat, ist Routine.

Damit ist die Veröffentlichung eines Sicherheitsupdates zugleich eine Wegbeschreibung zur Lücke in der alten Fassung. Das ist kein Argument gegen Updates, sondern das stärkste Argument für schnelle Updates. Der gefährlichste Zeitraum im Leben einer Sicherheitslücke beginnt nicht mit ihrer Entstehung, sondern mit ihrer Behebung. Wer drei Wochen später aktualisiert, hat drei Wochen lang eine dokumentierte Schwachstelle betrieben.

2. Niemand greift dich an, es scannt dich jemand

Der häufigste Einwand lautet: „Meine Seite ist doch viel zu klein, da will niemand rein." Das setzt voraus, dass am anderen Ende ein Mensch sitzt, der auswählt. Tut er nicht. Was läuft, sind automatische Scans, die Adresslisten abarbeiten und nach Fingerabdrücken suchen: nach Pfaden, die es nur bei einem bestimmten Plugin gibt, nach Versionsangaben in öffentlich lesbaren Dateien, nach Antworten, die eine bestimmte Fassung verraten.

Für diesen Ablauf ist es gleichgültig, ob deine Seite zehn oder zehntausend Besucher hat. Interessant ist nicht deine Reichweite, sondern der Server, das Postfach für Spamversand und der Platz für Weiterleitungen. Eine kleine Seite ist deshalb kein schlechteres Ziel, sondern nur ein weniger auffälliges. Das ist übrigens der Grund, warum Einbrüche oft monatelang unbemerkt bleiben.

3. Ein Plugin ist mehr als der Code, den der Entwickler geschrieben hat

Fast jedes größere Plugin bringt fremde Bibliotheken mit: für PDF-Erzeugung, Bildbearbeitung, Zahlungsanbindung, Diagramme. Die liegen im Plugin-Ordner und werden mit ausgeliefert. Wird in einer solchen Bibliothek eine Lücke bekannt, hängt es allein am Plugin-Anbieter, ob die aktualisierte Fassung bei dir ankommt. Du kannst diese Abhängigkeiten im Backend nicht sehen, und du kannst sie auch nicht selbst aktualisieren.

Aus Entwicklersicht ist das ein guter Teil unserer Update-Arbeit, der von außen komplett unsichtbar bleibt. Ein Release, das im Changelog nur „aktualisierte Abhängigkeiten" nennt, sieht nach nichts aus und kann trotzdem der wichtigste des Quartals sein.

4. Das gefährlichste Plugin ist das aufgegebene

Ein Plugin, das seit zwei Jahren keine Aktualisierung bekommen hat, ist nicht deshalb ungefährlich, weil nichts passiert. Es ist gefährlich, weil nichts mehr passieren wird. Wenn dort eine Lücke gefunden wird, kommt kein Update mehr, und du erfährst es im Regelfall nicht.

Wie verbreitet das ist, haben wir bei einer eigenen Recherche gesehen. Für unsere Marktübersicht haben wir deutschsprachige Vergleichsartikel geprüft und die empfohlenen Plugins an der Quelle nachgeschlagen. In einem aktuellen Artikel mit zwanzig Empfehlungen waren fünf davon im WordPress-Verzeichnis geschlossen. Der Artikel empfiehlt sie weiterhin, und wer sie installiert hat, sieht in seiner Plugin-Liste genau dasselbe wie vorher: einen Namen, eine Versionsnummer, keinen Hinweis. Ein geschlossenes Plugin verschwindet nicht von deiner Seite, es hört nur auf, Updates zu liefern.

Wie das bei uns aussieht

Wir stehen auf der anderen Seite dieses Vorgangs, deshalb hier der unglamouröse Teil.

Es braucht eine Adresse, an die jemand schreiben kann. Wer eine Lücke findet, muss sie melden können, ohne über ein Kontaktformular zu gehen, das im Vertrieb landet. Wir betreiben dafür eine eigene Sicherheitsadresse. Das ist keine große Sache, aber es ist der Unterschied zwischen einem Hinweis, der ankommt, und einem, der irgendwann öffentlich wird, weil niemand geantwortet hat.

Wir veröffentlichen lieber klein und oft als groß und selten. Ein Beispiel von dieser Woche: Am 17. August ist unsere Version 2.3.0 erschienen, am 18. August die 2.3.1, weil der Einwilligungsbanner Besuchern erneut angezeigt wurde, die bereits entschieden hatten. Keine Sicherheitslücke, sondern ein Ärgernis. Trotzdem geht so etwas sofort raus und wartet nicht auf das nächste große Paket. Der Grund ist handfest: Ein Release, das eine Sache ändert, lässt sich prüfen. Ein Release, das acht Dinge ändert, kann niemand mehr auf die eine Änderung zurückführen, die das Layout zerlegt hat.

Und der Teil, den Anbieter ungern schreiben: Updates gehen manchmal schief. Das ist keine Theorie, das ist unser Alltag genauso wie deiner. Wer behauptet, seine Aktualisierungen seien risikofrei, hat entweder wenige Nutzer oder eine kurze Erinnerung. Die richtige Antwort darauf ist nicht, seltener zu aktualisieren, sondern die einzelne Aktualisierung klein zu halten und wiederherstellbar zu machen. Wenn bei dir nach einem Update eine weiße Seite steht, ist das ärgerlich und in zehn Minuten behoben. Ein Einbruch ist es nicht.

Der Satz „Never touch a running system" stammt aus einer Welt, in der das System in einem Raum stand und die Tür abgeschlossen war. Deine WordPress-Installation steht im Internet. Ihre Umgebung ändert sich täglich, auch wenn du nichts anfasst: PHP-Versionen, Browser, der WordPress-Kern, und die Werkzeuge derer, die nach alten Versionen suchen. Ein System, das sich nicht bewegt, wird in dieser Umgebung nicht stabiler, sondern nur älter.

Was der Cyber Resilience Act ab dem 11. September ändert

Der Cyber Resilience Act ist eine EU-Verordnung für Produkte mit digitalen Elementen, und dazu gehört Software. Ab dem 11. September 2026 greifen die Meldepflichten: Aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle müssen gemeldet werden. Der Rest der Pflichten folgt gestaffelt.

Für Hersteller läuft es im Kern auf drei Dinge hinaus, die vorher freiwillig waren: Schwachstellen geordnet bearbeiten, über einen benannten Zeitraum Sicherheitsupdates bereitstellen, und einen erreichbaren Kontaktpunkt dafür haben. Wer schon einmal versucht hat, den Entwickler eines Plugins zu erreichen, das seit 2021 nicht aktualisiert wurde, versteht sofort, welches Problem hier adressiert wird.

Zwei Einschränkungen gehören ehrlicherweise dazu. Erstens ist die Frage, wer bei freier Open-Source-Software als Hersteller im Sinne der Verordnung gilt, genau der Punkt, der noch strittig ist. Wir beschreiben das hier, wir entscheiden es nicht für dich. Dieser Beitrag ist keine Rechtsberatung, und für den eigenen Fall führt kein Weg an einer fachlichen Prüfung vorbei. Zweitens: Der CRA aktualisiert deine Website nicht. Er verändert, was du von einem Anbieter erwarten darfst, nicht wer die Aktualisierung einspielt. Das bleibt deine Aufgabe, und wenn du Websites für Kunden betreust, wird es eine vertragliche.

Praktisch heißt das für die Auswahl: Ein Plugin, das weder eine Sicherheitsadresse noch einen Supportzeitraum nennt, ist nicht automatisch schlecht. Aber es sagt dir etwas darüber, wie viel Struktur dahintersteht, und diese Auskunft bekommst du künftig ohne Nachfragen.

Praktisch: aktualisieren, ohne sich die Seite zu zerlegen

Ein Backup, das du schon einmal zurückgespielt hast. Ein Backup, das noch nie wiederhergestellt wurde, ist keine Sicherung, sondern eine Hoffnung. Einmal ausprobieren, dann weißt du, wie lange es dauert und ob es überhaupt funktioniert. Welche Werkzeuge dafür taugen, steht im Beitrag über Backup-Plugins für WordPress.

Automatische Updates für Sicherheitsreleases, manuelle für alles andere. WordPress kann Plugins selbstständig aktualisieren. Für kleine Korrekturversionen ist das die richtige Einstellung, weil die Zeit zwischen Veröffentlichung und Einspielen dort am meisten zählt. Bei großen Versionssprüngen, die neue Funktionen bringen, lohnt der manuelle Blick.

Dreißig Sekunden ins Changelog. Steht dort „security fix“, ist die Sache dringend und nicht verhandelbar. Steht dort eine neue Funktion, die du nicht brauchst, kannst du bis zum Wochenende warten.

Eine Testumgebung, sobald die Seite Geld verdient. Bei einem Blog reicht ein Backup. Bei einem Shop oder einem Mitgliederbereich willst du das Update einmal woanders gesehen haben, bevor es Kunden sehen.

Zweimal im Jahr Kassensturz. Jedes Plugin, das du nicht mehr brauchst, ist eine Angriffsfläche ohne Gegenwert. Deaktivieren genügt nicht, denn die Dateien liegen weiterhin auf dem Server. Löschen.

Woran du ein Plugin erkennst, das dich hängen lässt

Häufige Fragen