Was du tust, wenn eine Sicherheitslücke in einem WordPress-Plugin veröffentlicht wird

Fast jeden Tag wird eine neue Sicherheitslücke in einem WordPress-Plugin veröffentlicht. Die meisten brauchen nichts weiter als das nächste reguläre Update. Einige brauchen heute Aufmerksamkeit: die, die aktiv ausgenutzt werden, die keinen Login brauchen oder die in einem Plugin stecken, das auf Dutzenden Kundenseiten läuft. Diese Anleitung ist eine Routine für diesen Tag: wie du schnell entscheidest, ob eine Lücke dich betrifft, wie du jede betroffene Seite findest und was du nach dem Update tust.

Schritt 1: in fünf Minuten entscheiden, ob es dringend ist

Lies die Meldung selbst (Patchstack, Wordfence oder WPScan), nicht nur die Schlagzeile. Vier Fragen bestimmen, wie schnell du handelst:

• Wird sie ausgenutzt? Eine Meldung, die von beobachteten Angriffen spricht, rückt ganz nach oben auf deine Tagesliste.
• Braucht sie einen Login? Eine Lücke, die ein anonymer Besucher nutzen kann, ist weit gefährlicher als eine, für die ein Administratorkonto nötig ist.
• Was kann ein Angreifer tun? Dateien hochladen, Code ausführen oder Administratorkonten anlegen ist schlimmer als ein reflektiertes XSS, das einen Klick braucht.
• Auf wie vielen deiner Seiten läuft es? Eine Seite ist eine Aufgabe; vierzig Seiten sind ein Projekt mit Frist.

Lautet die Antwort auf die ersten beiden Fragen ja, behandle es als dringend: betroffene Seiten heute, nicht bei der nächsten Wartungsrunde.

Schritt 2: jede betroffene Seite finden

Du brauchst pro Seite zwei Fakten: Ist das Plugin installiert (aktiv oder nicht), und welche Version läuft. Inaktive Plugins zählen mit. Der verwundbare Code liegt weiterhin auf dem Server und ist oft noch direkt erreichbar.

Mit WP-CLI dauert das Sekunden pro Seite:

wp plugin list --name=ninja-forms --fields=name,status,version

Ohne WP-CLI schaust du unter Plugins in wp-admin nach oder in die readme.txt des Plugins. Trage das Ergebnis in eine Liste ein: Seite, installiert ja oder nein, Version, Version mit Fix. Diese Liste ist deine Checkliste für den Rest des Tages und danach dein Nachweis für den Kunden.

Schritt 3: betroffene Seiten aktualisieren, die gefährdetsten zuerst

Fang mit den Seiten an, bei denen ein Angriff am meisten schadet: Onlineshops, Seiten mit vielen Formularen oder Benutzerkonten und Seiten mit viel Traffic. Stell vor jedem Update sicher, dass es ein aktuelles Backup gibt, das du wirklich wiederherstellen kannst.

Sicherheitsupdates sind meist klein, aber nicht immer. Manche Hersteller liefern den Fix in einem größeren Release mit anderen Änderungen. Ist die Version mit dem Fix ein großer Sprung oder verarbeitet das Plugin Formulare oder den Checkout, teste es nach Möglichkeit zuerst auf einer Kopie der Seite und prüfe danach die wichtigsten Seiten.

Kannst du heute nicht aktualisieren, etwa weil der Fix noch nicht erschienen ist oder das Update etwas kaputt macht, verringere stattdessen das Risiko: Deaktiviere das Plugin, wenn die Seite einen Tag ohne auskommt, oder blockiere den verwundbaren Endpunkt in deiner Firewall, wenn die Meldung ihn nennt. Sag dem Kunden, was du getan hast und warum.

Schritt 4: testen, wofür das Plugin da ist

Ein erfolgreiches Update ist nicht dasselbe wie eine Seite, die funktioniert. Teste nach dem Update, wofür das Plugin da ist. Bei einem Formular-Plugin schickst du eine echte Testeinsendung und prüfst, ob die E-Mail ankommt. Bei einem Shop-Plugin machst du eine Testbestellung bis zur Zahlung. Ein Formular, das still aufhört zu senden, kann einen Kunden eine Woche an Anfragen kosten, bevor es jemand merkt.

Schritt 5: prüfen, ob die Seite schon getroffen wurde

Das Update schließt die Lücke. Es entfernt nichts, was ein Angreifer vor dem Update hinterlassen hat. Wurde die Lücke ausgenutzt, bevor du gepatcht hast, prüfe jede betroffene Seite auf:

• Administratorkonten, die du nicht kennst;
• PHP-Dateien im Uploads-Ordner, der nur Medien enthalten sollte;
• kürzlich geänderte Dateien in Plugins und Themes, die du nicht aktualisiert hast;
• unbekannte geplante Aufgaben oder Weiterleitungen, die du nicht eingerichtet hast.

Findest du Anzeichen für einen Einbruch, stelle ein Backup von vor dem Angriffszeitraum wieder her, aktualisiere sofort und ändere alle Passwörter und die Sicherheitsschlüssel in wp-config.php. Patchen allein reicht nicht.

Schritt 6: den Kunden kurz informieren

Kunden lesen selten Sicherheitsnachrichten, aber sie merken, wenn ihre Agentur am Ball war. Eine kurze Nachricht genügt: was das Problem war, ob ihre Seite betroffen war oder nicht, was du getan hast und wann. So wird unsichtbare Arbeit zu sichtbarem Wert, und es gehört auch in deinen nächsten Wartungsbericht.

Beim nächsten Mal schneller

• Führe eine Liste, welche Plugins auf welchen Seiten laufen, damit Schritt 2 nur Minuten dauert.
• Folge einer oder zwei Quellen für Meldungen, nicht zehn.
• Sorge dafür, dass jede Seite ein Backup hat, das du wirklich schon einmal wiederhergestellt hast.
• Vereinbare vorab mit Kunden, dass dringende Sicherheitsupdates außerhalb des normalen Plans passieren.

Wie Verploy mit Plugin-Sicherheitslücken umgeht

Verploy zeigt bekannte Sicherheitslücken in den Plugins und Themes jeder verbundenen Seite, sodass du sofort siehst, welche Seiten betroffen sind. Jedes Update wird geprüft, und die riskanten werden zuerst auf einer Kopie getestet, einschließlich Formularen und Checkout. Nächtliche Backups kommen mit einem Wiederherstellungstest, und wenn eine Seite nach dem Livegang kaputtgeht, setzt Verploy sie zurück. Mehr zu WordPress-Sicherheitslücken überwachen.