WordPress Security: Was Ihre Website wirklich schützt – und was nicht mehr reicht

Die meisten Unternehmen behandeln die Sicherheit ihrer Website wie eine Versicherung: einmal abgeschlossen, dann nicht mehr angefasst. Ein Security-Plugin ist installiert, Updates laufen automatisch, ein Backup liegt irgendwo. Damit fühlt sich das Thema erledigt an.

Diese Rechnung ging lange auf. 2026 geht sie nicht mehr auf – und zwar aus einem Grund, der wenig mit Technik und viel mit Zeit zu tun hat. Zwischen der Veröffentlichung einer Sicherheitslücke und ihrer massenhaften Ausnutzung liegen im Mittel fünf Stunden. Kein Wartungsvertrag der Welt ist so schnell.

Geschrieben von Sergei Fink · Zuletzt aktualisiert am [Datum]

Wie ernst ist die Lage 2026 wirklich?

Sicherheitsthemen werden gerne dramatisiert. Deshalb hier zuerst die Zahlen – und danach ein Hinweis darauf, wie belastbar sie eigentlich sind.

Der Blick auf Deutschland

Das Bundesamt für Sicherheit in der Informationstechnik zählte in seinem letzten Lagebericht durchschnittlich 119 neue Sicherheitslücken pro Tag, rund ein Viertel mehr als im Jahr zuvor. Die Reihe der Vorjahre zeigt, wohin das läuft: von 68 über 78 auf 96 und jetzt 119.

Zwei Beobachtungen des BSI sind für Website-Betreiber besonders relevant. Erstens: Web-Angriffsflächen gewinnen an Bedeutung, während E-Mail-basierte Angriffe zurückgehen. Zweitens: Rund 80 Prozent der angezeigten Ransomware-Fälle trafen kleine und mittlere Unternehmen. Nicht Konzerne. Nicht Betreiber kritischer Infrastruktur. Den Mittelstand.

Das Bild im WordPress-Ökosystem

Besonders bemerkenswert sind zwei Werte. Erstens die 46 Prozent ohne Patch: Selbst wer diszipliniert aktualisiert, ist in fast der Hälfte der Fälle zunächst schutzlos. Zweitens die Zahlen zu kommerziellen Erweiterungen – die verbreitete Annahme, gekaufte Plugins seien sicherer als kostenlose, hält der Prüfung nicht stand.

Ein Hinweis zu diesen Zahlen

Alle genannten Werte stammen aus der Auswertung von Anbietern, die selbst Sicherheitsprodukte verkaufen. Dass Wordfence für ein einziges Quartal rund 2.200 Schwachstellen meldet und Patchstack für das Gesamtjahr 11.334, ist kein Widerspruch, sondern schlicht ein anderer Erfassungsrahmen.

Wir halten es für ehrlicher, das offen zu sagen, als mit scheinbar präzisen Zahlen zu argumentieren: Belastbar ist die Richtung, nicht die zweite Nachkommastelle. Und die Richtung ist in allen Quellen dieselbe.

Was nach einem erfolgreichen Angriff passiert

Der Hoster GoDaddy analysierte im vergangenen Jahr über 830.000 infizierte Websites. Der größte Teil der Funde entfiel auf Schadsoftware und SEO-Spam – also auf Angriffe, die eine Website nicht lahmlegen, sondern sie unbemerkt für fremde Zwecke benutzen.

Besonders aufschlussreich ist eine dort dokumentierte Angriffskette: Anmeldung mit gestohlenen Zugangsdaten, Upload eines präparierten Plugins, Aktivierung – alles in 30 Sekunden. Keine Sicherheitslücke beteiligt. Nur ein Passwort.

Die Konsequenz aus allen drei Quellen ist dieselbe: Updates sind die zweite Verteidigungslinie, nicht die erste.

Was verändert KI an der Sicherheit von WordPress?

Die kurze Antwort: nicht die Angriffsarten, sondern deren Kosten und Tempo. Drei Verschiebungen sind relevant.

Schwachstellen zu finden kostet fast nichts mehr

Ein Forschungsteam kombinierte KI-gestützte Code-Analyse mit automatisierter Überprüfung und fand damit in rund 72 Stunden über 300 kritische, bis dahin unbekannte Schwachstellen im WordPress-Plugin-Ökosystem. Jeder Fund wurde vor der Veröffentlichung manuell verifiziert.

Was sich hier ändert, ist keine neue Angriffsart. Es ist der Preis pro gefundener Lücke. Was früher Wochen an Spezialistenarbeit kostete, läuft heute als automatisierter Durchlauf. Der Nachschub an Schwachstellen wird dadurch nicht gefährlicher, aber deutlich größer.

Code entsteht schneller, als er geprüft wird

Die zweite Verschiebung betrifft die Seite, über die kaum jemand spricht: Wer schreibt eigentlich die Plugins?

Der Sicherheitsanbieter Veracode testete über 100 Sprachmodelle mit sicherheitsrelevanten Programmieraufgaben. In 45 Prozent der erzeugten Code-Beispiele fanden sich Schwachstellen aus den OWASP Top 10 – der Standardliste der häufigsten Sicherheitsfehler in Webanwendungen. Die Quote hat sich über mehrere Testzyklen nicht verbessert, und größere Modelle schnitten nicht besser ab als kleinere. Eine unabhängige Zählung an der Georgia Tech verzeichnete zuletzt einen deutlichen Anstieg von Sicherheitsmeldungen, die sich auf KI-generierten Code zurückführen lassen.

Wir sagen das ausdrücklich nicht als Kritik am Werkzeug. Wir arbeiten selbst täglich mit KI-Unterstützung in der Entwicklung. Das Problem ist nicht die Erzeugung von Code, sondern die fehlende Prüfung davor – Code wird heute schneller veröffentlicht, als jemand ihn lesen kann. Für Sie als Website-Betreiber heißt das: Die Erweiterung, die Sie nächstes Jahr installieren, ist mit höherer Wahrscheinlichkeit von einem Modell geschrieben und von niemandem geprüft worden.

Ihre eigene KI-Funktion wird zur Angriffsfläche

Die dritte Verschiebung entsteht auf der eigenen Website. Chatbots, automatische Zusammenfassungen, KI-gestützte Suche – all das sind Funktionen, die Inhalte automatisch verarbeiten.

Eine Untersuchung von 17 verbreiteten KI-Chatbot-Plugins auf über 10.000 WordPress-Websites zeigte, wo das Problem liegt: Die Mehrheit dieser Erweiterungen unterschied nicht zwischen den Anweisungen des Betreibers und den Inhalten, die Dritte auf der Seite hinterlassen – Kommentare, Bewertungen, Formulareingaben. In diesem Fall kann jeder, der etwas auf Ihre Website schreiben darf, dem Assistenten Anweisungen geben.

Das Prinzip lässt sich in einem Satz zusammenfassen: Wer Inhalte automatisch verarbeiten lässt, verarbeitet auch das, was Fremde hineinschreiben. Je mehr Rechte ein solcher Assistent hat, desto größer der mögliche Schaden.

Und trotzdem: Der wahrscheinlichste Angriff auf Sie ist kein KI-Angriff

Bei aller Aufmerksamkeit für KI-gestützte Angriffe lohnt der nüchterne Blick auf die Statistik. Der häufigste Weg in eine WordPress-Website führt nicht über eine ausgeklügelte Schwachstelle, sondern über einen gültigen Zugang.

KI verschiebt Umfang und Tempo. Sie verschiebt nicht die Rangfolge der Einfallstore. Wie das konkret aussieht, zeigt der Fall weiter unten.

Warum reichen die üblichen Sicherheits-Checklisten nicht mehr?

Suchen Sie nach „WordPress absichern", bekommen Sie überall dieselbe Liste: Updates einspielen, Zwei-Faktor-Authentifizierung aktivieren, den Benutzernamen „admin" vermeiden, Anmeldeversuche begrenzen, Backups anlegen, Security-Plugin installieren.

Diese Liste ist richtig und notwendig. Sie ist nur nicht mehr ausreichend – und zwar an genau bestimmbaren Stellen:

Der gemeinsame Nenner: Alle vier Maßnahmen setzen an der Software an. Die häufigsten Vorfälle entstehen aber an Zugängen, Berechtigungen und fehlender Beobachtung.

Was schützt eine WordPress-Website wirklich?

Als WordPress-Agentur denken wir Sicherheit in fünf Ebenen statt in einer Liste von zwanzig Einzelmaßnahmen. Der Unterschied ist nicht kosmetisch: Bei einer Liste hakt man ab, bei Ebenen wird sichtbar, wer wofür zuständig ist.

Ebene 1: Zugänge

Zwei-Faktor-Authentifizierung für alle Administratoren, keine geteilten Konten, Rechte streng nach Rolle vergeben und Zugänge sofort entziehen, wenn jemand das Projekt verlässt. Dazu ein regelmäßiger Blick auf die Liste der Administratoren – in gewachsenen Installationen ist sie fast immer länger, als alle Beteiligten vermuten.

Ebene 2: Patch-Betrieb

Eine vorgelagerte Schutzschicht, die bekannte Angriffsmuster abfängt, bevor sie die Anwendung erreichen. Dazu eine Testumgebung und ein Weg, ein Update im Notfall innerhalb eines Tages produktiv zu bringen. Zur Wirksamkeit gängiger Hosting-Schutzmechanismen gibt es eine ernüchternde Zahl – nach Angaben eines Anbieters, der entsprechende Schutzprodukte verkauft, wurde in einem Test nur rund ein Viertel der Angriffe blockiert. Die Zahl ist mit Vorsicht zu lesen; die Richtung deckt sich mit unserer Praxiserfahrung.

Ebene 3: Lieferkette

Ein vollständiges Verzeichnis aller eingesetzten Erweiterungen inklusive ihrer Herkunft. Bewertung nach Wartungsstand und Reaktionszeit des Herstellers, nicht nach Installationszahlen. Und ein klarer Freigabeprozess, bevor eine neue Erweiterung dazukommt.

Ebene 4: KI-Funktionen

Sofern Sie KI-Funktionen auf der Website einsetzen: Anweisungen und Nutzerinhalte müssen technisch getrennt sein, Assistenten bekommen die minimal nötigen Rechte, und jede Aktion wird protokolliert. Ein Assistent, der Inhalte veröffentlichen oder Benutzer anlegen darf, ist kein Komfort-Feature mehr, sondern ein Administrator.

Ebene 5: Betrieb und Wiederherstellung

Backups außerhalb des Servers, mit mindestens einmal jährlich getesteter Wiederherstellung. Eine Überwachung, die meldet, wenn sich Dateien außerhalb eines Deployments ändern oder ein neues Administratorkonto entsteht. Und eine benannte Person, die im Ernstfall entscheidet.

Wer ist wofür zuständig?

Die häufigste Sicherheitslücke im Mittelstand ist keine technische, sondern eine organisatorische: Niemand ist eindeutig verantwortlich.

Hinzu kommt eine Entwicklung, die viele Unternehmen noch nicht auf dem Schirm haben: Mit dem Cyber Resilience Act und NIS2 entstehen Nachweispflichten rund um Software-Bestandteile und Schwachstellenbehandlung. Ein vollständiges Verzeichnis Ihrer Komponenten – Ebene 3 – ist die Grundlage für beides. Wir behandeln das in einem eigenen Beitrag.

Härten oder entkoppeln: Wann lohnt sich der Architekturwechsel?

Wo Härten an seine Grenze kommt

Absicherung verkleinert die Angriffsfläche, ändert aber nichts an der Grundkonstruktion: In einer klassischen WordPress-Installation läuft jede Erweiterung mit denselben Rechten wie die gesamte Website. Ein einziges kompromittiertes Plugin genügt.

Ab einer bestimmten Zahl von Erweiterungen wächst der Wartungsaufwand deshalb schneller als der Sicherheitsgewinn. Genau an diesem Punkt lohnt sich die Frage nach der Architektur.

Was Entkopplung ändert

Bei einem entkoppelten Setup ist die Redaktionsumgebung nicht mehr identisch mit der ausgelieferten Website. WordPress bleibt als Redaktionssystem erhalten – die Oberfläche, die Ihr Team kennt, ändert sich nicht. Was Besucher sehen, wird jedoch von einem eigenen Frontend ausgeliefert, in der Regel auf Basis von Next.js.

Der Sicherheitseffekt ist strukturell: Auf der öffentlich erreichbaren Seite wird kein WordPress-Code mehr ausgeführt. Angriffe, die auf typische WordPress-Pfade zielen, laufen ins Leere. Das Backend liegt hinter einem Zugangsschutz statt offen im Netz.

Wann sich das im Mittelstand rechnet

Wir empfehlen den Wechsel nicht pauschal. Die Entscheidung lässt sich an der Rolle der Website festmachen:

Was Entkopplung nicht löst

Wir wären unglaubwürdig, wenn wir das auslassen würden. Das Redaktions-Backend bleibt ein Ziel. Die Abhängigkeiten des Frontends bilden eine eigene Lieferkette, die gepflegt werden muss. Und der häufigste Weg hinein bleibt derselbe wie zuvor: ein gültiger Zugang in falschen Händen.

Der folgende Fall wäre durch eine Entkopplung nicht verhindert worden. Wir zeigen ihn trotzdem – oder gerade deshalb.

Was tun, wenn es passiert ist?

Aus der Praxis: Zwölf Tage unsichtbar

Ausgangslage. Ein reichweitenstarkes Portal mit eigener Redaktion und externen Partnern. WordPress, über Jahre gewachsen, rund 390 Benutzerkonten – davon 30 mit vollen Administratorrechten. Darunter Redakteure, Agenturen, ehemalige Dienstleister und Partner. Zwei-Faktor-Authentifizierung war nirgends aktiv. In diesem Zustand haben wir die Betreuung des Projekts übernommen – ein in der Branche völlig normaler Zustand.

Was passierte. Angreifer übernahmen den Zugang eines legitimen Administratorkontos. Keine Sicherheitslücke, kein Exploit, kein Patch, der gefehlt hätte – schlicht ein gültiges Passwort in falschen Händen. Mit diesem Zugang legten sie fünf getarnte Administratorkonten an, um sich den Zugriff zu sichern, und nutzten anschließend ein regulär installiertes Plugin mit Dateiverwaltungsfunktion, um die Startseite zu manipulieren. Das Ergebnis war ein sogenanntes Cloaking: Besucher bekamen weiterhin die echte Website zu sehen, Googles Crawler dagegen eine fremde Glücksspiel-Spamseite. Zwischen den Angriffsschritten bearbeitete derselbe Zugang ganz normal Artikel – die Aktivität sah im Backend nach Redaktionsalltag aus.

Auswirkung. Zwölf Tage vergingen zwischen dem ersten unbefugten Zugriff und der Entdeckung. Aufgefallen ist es nicht durch ein Monitoring, sondern weil bei einer Google-Suche nach dem Markennamen plötzlich ein fremder Spam-Eintrag als Titel und Beschreibung erschien. Es gab keinen Ausfall, keine Fehlermeldung, keine Beschwerde von Nutzern. Der Schaden lag ausschließlich dort, wo ihn niemand überwacht hatte: in der Suchsichtbarkeit und in der Marke. Die Bereinigung selbst dauerte einen Arbeitstag – die Wiederherstellung des Vertrauens von Google mehrere Wochen.

Was wir seit der Übernahme geändert haben. Vier Dinge, in dieser Reihenfolge: Zwei-Faktor-Authentifizierung verpflichtend für alle Administratoren. Konsequente Reduktion der Administratorrechte – ein redaktioneller Zugang braucht keine Berechtigung, andere Administratoren anzulegen oder Dateien zu schreiben. Kein Recht mehr, Plugins zu installieren oder zu aktivieren: Erweiterungen kommen ausschließlich über einen kontrollierten Deployment-Prozess auf die Website, nicht mit zwei Klicks aus dem Backend. Und eine Benachrichtigung, sobald ein neues Administratorkonto entsteht oder sich Dateien außerhalb eines Deployments ändern. Jede dieser Maßnahmen kostet wenig Einrichtungsaufwand. Zusammen hätten sie den Vorfall entweder verhindert oder ihn nach Stunden statt nach zwölf Tagen sichtbar gemacht.

Die richtige Reihenfolge nach einem Vorfall

Der häufigste Fehler ist, sofort mit dem Aufräumen zu beginnen. Solange der Angreifer noch eine aktive Sitzung hat, legt er alles innerhalb von Minuten neu an. Die Reihenfolge lautet deshalb:

Zugang unterbrechen – alle Sitzungen beenden, Passwörter und Schlüssel erneuern.
Spuren sichern, bevor etwas gelöscht wird.
Ursache finden – ohne diesen Schritt wiederholt sich der Vorfall.
Hintertüren suchen, auch in der Datenbank und in scheinbar legitimen Dateien.
Erst dann wiederherstellen – und anschließend die Lücke schließen, die den Zugang ermöglicht hat.

Der Grund für Schritt vier: Angreifer legen längst nicht mehr nur eigene Dateien ab, sondern verändern bestehende. Das klassische Suchen und Löschen verdächtiger Dateien greift dann ins Leere.

Fazit

WordPress ist nicht unsicher. WordPress ist das am weitesten verbreitete CMS der Welt und damit das lohnendste Ziel – was etwas anderes ist.

Was sich geändert hat, ist die Rechnung dahinter. Angreifer finden Lücken heute in Stunden, Unternehmen schließen sie in Wochen. Diese Lücke lässt sich nicht durch mehr Plugins schließen, sondern nur durch klare Zuständigkeiten, kontrollierte Prozesse und – ab einer bestimmten Größe – durch eine Architektur, die den Schaden eines einzelnen Fehlers begrenzt.

Eine Frage zum Mitnehmen: Wie viele Administratorkonten hat Ihre Website – und wann haben Sie diese Liste zuletzt gelesen?