Sicherheitslücken in WordPress-Plugins: Was Sie nach einer Meldung jetzt prüfen sollten

Bei Sicherheitslücken in WordPress-Plugins klären Sie nach einer Meldung drei Fragen in dieser Reihenfolge: Ist Ihre Website betroffen, wie eilig ist es, und war schon jemand auf der Website? Sie sind betroffen, wenn das gemeldete Plugin auf Ihrem Server liegt und seine Version in den Bereich fällt, den die Meldung nennt. Prüfen Sie dabei auch deaktivierte Plugins. Drei Angaben derselben Meldung zeigen, wie eilig es ist: ob ein Angreifer eine Anmeldung braucht, ob schon Angriffe bekannt sind und ob es ein Update gibt.

Vor dem Update ziehen Sie eine Sicherung, danach prüfen Sie Spuren. Denn die dritte Frage beantwortet das Update nicht: Es schließt die Lücke, entfernt aber kein Administratorkonto und keine Datei außerhalb des Plugin-Ordners, die jemand vorher über die Lücke angelegt hat. Wenn Sie bei dieser Prüfung etwas finden, das Sie nicht zuordnen können und das seit dem Tag entstanden ist, an dem die Lücke ausnutzbar wurde, geht es nicht mehr um ein Update, sondern um eine Bereinigung.

Bin ich von der gemeldeten Plugin-Lücke betroffen?

Ihre Website ist betroffen, wenn die installierte Version des Plugins in den Bereich fällt, den die Meldung als verwundbar angibt. Suchen Sie in der Meldung nach zwei Angaben: bis zu welcher Version das Plugin betroffen ist und mit welcher Version der Hersteller die Lücke geschlossen hat. Ihre eigene Version finden Sie in WordPress oder per Befehl auf dem Server.

Ein echtes Beispiel zeigt, wo in einer Meldung die beiden Versionsangaben stehen. Im Verzeichnis der Common Vulnerabilities and Exposures (CVE) betrifft der Eintrag CVE-2023-40000 das Plugin LiteSpeed Cache, genauer eine Lücke für Cross-Site-Scripting (XSS): Angreifer konnten ohne Anmeldung fremden Programmcode einschleusen, der als Teil der Seite im Browser lief. Der Eintrag nennt beide Angaben: Betroffen sind alle Versionen bis einschließlich 5.7, geschlossen ist die Lücke ab Version 5.7.0.1. Fehlt in einer Meldung die Version, die die Lücke schließt, sehen Sie im Änderungsprotokoll (Changelog) des Plugins nach, ob es inzwischen ein Update gibt.

Ihre eigene Version lesen Sie in der Plugin-Liste von WordPress ab. Die Liste zeigt laut WordPress-Dokumentation alle installierten Plugins, aktive wie inaktive, mit einer Ausnahme: Die Must-Use-Plugins (MU-Plugins) fehlen darin. WordPress lädt sie ohne Aktivierung aus dem Ordner wp-content/mu-plugins. Wenn Sie Zugang zum Server per SSH haben und dort das WordPress Command Line Interface (WP-CLI) installiert ist, sehen Sie beides mit diesen Befehlen im Hauptverzeichnis von WordPress:

# Alle Plugins mit Status, installierter Version und verfügbarem Update
wp plugin list
# Must-Use-Plugins, die in der Plugin-Liste von WordPress fehlen
wp plugin list --status=must-use

Die Befehle schreiben nichts. In der Spalte version steht die installierte Version, in update_version die Version, die zum Update bereitsteht (Stand Oktober 2026).

Zählen deaktivierte Plugins und Theme-Ordner mit?

Ja, prüfen Sie deaktivierte Plugins wie aktive. Wenn Sie ein Plugin deaktivieren, lädt WordPress es nicht mehr, löscht aber keine Datei. Und eine Plugin-Datei lässt sich unter Umständen direkt über ihre Adresse aufrufen, an WordPress vorbei. Ist das ausgerechnet die Datei mit der Lücke, läuft sie, ob das Plugin aktiv ist oder nicht. Das Plugin-Handbuch rät Entwicklern zwar, solche direkten Aufrufe abzufangen, aber ob ein Plugin es tut, entscheidet sein Entwickler. Ungenutzte Plugins löschen Sie deshalb am besten ganz; dazu rät auch die Härtungsanleitung von WordPress.

Bei zwei Untersuchungen gehackter WordPress-Websites habe ich 2026 den Plugin-Bestand durchgesehen, und beide Male lag auf dem Server deutlich mehr, als WordPress lud. Auf der einen Website waren es gut 30 Plugins, von denen nur eine Handvoll aktiv war. Auf der anderen lag ein nicht aktives Theme mit einem mitgelieferten Skript, für das seit Jahren eine schwere Lücke bekannt ist. Wer nur die aktiven Plugins geprüft hätte, hätte in beiden Fällen etwas übersehen. Sehen Sie deshalb auch in die Ordner nicht aktiver Themes.

Wie dringend ist eine Sicherheitslücke in einem WordPress-Plugin?

Drei Angaben der Meldung entscheiden, wie eilig eine Plugin-Lücke ist: ob ein Angreifer ohne Anmeldung zum Ziel kommt, ob schon Angriffe gemeldet sind und ob ein Update bereitsteht. Der Schweregrad nach dem Common Vulnerability Scoring System (CVSS) ergänzt das, sagt aber nichts darüber, ob die Lücke gerade angegriffen wird.

Der CVSS-Basiswert reicht von 0 bis 10. Nach der Spezifikation von CVSS 3.1 gilt 0,1 bis 3,9 als niedrig, 4,0 bis 6,9 als mittel, 7,0 bis 8,9 als hoch und ab 9,0 als kritisch. Der Wert beschreibt Eigenschaften der Lücke, die sich mit der Zeit nicht ändern.

Der CVSS-Vektor verrät, ob ein Angreifer ohne Anmeldung zum Ziel kommt: Unter „PR“ (Privileges Required) steht dort, ob er ein Konto braucht. „PR:N“ heißt, er braucht vor dem Angriff keinerlei Zugang zu Einstellungen oder Dateien. Bei „PR:L“ braucht er ein Konto mit einfachen Rechten, bei „PR:H“ eines mit weitreichenden, etwa ein Administratorkonto. Der Eintrag zu LiteSpeed Cache trägt „PR:N“ und den Basiswert 8,3, Stufe „High“. Für diese Lücke brauchte also niemand ein Konto.

Die Meldung nennt im Text, ob schon angegriffen wird; in CVSS 4.0 steht dafür die Angabe „Attacked“. Diese Angabe ist allerdings eine Momentaufnahme, und die LiteSpeed-Lücke zeigt, was das bedeutet. Der CVE-Eintrag vermerkt mit Stand 9. Mai 2024 als Ausnutzungsstand „poc“, also Beispielcode für einen Angriff. Im Jahresbericht von Patchstack steht dieselbe Lücke dagegen auf Platz 1 der 2025 am häufigsten angegriffenen. Patchstack, ein Hersteller mit eigener Schutzlösung für WordPress, zählt dafür die Angriffsversuche, die er auf den Websites seiner Kunden abgewehrt hat. Und die LiteSpeed-Lücke war in dieser Rangliste nicht die einzige ältere: Nur vier der zehn Spitzenreiter stammten aus dem Jahr 2025. Eine Lücke wird also nicht harmlos, weil sie älter ist.

Bei einer frisch veröffentlichten Lücke kann es außerdem sehr schnell gehen. Laut demselben Bericht wurde etwa die Hälfte der Lücken mit hoher Tragweite binnen 24 Stunden ausgenutzt (Daten 2025, Stand Februar 2026). Wer Updates liegen lässt, lässt diese Lücken offen.

Wenn Sie die drei Angaben der Meldung nebeneinanderlegen, ergibt sich diese Reihenfolge, oben das Dringendste:

Woher weiß ein Angreifer, welche Version auf Ihrer Website läuft?

Er liest sie dort ab, wo die Website sie selbst nennt. Ein Plugin kann seine Versionsnummer zum Beispiel selbst in den Quelltext der Seite eintragen, in den sogenannten Generator-Eintrag. Bei meiner passiven Prüfung von Firmen-Startseiten im dritten Quartal 2026 stand die Versionsnummer mindestens eines von neun verbreiteten Plugins in 79.073 von 169.828 Messungen an WordPress-Seiten direkt im Quelltext (46,6 %).

Ein zweiter Weg führt über die Beschreibungsdatei readme.txt im Plugin-Ordner. Die Datei nennt unter „Stable tag“ die Version; maßgeblich ist laut Plugin-Handbuch aber die Haupt-PHP-Datei, die readme.txt ist also ein Indiz. In den Server-Logs einer WordPress-Website habe ich 2026 gesehen, wie ein Suchlauf nach diesen Dateien aussieht: In neun Tagen fragten Abrufe, die sich als gewöhnlicher Browser ausgaben, die readme.txt von mehr als 60 Plugin-Ordnern ab. Über 150 der rund 170 Anfragen kamen in drei einzelnen Minuten. Der Fall zeigt: Solche Suchläufe fragen nach einer Liste von Plugins, nicht nach Ihrer Website.

Ein dritter Weg führt über die Adressen der Dateien, die eine Website ausliefert: WordPress hängt dort den Zusatz ?ver= an, damit Browser nach einem Update die neue Datei laden. Bei einer passiven Prüfung einer Unternehmenswebsite habe ich 2026 rund ein Dutzend Plugins erkannt, und bei den meisten stand die Version in genau diesem Zusatz.

Den Abgleich Ihrer Version mit der Version, die die Lücke schließt, kann also auch jemand machen, der nur Ihre Website abruft. Prüfen Sie eine Meldung deshalb sofort selbst, statt bis zur nächsten Wartung zu warten.

Was tun Sie, wenn ein Update für das Plugin bereitsteht – und wenn nicht?

Gibt es ein Update, das die Lücke schließt, ziehen Sie direkt davor eine Sicherung und spielen es ein, bei großen Plugins von Hand. Gibt es noch keins, nehmen Sie das Plugin außer Betrieb: deaktivieren und löschen, wenn die Website ohne es auskommt. Braucht sie das Plugin, überbrücken Sie die Zeit bis zum Update.

Die Sicherung ist Ihr Weg zurück, falls das Update etwas zerbricht, und die WordPress-Dokumentation rät ohnehin, vor jedem Plugin-Update eine aktuelle Sicherung der Website zu haben. Die Anleitung für ein WordPress-Backup zeigt, wie Sie sie anlegen. Und wenn die Seite nach dem Update doch weiß bleibt, hilft der Beitrag zur weißen Seite nach einem Plugin-Update weiter.

Von Hand oder automatisch? Das hängt vom Plugin ab. Automatische Updates für Plugins gibt es seit WordPress 5.5, und Sie schalten sie je Plugin ein (Stand Oktober 2026). Für den WordPress-Kern und kleine Erweiterungen rate ich, die automatischen Sicherheitsupdates laufen zu lassen:

„Die Zeit zwischen ‚Lücke bekannt‘ und ‚Lücke ausgenutzt‘ schrumpft, und keine manuelle Update-Routine ist schnell genug für dieses Fenster. Automatische Updates aktiviert zu lassen ist deshalb eine der wenigen Maßnahmen, die mit diesem Tempo mithalten.“

— Sascha Fix

Für umfangreiche Plugins wie WooCommerce oder einen Page Builder empfehle ich dagegen Updates von Hand mit einem Backup direkt davor: Diese Erweiterungen greifen tief in die Seite ein, und wenn ein Update etwas zerbricht, macht die Sicherung den Fehler rückgängig. Bei einer Sicherheitsmeldung heißt „von Hand“ allerdings: jetzt, nicht beim nächsten Wartungstermin.

Und ohne Update? Das ist kein Sonderfall: Fast die Hälfte der Lücken, 46 %, hatte laut dem Patchstack-Bericht bei der Veröffentlichung noch keine Korrektur des Entwicklers (Daten 2025, Stand Februar 2026). Dann bleiben Ihnen drei Wege. Wenn die Website ohne das Plugin auskommt, löschen Sie es und suchen Ersatz. Lässt sich die betroffene Funktion im Plugin abschalten, schalten Sie sie ab. Oder Sie lassen Anfragen prüfen, bevor WordPress sie verarbeitet. Das übernimmt laut Härtungsanleitung von WordPress eine Web Application Firewall (WAF), entweder auf dem Webserver oder als vorgeschalteter Dienst. Allerdings fängt die Firewall eine bestimmte Lücke nur ab, wenn ihre Regeln das vorsehen, und auch dann ersetzt sie das Update nicht.

Was gilt, wenn das Plugin im Verzeichnis geschlossen ist?

Wenn das Plugin-Verzeichnis von WordPress.org ein Plugin schließt, kann es laut Plugin-Handbuch niemand mehr herunterladen oder im Backend installieren, und das Verzeichnis erzeugt auch keine Pakete zum Herunterladen mehr. Nach einer Sicherheitsmeldung bleiben die meisten Plugins geschlossen, bis das Problem behoben ist, heißt es dort weiter (Stand Oktober 2026). Auf Ihrer Website dagegen kann ein geschlossenes Plugin installiert und aktiv bleiben, wie der Fall der gehackten Elementor-Add-ons von BdThemes zeigt. Behandeln Sie es deshalb wie ein Plugin ohne Update.

Mit diesem Befehl sehen Sie, ob Ihre Plugins im Verzeichnis noch als aktiv geführt werden; auch er schreibt nichts:

wp plugin list --fields=name,version,wporg_status,wporg_last_updated

Bei Plugins, die nicht aus dem Verzeichnis stammen, bleiben die beiden letzten Spalten leer.

Reicht das Update, oder war schon jemand auf der Website?

Ein Update schließt die Lücke, nimmt aber niemandem einen Zugang, den er sich vorher über sie verschafft hat: ein Administratorkonto, eine zusätzliche Datei außerhalb des Plugin-Ordners, einen Eintrag in der Datenbank. Prüfen Sie deshalb nach dem Update, ob seit dem Tag, an dem die Lücke ausnutzbar wurde, jemand auf Ihrer Website war.

Das gilt genauso, wenn Sie ein verwundbares Plugin löschen, statt es zu aktualisieren, denn es geht um den Unterschied zwischen infiziert und kompromittiert. Infiziert heißt, es liegt etwas auf der Website, das dort nicht hingehört. Kompromittiert heißt, jemand hat einen Schlüssel, und den nimmt ihm keine Deinstallation ab.

Und spricht eine aktuelle Versionsnummer eine Website frei? Nicht unbedingt. Bei meiner passiven Prüfung von Firmen-Startseiten im dritten Quartal 2026 gab es 38 Messungen an befallenen WordPress-Seiten mit dem Plugin LayerSlider, also an Seiten, auf denen eine Einzelprüfung fremde Inhalte bestätigt hat, auf der Seite selbst oder in ihrer Fassung für Suchmaschinen. Davon zeigten 28 die höchste Hauptversion, die in der ganzen Messung vorkam. Unter allen 2.929 Messungen mit diesem Plugin waren es dagegen 31,3 %. Die höchste Hauptversion der Messung muss dabei nicht die aktuellste Version des Herstellers sein. Eine aktuelle Plugin-Version und ein Befall schließen sich aber nicht aus, und deshalb gehört die Spurenprüfung zum Update dazu.

Gehen Sie für die Spurenprüfung in dieser Reihenfolge vor. Die Befehle setzen wie oben SSH und WP-CLI voraus, laufen im Hauptverzeichnis von WordPress und schreiben nichts. Allerdings laden die wp-Befehle außer wp core verify-checksums WordPress und führen dabei den Code Ihrer Website aus, MU-Plugins eingeschlossen. Steckt darin Schadcode, kann er ein Konto sogar vor wp user list verstecken.

1. Stichtag festlegen

   Der Stichtag ist der Tag, an dem die Lücke ausnutzbar wurde; nehmen Sie dafür den Tag ihrer Veröffentlichung oder einen früheren, wenn die Meldung von Angriffen davor berichtet. Behalten Sie Sicherungen von vor diesem Tag, denn laut Härtungsanleitung von WordPress helfen sie beim Wiederaufbau, Sicherungen von danach bei der Frage, wie der Angreifer hereinkam.

2. Administratoren prüfen

   wp user list --role=administrator
   

   Die Spalte user_registered zeigt, wann ein Konto angelegt wurde. Ein Konto, das Sie nicht kennen und das nach dem Stichtag entstanden ist, ist eine Spur.

3. Plugin- und Kerndateien abgleichen

   wp plugin verify-checksums --all --strict
   wp core verify-checksums --include-root
   

   Der erste Befehl vergleicht Ihre Plugins mit den Prüfsummen von WordPress.org und meldet geänderte und hinzugefügte Dateien, mit --strict auch eine geänderte readme.txt; Plugins ohne Prüfsummen dort, etwa Kauf-Plugins, überspringt er mit einer Warnung. Der zweite prüft den WordPress-Kern und meldet mit --include-root fremde Dateien im Hauptverzeichnis.

4. Neue PHP-Dateien suchen

   find wp-content/mu-plugins wp-content/uploads -name '*.php' -newermt '2026-01-01' -ls
   

   Setzen Sie statt des Beispieldatums Ihren Stichtag ein. Der Befehl listet PHP-Dateien in den Ordnern der Must-Use-Plugins und der Uploads, die seit diesem Tag geändert wurden; fehlt der Ordner mu-plugins, meldet find das und sucht weiter. Eine PHP-Datei zwischen hochgeladenen Bildern kann eine Webshell sein, eine Fernsteuerung über die Adresszeile.

5. Zugriffsprotokolle sichern

   Fragen Sie Ihren Hoster nach den Zugriffsprotokollen (Access-Logs) ab dem Stichtag und sichern Sie sie zusammen mit der Website. Logs zeigen laut Härtungsanleitung von WordPress, wann und von welcher IP-Adresse aus etwas geschah und welche Aktionen ein Angreifer unternommen haben könnte.

Schadcode in der Datenbank findet keiner dieser Befehle, und die Prüfsummen-Befehle von WP-CLI sehen nur, wofür es bei WordPress.org ein Original gibt. Von außen prüfen kostenlose Malware-Scanner für Websites, was Ihre Website ausliefert. Und wenn ein Schritt anschlägt, beschreibt der Ratgeber Website gehackt: Malware erkennen und entfernen, wie es weitergeht.

Wann sollten Sie die Prüfung abgeben?

Selbst prüfen können Sie, wenn Sie Zugang zu WordPress und zum Server haben, die Spurenprüfung ohne Befund bleibt und die Website keine personenbezogenen Daten speichert. Abgeben sollten Sie die Prüfung, sobald Sie ein Konto oder eine Datei nicht zuordnen können, die Website ein Plugin ohne Update braucht oder Kundendaten betroffen sein können.

Wenn eine Bedingung aus der rechten Spalte zutrifft, übernehme ich die Prüfung und, falls nötig, die Bereinigung. Wie ich dabei vorgehe, beschreibe ich auf der Seite zur WordPress-Hack-Hilfe. Die Erstanalyse ist kostenlos, und für die Bereinigung nenne ich Ihnen einen Festpreis, bevor ich anfange.

Speichert die Website personenbezogene Daten und war jemand darauf, können Meldepflichten bestehen. Ob das für Sie gilt, ist eine rechtliche Frage für Ihren Datenschutzbeauftragten oder einen Fachanwalt; meinen technischen Bericht können Sie dafür verwenden. Für ein Gutachten in einem Verfahren oder eine Strafanzeige ist ein zertifizierter IT-Forensiker der richtige Ansprechpartner.

Wie erfahren Sie künftig rechtzeitig von Plugin-Lücken?

Von Sicherheitslücken in WordPress-Plugins erfahren Sie über das WordPress-Dashboard, das verfügbare Updates meldet, über den Changelog des Herstellers, über Schwachstellen-Datenbanken und über Warnungen des Bundesamts für Sicherheit in der Informationstechnik (BSI). Damit keine Meldung liegen bleibt, muss bei Ihnen jemand dafür zuständig sein.

Das Dashboard meldet, dass ein Update bereitsteht. Ob es eine Lücke schließt, steht im Changelog des Plugins, sofern der Hersteller es dort angibt. Bei Lücken im WordPress-Kern kann auch eine Warnung des BSI kommen: Im Juli 2026 warnte es etwa vor einer Lücke, für die Beispielcode für Angriffe ohne Anmeldung veröffentlicht war. Der Beitrag zur WordPress-Sicherheitslücke wp2shell zeigt, wie diese Meldung aussah.

Die allermeisten neuen Lücken betreffen allerdings Plugins: Patchstack zählte für 2025 im WordPress-Umfeld 11.334 neue Lücken, 91 % davon in Plugins (Stand Februar 2026). Aufräumen lohnt sich deshalb: Jedes Plugin, das Sie löschen, nimmt seine künftigen Meldungen mit. Der Ratgeber zur WordPress-Sicherheit beschreibt, welche Schutzmaßnahmen vor der nächsten Meldung zuerst kommen.

Auch wenn alle Plugins aktuell sind, kann jemand eine Lücke ausnutzen, die zum Zeitpunkt des Angriffs noch niemand kannte, eine sogenannte Zero-Day-Lücke. Kein Update schließt eine solche Lücke. Für diesen Fall brauchen Sie eine Sicherung, die sich zurückspielen lässt, und jemanden, der nach einer Meldung die Spuren prüft.

Wenn bei Ihnen niemand für Updates zuständig ist, übernehme ich sie in der WordPress-Wartung: Ich spiele Updates erst nach einem Backup ein, prüfe die Website danach und suche regelmäßig nach Schadcode. Entsteht ein Befall nach Beginn der Wartung, ist die Bereinigung enthalten; die Bedingungen stehen auf der Seite.