WordPress-Sicherheit: Warum Plugins das größte Risiko sind

Das größte Sicherheitsrisiko einer WordPress-Website sind ihre Plugins. Patchstack zählte 2025 insgesamt 11.334 neue Schwachstellen im WordPress-Ökosystem. 91 % davon lagen in Plugins, 9 % in Themes, im WordPress-Kern waren es sechs.

Der Kern selbst ist gut gepflegt. Das Risiko entsteht an den Rändern: bei Erweiterungen von Tausenden unterschiedlichen Entwicklern, von denen manche ihre Plugins jahrelang pflegen und andere sie nach einem Projekt vergessen.

Wie groß ist das Plugin-Risiko in Zahlen?

Patchstack veröffentlicht jährlich einen Bericht zur Sicherheitslage von WordPress. Die beiden letzten Ausgaben im Vergleich:

Zwei Zahlen sind für Betreiber besonders relevant. Erstens: 2025 war fast jede zweite Lücke noch offen, als sie öffentlich wurde. Ein Update, das Sie einspielen könnten, gab es zu diesem Zeitpunkt nicht. Zweitens: Laut Patchstack wird etwa die Hälfte der schwerwiegenden Lücken innerhalb von 24 Stunden ausgenutzt, bei stark angegriffenen Lücken liegt der gewichtete Median bei fünf Stunden bis zum ersten Angriff.

Warum ausgerechnet Plugins?

• Voller Zugriff. Ein Plugin ist PHP-Code, der mit denselben Rechten läuft wie WordPress selbst. Eine Lücke in einem Kontaktformular-Plugin reicht, um die ganze Website zu übernehmen.
• Sehr unterschiedliche Qualität. Hinter Plugins stehen große Firmen, Einzelentwickler und Hobbyprojekte. Code-Review und Sicherheitstests sind nicht einheitlich geregelt.
• Aufgegebene Plugins. 2024 wurden laut Patchstack 1.614 Plugins und Themes wegen nicht behobener Sicherheitsprobleme aus dem offiziellen Verzeichnis entfernt. Auf den Websites, die sie installiert haben, laufen sie weiter.
• Viele Plugins pro Website. Jede Erweiterung vergrößert die Angriffsfläche. Wer für jede Kleinigkeit ein Plugin installiert, verwaltet am Ende Code von Dutzenden Herstellern.

Was eine Plugin-Lücke im Ernstfall anrichtet

Typische Lückenarten sind Cross-Site-Scripting, fehlerhafte Zugriffskontrollen, SQL-Injection und ungeprüfte Datei-Uploads. Sie stehen alle in den OWASP Top 10. Die Folgen reichen von eingeschleustem Spam und Weiterleitungen auf Betrugsseiten über gestohlene Formulardaten bis zur kompletten Übernahme des Servers.

Für ein Unternehmen ist das mehr als ein technisches Problem. Gehen personenbezogene Daten aus Kontaktformularen oder einem Shop verloren, gilt die 72-Stunden-Meldefrist nach Art. 33 DSGVO. Und eine Website, die Google als gehackt markiert, verliert Besucher, bis sie bereinigt ist.

Checkliste: So senken Sie das Plugin-Risiko

• Inventar führen. Welche Plugins und Themes sind installiert, in welcher Version, wofür werden sie gebraucht?
• Unnötiges löschen. Deaktivierte Plugins liegen weiter auf dem Server. Was nicht gebraucht wird, wird gelöscht.
• Vor der Installation prüfen. Wann kam das letzte Update? Reagiert der Entwickler auf Meldungen? Gibt es bekannte Lücken in der Vergangenheit?
• Auto-Updates gezielt nutzen. Seit WordPress 5.5 lassen sich automatische Updates für jedes Plugin und Theme einzeln einschalten. Für einfache Plugins ist das sinnvoll, für geschäftskritische vorher auf einer Testumgebung prüfen.
• Schwachstellen überwachen. Datenbanken wie WPScan oder Patchstack melden, wenn ein installiertes Plugin betroffen ist.
• Admin-Zugänge absichern. Wenige Administratoren, eigene Konten statt geteilter Logins, Multi-Faktor-Authentifizierung für alle mit Schreibrechten.
• Backups extern und getestet. Tägliche Sicherung außerhalb des Webservers und regelmäßig ein Test-Restore. Ein Backup, das nie zurückgespielt wurde, ist eine Hoffnung.
• PHP aktuell halten. Eine PHP-Version ohne Sicherheitsupdates ist ein eigenes Risiko, unabhängig von WordPress.

Wenn es kein Update gibt

Bei 46 % der Lücken des Jahres 2025 existierte zum Zeitpunkt der Veröffentlichung kein Patch. Dann bleiben drei Wege: das Plugin deaktivieren und löschen, es durch eine gepflegte Alternative ersetzen oder die Lücke vorübergehend abschirmen, etwa mit einer Web Application Firewall mit WordPress-spezifischen Regeln.

Eine WAF ist dabei eine Ergänzung. Patchstack beschreibt für eine kritische Lücke im Bricks Builder Anfang 2024, dass verbreitete WAF-Lösungen von Hostern die Angriffe nicht verhinderten, weil ihnen die Regeln für genau diese Lücke fehlten. Das Grundproblem löst nur, wer den verwundbaren Code entfernt oder aktualisiert.

Die Website ist schon gehackt: was jetzt?

Wenn Besucher auf fremde Seiten umgeleitet werden, unbekannte Admin-Konten auftauchen oder Google vor Ihrer Website warnt, gehen Sie in dieser Reihenfolge vor:

1. 1

   Website vom Netz nehmen

   Wartungsseite schalten oder die Seite beim Hoster sperren lassen, damit keine Besucher infiziert und keine weiteren Daten abgegriffen werden.

2. 2

   Zugangsdaten ändern

   Alle WordPress-Admins, SFTP- und Hosting-Zugänge sowie das Datenbank-Passwort. Unbekannte Benutzerkonten löschen.

3. 3

   Eintrittsweg finden

   Welches Plugin oder Theme war verwundbar? Ohne diese Antwort wird eine bereinigte Website erneut übernommen.

4. 4

   Sauberen Stand wiederherstellen

   Backup von vor dem Angriff zurückspielen, danach sofort alle Plugins, Themes und den Kern aktualisieren und die verwundbare Erweiterung entfernen.

5. 5

   Meldepflichten und Google klären

   Bei betroffenen personenbezogenen Daten gilt die 72-Stunden-Frist nach Art. 33 DSGVO. In der Google Search Console können Sie nach der Bereinigung eine Überprüfung beantragen, damit die Warnung verschwindet.

Wann WordPress die richtige Wahl bleibt

Für einen Blog, eine Broschüren-Website oder eine Marketing-Seite mit wenigen, gut gepflegten Plugins ist WordPress eine vernünftige Wahl. Das Redaktions-Backend ist bekannt, Agenturen und Freelancer gibt es überall, die Einstiegskosten sind niedrig. Mit der Checkliste oben und jemandem, der sich regelmäßig darum kümmert, lässt sich das Risiko gut beherrschen.

Kritischer wird es, wenn eine Website zur Geschäftsanwendung wird: Kundenportal, Buchungssystem, Mitgliederbereich, Shop mit Schnittstellen zur Warenwirtschaft. Dann hängt ein Geschäftsprozess an einer Kette von Plugins verschiedener Hersteller. Wo die Grenze liegt, beschreibt unser Vergleich WordPress vs. Custom Code mit Laravel und Vue. Wer wechseln will, findet den Ablauf ohne Ranking-Verlust in der Anleitung WordPress-Exit in sechs Schritten.

Warum Visgenix kein WordPress baut

Visgenix hat sich gegen Baukastenlösungen entschieden: kein WordPress-Development, keine Plugin-Abhängigkeiten, keine Blackbox. WordPress-Websites hosten und richten wir auf Wunsch ein. Wir entwickeln Webanwendungen mit Laravel und Vue, deren Code mit Bezahlung dem Kunden gehört und die wir selbst betreiben und warten. Das ist bei einfachen Websites teurer als ein WordPress-Theme. Kleine Webanwendungen beginnen bei 10.000 €.

Der Vorteil liegt im Betrieb: Es gibt keine fremden Plugins, deren Lücken wir abwarten müssen. Die Abhängigkeiten sind wenige und bekannt, wir haben sie selbst im Blick, und die Anwendung läuft auf unserem Hosting in Frankfurt am Main mit CrowdSec als WAF und täglichen Malware-Scans. Ob sich das für Ihre Website lohnt, klären wir gern im Gespräch. Wenn WordPress für Ihren Fall reicht, sagen wir das.

• Ist WordPress unsicher?

  Der WordPress-Kern hatte 2025 laut Patchstack sechs gemeldete Schwachstellen und gilt als gut gepflegt. Das Risiko liegt in Plugins und Themes, auf die 2025 praktisch alle 11.334 gemeldeten Lücken entfielen. Eine WordPress-Website ist so sicher wie ihre am schlechtesten gepflegte Erweiterung.

• Reichen automatische Updates aus?

  Nein. Auto-Updates helfen, wenn ein Patch existiert. 2025 waren laut Patchstack 46 % der Lücken bei ihrer Veröffentlichung noch nicht behoben. Dazu kommen aufgegebene Plugins, die gar keine Updates mehr bekommen.

• Wie viele Plugins sind zu viele?

  Eine feste Grenze gibt es nicht. Entscheidend ist, dass jedes Plugin einen klaren Zweck hat, aktiv gepflegt wird und jemand seine Updates überwacht. Jedes zusätzliche Plugin ist Code eines weiteren Herstellers mit vollem Zugriff auf Ihre Website.

• Schützt eine Web Application Firewall vor Plugin-Lücken?

  Teilweise. Eine WAF mit WordPress-spezifischen Regeln kann bekannte Angriffsmuster abfangen und Zeit bis zum Patch verschaffen. Sie ersetzt nicht das Entfernen oder Aktualisieren des verwundbaren Plugins.