Sicherheitslücken in WordPress-Plugins erkennen: Schwachstellen-Datenbanken und geschlossene Plugins prüfen

Die Statistik der WPScan-Datenbank wies am 30.09.2026 knapp 40.000 Einträge zu Plugin-Schwachstellen aus. Für viele dieser Lücken existiert längst ein Update. Das Problem ist selten die fehlende Korrektur, sondern dass niemand bemerkt, dass sie nötig ist. Diese Anleitung zeigt, wie Sie Ihren Plugin-Bestand systematisch gegen öffentliche Schwachstellen-Datenbanken prüfen, geschlossene Plugins im Verzeichnis von wordpress.org erkennen und Warnungen richtig einordnen. Die Prüfbefehle haben wir in einer Testinstanz mit WordPress 7.1.2 ausgeführt, die Angaben zu den Diensten stammen von deren Plugin-Seiten auf wordpress.org.

Voraussetzungen

• WordPress in einer aktuellen Version (getestet mit 7.1.2) mit PHP in einer unterstützten Version (Test: PHP 8.4)
• Benutzerkonto mit der Rolle Administrator
• Für die Befehle: SSH-Zugang mit WP-CLI (getestet mit 2.12.0) und curl; ohne SSH lesen Sie Versionen unter Plugins > Installierte Plugins ab
• Für automatische Prüfungen: ein Konto bei dem jeweiligen Dienst, je nach Plugin ein kostenloser API-Schlüssel oder eine Verbindung zu dessen Servern
• Ein aktuelles Backup, bevor Sie auf einen Befund hin Plugins aktualisieren, deaktivieren oder löschen
• Englischkenntnisse zum Lesen der Datenbankeinträge, die fast immer auf Englisch sind

Schritt 1: Bestand erfassen

Eine Schwachstellenprüfung ist nur so gut wie die Liste, gegen die Sie prüfen. Erfassen Sie alle Plugins, auch deaktivierte. Deaktivierte Plugins sind nicht harmlos: Ihre Dateien liegen auf dem Server und können bei manchen Lücken direkt aufgerufen werden.

wp plugin list --fields=name,status,version,update_version,update
wp theme list --fields=name,status,version,update_version,update

In der Testinstanz hatten wir absichtlich eine ältere Version von Contact Form 7 installiert. Die Ausgabe zeigte die Zeile contact-form-7 5.3.1 6.1.7 available, also installierte Version, verfügbare Version und den Hinweis auf das Update. Im Backend finden Sie dieselbe Information unter Plugins > Installierte Plugins mit dem Hinweis „Aktualisierung verfügbar“.

Der Name in der ersten Spalte ist der Slug, also die Kennung des Plugins. Unter diesem Slug suchen Sie in den Datenbanken. Premium-Plugins und selbst entwickelte Erweiterungen, die nicht aus dem Verzeichnis von wordpress.org stammen, haben oft einen eigenen Slug. Notieren Sie bei ihnen Hersteller und Produktname, damit Sie sie in den Datenbanken finden.

Verifizieren: Sie haben eine Liste aller Plugins und Themes mit Slug, Status, Version und verfügbarer Version, idealerweise im Wartungsprotokoll abgelegt.

Schritt 2: Plugins gegen Schwachstellen-Datenbanken prüfen

Drei öffentlich durchsuchbare Datenbanken haben sich auf WordPress spezialisiert. Sie werden von Sicherheitsfirmen gepflegt, die Lücken sammeln, prüfen und mit CVE-Nummern verknüpfen:

Für eine einmalige Prüfung suchen Sie jedes Plugin auf der Webseite einer der Datenbanken. Die Einträge nennen die betroffenen Versionen und die Version, die das Problem behebt, in der Regel als „Fixed in“. Liegt Ihre installierte Version unter der Korrekturversion, sind Sie betroffen.

Die APIs lassen sich nicht ohne Zugangsdaten nutzen. Im Test antwortete die WPScan-API ohne Token mit Status 403 und {"status":"forbidden"}, die Wordfence-API mit 401 und der Meldung API key must be supplied using a Bearer token. Wenn Sie viele Websites betreuen, lohnt sich ein Schlüssel. Für eine einzelne Unternehmenswebsite ist ein Plugin einfacher, das die Abfrage täglich erledigt (Schritt 4).

Prüfen Sie Themes genauso. Auch ein inaktives Theme mit bekannter Lücke gehört gelöscht oder aktualisiert.

Verifizieren: Für jedes Plugin und Theme aus Schritt 1 ist vermerkt, ob die installierte Version eine bekannte, noch offene Lücke hat.

Schritt 3: Geschlossene Plugins erkennen

Eine besondere Gefahr sind Plugins, die im Verzeichnis von wordpress.org geschlossen wurden. Laut Plugin-Entwickler-FAQ geschieht das bei Verstößen gegen die Richtlinien, bei Sicherheitsproblemen oder auf Wunsch des Autors. Ein geschlossenes Plugin ist nicht mehr herunterladbar und erhält keine Updates, auch keine Sicherheitskorrekturen. Ohne gezielte Prüfung fällt das leicht nicht auf, weil einfach keine Update-Hinweise mehr erscheinen.

Die Plugin-API von wordpress.org liefert diese Information ohne Anmeldung. Das folgende Skript prüft alle installierten Plugins; führen Sie es im WordPress-Verzeichnis aus:

wp plugin list --field=name | while read -r slug; do
  r=$(curl -s "https://api.wordpress.org/plugins/info/1.2/?action=plugin_information&slug=${slug}" < /dev/null)
  case "$r" in
    *'"error":"closed"'*) echo "$slug: GESCHLOSSEN" ;;
    *'"error"'*) echo "$slug: nicht auf wordpress.org" ;;
    *) echo "$slug: zuletzt aktualisiert $(printf '%s' "$r" | grep -o '"last_updated":"[^"]*"' | cut -d'"' -f4)" ;;
  esac
done

Im Test lieferte das Skript unter anderem:

akismet: zuletzt aktualisiert 2026-08-18 11:42pm GMT
contact-form-7: zuletzt aktualisiert 2026-08-17 4:10am GMT
display-widgets: GESCHLOSSEN
hello: nicht auf wordpress.org

Das Plugin „Display Widgets“ ist ein reales Beispiel: Die API meldet "closed_date":"2021-01-30" und als Grund "reason_text":"Security Issue", mit dem Zusatz, die Schließung sei dauerhaft. Wer ein solches Plugin noch einsetzt, sollte es sofort ersetzen.

Die Zeile für hello zeigt eine Grenze des Verfahrens: Das mitgelieferte Plugin Hello Dolly liegt lokal im Ordner hello, im Verzeichnis aber unter dem Slug hello-dolly. Ein „nicht auf wordpress.org“ bedeutet also nicht zwingend Gefahr; es kann ein abweichender Slug, ein Premium-Plugin oder eine Eigenentwicklung sein. Prüfen Sie diese Fälle von Hand. Das Datum der letzten Aktualisierung hilft zusätzlich: Ein Plugin, das seit Jahren keine neue Version erhalten hat, ist ein Kandidat für Ersatz.

Verifizieren: Das Skript läuft ohne Fehler durch, kein Plugin ist als GESCHLOSSEN markiert, und jede Zeile „nicht auf wordpress.org“ ist von Hand geklärt.

Schritt 4: Laufende Überwachung einrichten

Eine einmalige Prüfung veraltet mit der nächsten veröffentlichten Lücke. Für die laufende Überwachung gibt es Plugins, die Ihren Bestand regelmäßig mit einer Datenbank abgleichen. Die folgenden Angaben stammen von den jeweiligen Plugin-Seiten auf wordpress.org, Stand 30.09.2026; wir haben diese Plugins nicht im Labor getestet, weil sie eine Verbindung zu externen Diensten voraussetzen.

• Jetpack Protect (Version 6.1.0) wirbt mit kostenlosen täglichen Schwachstellen-Scans auf Basis der WPScan-Datenbank. Malware-Scan und Firewall gibt es erst in der kostenpflichtigen Stufe.
• Wordfence Security (Version 9.0.2) prüft laut Beschreibung auf bekannte Schwachstellen und warnt auch, wenn ein Plugin geschlossen oder aufgegeben wurde. In der kostenlosen Version kommen Firewall-Regeln und Malware-Signaturen mit 30 Tagen Verzögerung.
• WPScan (Version 1.17) wird laut eigener Plugin-Seite für Nicht-Enterprise-Kunden nicht mehr aktiv unterstützt; der Hersteller empfiehlt stattdessen Jetpack Protect. Setzen Sie es für neue Einrichtungen deshalb nicht mehr ein.

Entscheiden Sie sich für ein Werkzeug, nicht für mehrere gleichzeitig. Mehrere Sicherheits-Plugins mit Firewall-Funktionen stören sich gegenseitig und verlangsamen die Website. Achten Sie außerdem auf den Datenschutz: Diese Plugins übermitteln Informationen über Ihre Installation an den Betreiber. Prüfen Sie Datenschutzhinweise und gegebenenfalls einen Vertrag zur Auftragsverarbeitung. Wichtig ist in jedem Fall, dass die Warnungen bei jemandem ankommen, der sie liest. Prüfen Sie die E-Mail-Adresse im Plugin und unter Einstellungen > Allgemein.

Hier wird deutlich, dass Schwachstellenmanagement eine dauerhafte Aufgabe ist: Warnungen lesen, bewerten, Updates einspielen, Ersatz suchen. Wer das nicht selbst im Kalender halten möchte, kann es abgeben: Die WordPress-Wartung von wordpressupdate.de übernimmt Updates von WordPress, Plugins und Themes innerhalb von 48 Stunden mit Kompatibilitätsprüfung, wöchentliche Backups auf externen Speicher und die Einrichtung und Wartung der Firewall.

Verifizieren: Das gewählte Werkzeug zeigt einen abgeschlossenen Scan mit Datum, und eine Test- oder Scan-Benachrichtigung ist im richtigen Postfach angekommen.

Schritt 5: Befund bewerten und handeln

Nicht jede Warnung bedeutet akute Gefahr. Lesen Sie den Datenbankeintrag und beantworten Sie vier Fragen. Welche Versionen sind betroffen, und liegt Ihre darunter? Gibt es eine Korrekturversion? Welche Voraussetzung braucht der Angreifer: Genügt ein anonymer Besucher, oder braucht er ein Konto mit bestimmten Rechten? Und welche Art von Lücke ist es? Eine Lücke, die ohne Anmeldung das Hochladen von Dateien oder das Ausführen von Code erlaubt, ist akut. Eine Lücke, für die ein Administratorkonto nötig ist, ist auf einer Website mit nur einem vertrauenswürdigen Administrator weniger dringlich, aber nicht egal.

Daraus folgt die Handlung:

Das Update per WP-CLI lautet wp plugin update contact-form-7; Details zum sicheren Ablauf beschreibt die Anleitung WordPress-Updates per WP-CLI. Wurde eine Lücke vermutlich schon ausgenutzt, bevor Sie sie geschlossen haben, reicht das Update nicht: Prüfen Sie Dateien per Prüfsumme, Administratorkonten und Logs, wie im Wartungsplan für WordPress beschrieben.

Verifizieren: wp plugin list --fields=name,version,update zeigt für das betroffene Plugin eine Version ab der Korrekturversion und none in der Spalte update, oder das Plugin ist entfernt.

Typische Fehler

„nicht auf wordpress.org“ bei einem bekannten Plugin: Der lokale Ordnername weicht vom Slug im Verzeichnis ab, wie im Test bei hello und hello-dolly. Suchen Sie das Plugin auf wordpress.org und vergleichen Sie den Slug in der Adresse.

API antwortet mit 403 oder 401: WPScan und Wordfence verlangen für ihre APIs einen Token bzw. Schlüssel. Nutzen Sie die Webseite der Datenbank oder ein Plugin.

Warnung zu einem deaktivierten Plugin ignoriert: Deaktivieren genügt nicht, wenn die Lücke in direkt aufrufbaren Dateien steckt. Löschen Sie Plugins, die Sie nicht brauchen.

Keine Warnungen, weil E-Mails nicht ankommen: Viele Server versenden E-Mails unzuverlässig. Richten Sie einen Versand über SMTP ein und testen Sie ihn.

Häufige Fragen

Reichen automatische Plugin-Updates nicht aus?

Sie schließen Lücken, für die es eine Korrektur gibt, oft schnell. Sie helfen nicht bei geschlossenen Plugins, bei Premium-Plugins ohne gültige Lizenz und bei Lücken ohne Korrektur. Dafür brauchen Sie die Prüfung aus diesem Artikel.

Wie oft sollte ich prüfen?

Automatisch täglich über ein Plugin, dazu einmal im Monat die Prüfung auf geschlossene Plugins. Bei großen, öffentlich bekannt gewordenen Lücken in verbreiteten Plugins prüfen Sie sofort.

Was mache ich mit Premium-Plugins?

Suchen Sie sie in den Datenbanken nach Hersteller und Namen und abonnieren Sie den Sicherheits-Newsletter oder Blog des Herstellers. Halten Sie die Lizenz gültig, sonst erhalten Sie keine Updates.

Testumfang

Wir haben das Prüfskript am 30.09.2026 in einer isolierten Testinstanz mit WordPress 7.1.2 ausprobiert, samt einer absichtlich veralteten Plugin-Version in der Bestandsliste. Dabei haben wir auch geschlossene und abweichende Slugs gegen die Plugin-API von wordpress.org geprüft. Die Plugins Jetpack Protect, Wordfence und WPScan selbst haben wir nicht getestet, die Angaben dazu stammen von ihren Plugin-Seiten. Probieren Sie diese daher zuerst auf einer Kopie Ihrer Website aus.

Fazit

Sicherheitslücken in Plugins erkennen Sie mit drei Bausteinen: einer vollständigen Bestandsliste, dem Abgleich mit einer Schwachstellen-Datenbank und der Prüfung auf geschlossene Plugins über die API von wordpress.org. Ein Überwachungs-Plugin übernimmt den täglichen Abgleich, bewerten und handeln müssen Sie selbst. Wenn Sie Updates und Firewall in fremde Hände geben möchten, übernimmt die WordPress-Wartung von Marcel Schönfelder diesen Teil.

Weiterführende Anleitungen und Quellen

• WordPress-Updates per WP-CLI
• Wartungsplan für WordPress
• Automatische Updates in WordPress steuern
• WPScan: WordPress Plugin Vulnerabilities
• Wordfence Intelligence: Vulnerability Database
• Patchstack Database
• Plugin Developer FAQ: geschlossene Plugins
• Jetpack Protect auf wordpress.org
• Wordfence Security auf wordpress.org