Plugins als Sicherheitsrisiko

Bei einer Blog-Übernahme zählen wir als Erstes die installierten Plugins. 30 sind keine Seltenheit. 40 haben wir auch schon gesehen. Jedes einzelne davon ist ein Stück Code, das Schwachstellen enthalten kann, und bei dem du darauf vertraust, dass der Entwickler regelmäßig Updates liefert.

Das Problem ist nicht, dass Plugins grundsätzlich schlecht sind. Das Problem ist die Menge und die fehlende Prüfung.

2026: Plugin-Diät ist keine Schönheitsmaßnahme mehr

Die Plugin-Landschaft 2026 steckt in einer schlechten Phase. Plugins, die jahrelang zuverlässig gepflegt waren, geben gerade reihenweise den Geist auf. Entwickler kommen mit den WordPress-Release-Zyklen und PHP-Upgrades nicht mehr nach. Übernahmen ans nächste Team scheitern oder ziehen sich, weil die Wirtschaftlichkeit fehlt, kostenlose Plugins finanzieren keine drei Tage Code-Audit pro Quartal.

Das Ergebnis siehst du, wenn du in dein Plugin-Verzeichnis schaust: Versionen, deren letztes Update aus 2023 stammt. Plugins, deren WordPress.org-Seite einen rot eingefärbten Hinweis trägt, dass das Plugin seit über einem Jahr keine Aktualisierung mehr erhalten hat. Eigentlich solide Werkzeuge, die plötzlich Karteileichen sind.

Heißt für dich: Plugin-Diät ist 2026 keine Schönheitsmaßnahme, sondern Pflicht. Was vor zwei Jahren noch entspannt mitgelaufen ist, kann heute eine offene Tür sein. Der Maßstab hat sich verschoben, nicht weil die Plugins schlechter geworden sind, sondern weil die Pflege im breiten Mittelfeld zurückgegangen ist.

Drei Fragen vor jeder Plugin-Installation

Wenn du ein Plugin installierst, schau dir drei Dinge an: Wann war das letzte Update? Wie viele aktive Installationen hat es? Und gibt es bekannte Sicherheitsprobleme? Ein Plugin, das seit zwei Jahren kein Update mehr bekommen hat, ist ein Risiko, egal wie gut die Bewertungen sind.

Die Zahl der aktiven Installationen allein sagt wenig aus. Auch populäre Plugins hatten schon schwere Sicherheitslücken. Aber ein Plugin mit 500.000 Installationen wird schneller gepatcht als eines mit 2.000, weil mehr Augen drauf schauen und der Druck auf den Entwickler höher ist.

Weniger Plugins bedeuten weniger Angriffsfläche. Punkt.

"Installiert und läuft" ist kein Sicherheitsbeweis, Beispiel VG-WORT-METIS

Ein gutes Beispiel, warum auch offiziell aussehende Plugins genau geprüft werden müssen, ist VG-WORT-METIS. Das ist das offizielle Plugin der VG Wort, weit verbreitet bei deutschen Foodbloggern, weil es die Zählpixel für die Texterfassung sauber in WordPress integriert. Wer ernsthaft Beiträge zur Verwertungsgesellschaft meldet, hat es fast immer installiert.

Wordfence führt für VG-WORT-METIS in den Versionen <= 2.0.1 eine Missing-Authorization-Schwachstelle. Ungepatcht, Stand Mai 2026. Gleichzeitig listet WordPress.org weiterhin 2.0.1 als aktuelle Plugin-Version. Du installierst also genau die Version, die im Verzeichnis steht, hältst alles aktuell, und hast trotzdem eine bekannte, dokumentierte Lücke im System.

Lehre daraus: "Installiert und läuft" ist nicht dasselbe wie "sicher". Auch ein Plugin von einer großen deutschen Verwertungsgesellschaft kann ungepatchte Schwachstellen mit sich rumschleppen, ohne dass die Plugin-Verwaltung in deinem Backend dich darauf hinweist. Es gibt drei Wege damit umzugehen: Du ersetzt das Plugin durch eine Alternative für die Zählpixel-Einbindung, du sicherst den verwundbaren Endpoint per Webserver-Regel ab, oder du betreibst es bewusst weiter, dann aber mit der Information im Hinterkopf, dass die Lücke da ist, und mit der Bereitschaft, schnell zu reagieren, wenn jemand sie aktiv ausnutzt. Den ausführlichen Quellen-Verweis dazu findest du in unserem 12-Punkte-Sicherheits-Post.

Was du nicht tun solltest: das Plugin als "naja, ist halt von der VG Wort" abhaken und weiterlaufen lassen, ohne überhaupt zu wissen, dass es eine offene Lücke gibt.

Theme-Features statt Plugin-Sammlung

Wir sehen oft Blogs, die fünf verschiedene Plugins für Dinge installiert haben, die ein gutes Theme von Haus aus kann: Social-Media-Buttons, Inhaltsverzeichnisse, verwandte Beiträge, Lazy Loading. Jedes dieser Plugins lädt eigene Skripte, eigene Stylesheets und eigenen PHP-Code. Das ist nicht nur langsam, sondern auch ein Sicherheitsrisiko.

Features aus einem zusammengehörigen Bundle haben einen klaren Vorteil, und das ist unabhängig davon, welches Theme oder welcher Anbieter das ist: Sie kommen aus einer Hand, werden zusammen getestet und zusammen aktualisiert. Egal ob das ein Theme-Feature, ein vom selben Anbieter gewartetes Sicherheitspaket oder ein zugehöriges Komponenten-Plugin ist, solange Theme und Plugin zusammen entwickelt werden, sind sie aufeinander abgestimmt. Ein wahllos aus dem Verzeichnis gezogenes Drittanbieter-Plugin wird dagegen unabhängig gepflegt und kann bei einem WordPress- oder Theme-Update plötzlich inkompatibel werden.

Die Frage ist nicht "Theme-Feature oder Plugin?", die Frage ist "aus einer Hand oder zusammengewürfelt?". Drei Plugins desselben Anbieters, die für dasselbe Theme gebaut wurden, sind auch ein Bundle. Vier Plugins von vier verschiedenen Entwicklern, die zufällig ähnliche Aufgaben erfüllen, sind keines.

Deaktiviert ist nicht weg

Noch ein Punkt, der oft vergessen wird: Deaktivierte Plugins sind nicht sicher. Ein Plugin, das du deaktivierst, liegt weiterhin physisch in /wp-content/plugins/<plugin-name>/ auf dem Server. Die Dateien sind da. Erreichbar. Ausführbar.

Das ist deshalb relevant, weil automatisierte Scanner gar nicht über das WordPress-Backend gehen. Sie probieren Plugin-Dateien direkt aus, indem sie URLs der Form /wp-content/plugins/<name>/<datei>.php aufrufen. WordPress prüft an dieser Stelle nicht, ob das Plugin in der Plugin-Liste auf "aktiv" oder "inaktiv" steht, die PHP-Datei wird ausgeführt, weil der Webserver sie liefert. Wenn die Datei eine bekannte Schwachstelle hat, kann der Angriff durchgehen, auch wenn das Plugin in deinem Backend grau hinterlegt ist.

Die Konsequenz ist einfach: Was du nicht brauchst, löschst du komplett. Nicht deaktivieren, entfernen. Deaktivieren ist eine WordPress-Information, kein Sicherheitsmechanismus.

Was wir bei Übernahmen sehen

Letztes Beispiel, fast schon Standardfall: Blog-Übernahme, 36 Plugins. Davon 9 deaktiviert. Bei sieben dieser deaktivierten lag die letzte Aktivierung mehr als zwei Jahre zurück, der Vorbesitzer hat irgendwann mal was ausprobiert und nie aufgeräumt. Drei der aktiven Plugins hatten seit 2023 kein Update mehr, eines davon mit einer dokumentierten Lücke aus 2024.

Was wir damit machen: Erst die deaktivierten löschen, kompromisslos. Dann die aktiven durchgehen und in drei Stapel sortieren, gepflegt und gebraucht (bleibt), gepflegt aber überflüssig (raus), schlecht gepflegt egal ob gebraucht oder nicht (Ersatz suchen). Aus 36 werden so meistens 12 bis 15. Der Blog läuft danach schneller, ist sicherer, und die monatliche Update-Routine dauert nicht mehr eine Stunde, sondern fünfzehn Minuten.

Unser Tipp: Geh heute durch deine Plugin-Liste und frag dich bei jedem einzelnen: Brauche ich das wirklich? Wenn die Antwort "vielleicht" ist, deaktiviere es für eine Woche und schreibe dir auf, was du verändert hast. Wenn nichts fehlt, lösch es, nicht nur deaktiviert lassen. Bei den Plugins, die bleiben, prüfst du das Datum der letzten Aktualisierung und ob auf der WordPress.org-Seite Sicherheitshinweise stehen. Das dauert pro Plugin keine zwei Minuten und ist die ehrlichste Bestandsaufnahme, die du deinem Blog 2026 schenken kannst.

Wenn du dabei feststellst, dass du gleich mehrere Plugins löschen oder ersetzen willst, kommt jetzt die nächste Frage: Was passiert, wenn beim Aufräumen etwas schiefgeht? Genau darum geht es in der nächsten Lektion, Backups als Sicherheitsnetz, das jede Plugin-Aufräumaktion erst ungefährlich macht.