WordPress-Plugins — jedes ist Angriffsfläche

Würdigung — jedes Plugin ist eine Entscheidung#

WordPress ist nicht das Problem. Es ist ein ausgereiftes System, und für viele Websites die richtige Wahl. Das Risiko sitzt in der Erweiterbarkeit: Funktionen kommen über Plugins, und jedes Plugin ist Software von Dritten, die mit vollen Rechten im selben System läuft wie die Website. Ein Formular-Plugin, ein Cookie-Banner-Plugin, ein SEO-Plugin, ein Galerie-Plugin — jedes hat in der Regel Zugriff auf die Datenbank, in der auch die Kontakt-Anfragen der Mandanten liegen.

Das ist kein hypothetisches Risiko. Die meisten erfolgreichen Angriffe auf WordPress-Seiten laufen nicht über WordPress selbst, sondern über ein veraltetes oder schlecht gepflegtes Plugin. Und es trifft nicht „die anderen": Automatisierte Bots scannen das Netz rund um die Uhr nach bekannten Schwachstellen-Mustern — die Frage ist nicht, ob eine kleine Kanzlei-Seite gescannt wird, sondern nur, ob der Scanner eine offene Tür findet.

Für eine Kanzlei kommt die Berufsdimension dazu: Hinter dem Kontaktformular liegen Mandanten-Daten, die § 203 StGB schützt. Eine kompromittierte Plugin-Lücke ist damit nicht nur ein IT-Problem, sondern berührt die Verschwiegenheits-Verantwortung.

Plugins als Angriffsfläche — CVEs und der Update-Zwang#

Eine CVE (Common Vulnerabilities and Exposures) ist ein öffentlich katalogisierter Sicherheits-Fehler mit einer eindeutigen Nummer. Wird in einem populären Plugin eine CVE bekannt, passiert zweierlei gleichzeitig: Der Autor veröffentlicht ein Update — und Angreifer wissen jetzt genau, wonach sie suchen müssen. Jede Seite, die das Update nicht zeitnah einspielt, steht offen.

Das ist der Update-Zwang in seiner ganzen Härte. Sicherheit bei WordPress ist keine einmalige Einrichtung, sondern eine Daueraufgabe: WordPress-Kern, jedes Plugin und das Theme müssen laufend aktuell gehalten werden. In einer Kanzlei, in der niemand für die Website zuständig ist, bleibt genau das liegen — und ein Plugin, das seit Monaten nicht aktualisiert wurde, ist die wahrscheinlichste Einfallstür. Im Quelltext ist die veraltete Version oft offen sichtbar, und Bots lesen sie automatisiert aus.

Supply-Chain — das fremde Plugin, dem Sie vertrauen müssen#

Mit jedem Plugin übernimmt eine Kanzlei ein Supply-Chain-Risiko: Sie vertraut nicht nur dem Plugin in seiner heutigen Form, sondern jedem zukünftigen Update des Autors. Plugins wechseln den Eigentümer, Autoren stellen die Pflege ein, und in seltenen, aber dokumentierten Fällen wird über ein gekapertes Plugin-Update bösartiger Code an Tausende Seiten ausgeliefert — ohne dass die Betreiber etwas tun mussten als „Update installieren".

Je mehr Plugins, desto größer diese Vertrauens-Fläche. Ein Dutzend Plugins heißt ein Dutzend Autoren, ein Dutzend Update-Ströme, ein Dutzend potenzielle Schwachstellen-Quellen. Das ist die unsichtbare Last hinter der bequemen Ein-Klick-Installation.

Das Abmahn-Risiko — wenn ein Plugin Daten abfließen lässt#

Neben der Sicherheit gibt es eine zweite, oft übersehene Flanke: das Abmahn-Risiko. Viele Plugins laden im Hintergrund Ressourcen von Dritt-Servern oder binden Tracking ein — ohne dass die Kanzlei es bewusst entschieden hat. Das klassische Beispiel ist ein Theme oder Plugin, das Schriftarten direkt von Googles Servern nachlädt. Das LG München I hat dazu am 20.01.2022 entschieden, dass die Einbindung von Google Fonts über den Google-Server ohne Einwilligung gegen Datenschutzrecht verstößt — Schadenersatz inklusive. Dieselbe Mechanik gilt für eingebettete Karten, Analyse-Skripte oder Cookie-Banner-Plugins, die selbst Tracking-Cookies setzen.

Das Tückische: Die Kanzlei hat diese Datenabflüsse nie aktiv gewollt — sie kamen als Default eines Plugins mit. Die Verantwortung trägt trotzdem die Betreiberin. Wie sich diese Falle strukturell vermeiden lässt, steht im Artikel zur cookielosen Kanzlei-Website.

Die Alternative — statisch bauen, ohne Plugin-Park#

Der grundlegende Ausweg ist architektonisch: eine Website, die gar nicht erst auf einen Plugin-Park angewiesen ist. Eine statisch gebaute Seite ohne Datenbank und ohne serverseitige Plugin-Logik hat schlicht keine Plugin-Angriffsfläche — es gibt keinen Plugin-Code, der kompromittiert werden könnte, und keine Datenbank, die ausgelesen werden könnte. So bauen wir bei FA²: Funktionen wie Formulare, Spam-Abwehr oder Analytics sind direkt und kontrolliert eingebaut, nicht als fremde Plugins zugekauft. Eine vorgelagerte Cloudflare-Schicht und ein sauberer Schutz-Header-Satz härten den Rest.

Das heißt nicht, dass jede Kanzlei sofort weg von WordPress muss. Es heißt: Wer bei WordPress bleibt, sollte die Plugin-Liste bewusst kurz halten, jedes Plugin auf seinen Pflege-Stand prüfen und Updates als feste Routine einplanen — nicht als „machen wir, wenn Zeit ist". Dieselbe Routine-Disziplin gilt für Inhalte (Saison-Banner, Schließungs-Hinweise), die sonst Jahre im Quelltext liegen bleiben.

Für eine vollständige Bestandsaufnahme — CMS-Stack, Plugin-Risiken, Datenabflüsse, Header — empfehlen wir den Hebel-Audit (890 €, bei Mandanten-Boost-Beauftragung innerhalb von 60 Tagen voll anrechenbar).

Zusammenfassung#

Jedes WordPress-Plugin ist fremder Code mit Datenbank-Zugriff im eigenen System — und damit Angriffsfläche, Update-Verpflichtung und Supply-Chain-Risiko in einem. Bekannt gewordene CVEs werden von Bots automatisiert gesucht; ein nicht eingespieltes Update ist die wahrscheinlichste Einfallstür. Dazu kommt das oft übersehene Abmahn-Risiko, wenn ein Plugin ungefragt Daten an Dritte abfließen lässt — der Google-Fonts-Fall ist nur das bekannteste Beispiel. Wer bei WordPress bleibt, hält die Plugin-Liste kurz und Updates aktuell. Wer die Angriffsfläche grundsätzlich loswerden will, baut statisch — ohne Datenbank, ohne Plugin-Park. Der erste Schritt ist in jedem Fall, die eigene Plugin-Lage überhaupt zu kennen.

Quellen#

• OWASP Top 10 — A06:2021 Vulnerable and Outdated Components — abgerufen 2026-05-29
• NVD — National Vulnerability Database (CVE-Katalog) — abgerufen 2026-05-29
• LG München I, Urteil vom 20.01.2022 – 3 O 17493/20 (Google Fonts) — abgerufen 2026-05-29
• TDDDG § 25 — Schutz der Privatsphäre bei Endeinrichtungen — abgerufen 2026-05-29

Disclaimer: Allgemeine fachliche Information zum Zeitpunkt der Veröffentlichung — keine Rechtsberatung im Einzelfall. Konkrete Sicherheits- und Abmahn-Fragen einer bestehenden Seite gehören in die fachliche bzw. anwaltliche Einzelprüfung.