Kurzfassung: WordPress-Sicherheit ist 2026 vor allem ein Plugin-Problem, nicht ein Core-Problem: Der Kern ist gut gehärtet, aber die Erweiterungen sind die große Angriffsfläche, mit hunderten neuen Schwachstellen pro Woche, vielen davon ohne Anmeldung ausnutzbar. Für ein Blue Team, das WordPress betreibt oder überwacht, gilt dasselbe wie überall: die Angriffsfläche verkleinern (weniger Plugins, keine verwaisten), zeitnah patchen, den Zugang absichern und die richtigen Logquellen überwachen. Die wichtigsten Signale sind neue Admin-Konten, geänderte Dateien, verdächtige Anfragen an Plugin-Endpunkte und Anmeldungen aus ungewohnten Regionen. Dazu kommt eine neue Bedrohung: der Supply-Chain-Angriff über die Update-Infrastruktur eines Plugins.
WordPress-Sicherheit für Blue Teams ist ein Thema, das viele Verteidiger unterschätzen, obwohl WordPress einen erheblichen Teil des Webs betreibt und in fast jeder Organisation irgendwo läuft, sei es die Firmenwebsite, das Blog oder das Kundenportal. Dieser Beitrag betrachtet WordPress aus Blue-Team-Sicht: als Angriffsziel, das man härten und überwachen muss, und als Logquelle, die im Ernstfall die Antworten liefert. Er ist bewusst praxisnah und speist sich auch aus eigener Erfahrung mit WordPress-Schwachstellen; diese Seite selbst läuft auf WordPress. Es geht um die Frage, wo die Angriffe wirklich ansetzen, wie man die Angriffsfläche verkleinert, welche Logquellen zählen und was die neue Supply-Chain-Bedrohung für die Verteidigung bedeutet.
Der Kern ist sicher, die Plugins sind es nicht
Die wichtigste Einsicht zuerst, weil sie die ganze Verteidigung ausrichtet: WordPress-Core ist nach jedem vernünftigen Maßstab bemerkenswert sicher. Ein hauptamtliches Sicherheitsteam pflegt ihn, Schwachstellen werden schnell geschlossen, und Kernlücken sind selten. Das Problem liegt im Ökosystem der Erweiterungen: Zehntausende Plugins und Themes unterschiedlichster Qualität, viele von ehrenamtlichen oder längst inaktiven Entwicklern, sind die große Angriffsfläche. Die Zahlen aus den Lageberichten der WordPress-Sicherheitsdienste sind deutlich: hunderte neue Plugin-Schwachstellen pro Woche, ein erheblicher Teil davon ohne Anmeldung ausnutzbar, und die meisten Einbrüche beginnen bei einem Plugin, nicht beim Core. Wer WordPress verteidigt, verteidigt also in erster Linie die Plugins. Und ein zweiter Faktor beschleunigt das gerade: KI-Werkzeuge finden Schwachstellen in Plugin-Code schneller und billiger als je zuvor, was das Volumen weiter erhöht, auf der Angriffs- wie auf der Verteidigungsseite.
Die Angriffsfläche verkleinern
Weil die Plugins das Risiko sind, ist ihre Reduktion die wirksamste Maßnahme. Das ist dieselbe Disziplin wie überall in der Verteidigung: Was nicht da ist, kann nicht angegriffen werden.
- Weniger Plugins. Jedes Plugin ist zusätzliche Angriffsfläche. Was nicht gebraucht wird, wird nicht deaktiviert, sondern gelöscht, weil auch ein inaktives Plugin angreifbar sein kann.
- Keine verwaisten Plugins. Ein Plugin, das seit Monaten kein Update bekommen hat, wird nie gepatcht und ist eine dauerhafte Lücke. Angreifer suchen gezielt danach. Verwaiste Plugins gehören ersetzt oder entfernt.
- Vor der Installation prüfen. Wird ein Plugin aktiv gepflegt, wann kam das letzte Update, wie viele Installationen, gibt es offene Sicherheitsmeldungen? Diese Prüfung gehört vor die Installation, nicht nach dem Vorfall.
- Zeitnah patchen. Der größte einzelne Hebel. Ein erheblicher Teil der offengelegten Schwachstellen bleibt wochenlang ungepatcht, und genau dieses Fenster nutzen die automatisierten Angriffe. Automatische Updates für Plugins, wo möglich, und ein Überwachen der Schwachstellenmeldungen für die eingesetzten Komponenten. Das ist die WordPress-Variante des Schwachstellenmanagements, wie es der BSI-Lagebericht als Kernmaßnahme nennt.
Den Zugang absichern
Neben den Plugin-Schwachstellen ist der zweite Angriffsweg der Zugang zum Administrationsbereich. Die Maßnahmen sind dieselben wie bei jeder Identität: MFA für alle Konten mit erhöhten Rechten, starke und einzigartige Passwörter, und so wenige Administratorkonten wie möglich. Die Anmeldeseite ist das Ziel von Brute-Force- und Password-Spraying-Angriffen, weshalb eine Begrenzung der Anmeldeversuche und das Aussperren nach zu vielen Fehlversuchen zum Standard gehören. Dass Administratoren aus dem Dashboard heraus Plugin- und Theme-Dateien bearbeiten können, ist bequem, aber gefährlich: Ein übernommenes Adminkonto kann so direkt Schadcode einbringen. Diese Bearbeitungsfunktion sollte abgeschaltet sein, damit ein kompromittiertes Konto nicht sofort zur Codeausführung führt.
Die Logquellen, die zählen
Für die Erkennung ist WordPress eine Logquelle wie jede andere, und die Signale ähneln denen, die aus dem Rest der Seite bekannt sind. Die wichtigsten:
| Signal | Warum es zählt |
|---|---|
| Neues Administratorkonto | Eines der stärksten Signale. Ein neu angelegtes Adminkonto, das niemand kennt, ist das häufigste Zeichen einer Übernahme. |
| Geänderte Kern- oder Plugin-Dateien | WordPress-Dateien ändern sich nur bei Updates. Eine Änderung außerhalb eines Updates deutet auf eingeschleusten Code oder eine Hintertür. Datei-Integritätsprüfung deckt das auf. |
| Verdächtige Anfragen an Plugin-Endpunkte | Wiederholte, ungewöhnliche Anfragen an die AJAX- und REST-Endpunkte von Plugins, oft mit Einschleusungs-Mustern, sind der Versuch, eine Schwachstelle auszunutzen. 500er-Fehler auf diesen Endpunkten sind ein Hinweis. |
| Anmeldungen aus ungewohnten Regionen | Die Cloud-Variante der Anomalie: eine erfolgreiche Anmeldung am Adminbereich aus einem Land, aus dem niemand arbeitet. |
| Neue geplante Aufgaben (Cronjobs) | Angreifer nutzen WordPress-Cronjobs für Persistenz, ähnlich den geplanten Aufgaben unter Windows. |
| Hochgeladene Dateien in Upload-Verzeichnissen | Eine ausführbare PHP-Datei im Upload-Ordner ist fast immer eine Web-Shell. Uploads gehören überwacht und die Ausführung von PHP dort unterbunden. |
Diese Signale lassen sich über ein Sicherheits-Plugin sammeln, das Anmeldungen, Dateiänderungen und Adminaktionen protokolliert, und idealerweise zusätzlich an ein zentrales SIEM weiterleiten, damit sie neben den übrigen Logquellen stehen und dieselbe Aufbewahrung und denselben Manipulationsschutz genießen wie im Beitrag zu Log-Management und Aufbewahrung beschrieben. Auf Serverebene ergänzen eine Web Application Firewall, die bekannte Angriffsmuster blockiert, und eine Datei-Integritätsprüfung die Anwendungssicht, ein mehrschichtiger Aufbau wie bei jeder anderen Verteidigung.
Die neue Bedrohung: Supply Chain über Updates
Eine Entwicklung von 2026 verdient besondere Aufmerksamkeit, weil sie die bisherige Logik aushebelt. Der Rat „immer sofort updaten“ ist richtig, aber Angreifer haben gelernt, genau diesen Mechanismus anzugreifen: Sie kompromittieren die Update-Infrastruktur eines Plugin-Anbieters und verteilen über den legitimen Update-Weg eine bösartige Version an alle Nutzer. Mehrere solcher Fälle sind dokumentiert, teils über übernommene Entwicklerkonten, teils über eine neue Betreuung eines Plugins, die eine Hintertür einschleust. Das ist die WordPress-Ausprägung des Supply-Chain-Angriffs: Die Vertrauensbeziehung zum Lieferanten wird zum Angriffsweg. Für die Verteidigung folgt daraus, dass auch Updates nicht blind vertraut werden darf. Die Gegenmaßnahmen sind dieselben wie beim allgemeinen Supply-Chain-Angriff: die Datei-Integritätsprüfung, die eine unerwartete Änderung meldet, das Beobachten des Verhaltens nach einem Update (spricht die Seite plötzlich mit neuen Zielen?), und die Threat Intelligence, die kompromittierte Plugin-Versionen schnell bekannt macht.
Wenn es passiert ist
Ist eine WordPress-Seite kompromittiert, gilt der Incident-Response-Prozess auch hier: den Zugang sperren und alle Zugangsdaten rotieren, den Umfang über die Logs rekonstruieren, die eingeschleusten Dateien und Hintertüren finden und entfernen, und die ausgenutzte Schwachstelle schließen. Der wichtigste Punkt: Eine bereinigte Seite ist oft nicht vertrauenswürdig, weil Hintertüren leicht übersehen werden. Der sichere Weg ist der Wiederaufbau aus einem sauberen Backup von vor der Kompromittierung, kombiniert mit dem Schließen der Lücke, damit derselbe Weg nicht sofort wieder offensteht. Und weil die Sicherung selbst zum Ziel geworden ist, gehört die Backup-Infrastruktur ausdrücklich zum geschützten Bereich.
Fazit
WordPress-Sicherheit ist für ein Blue Team kein Sonderthema, sondern die vertrauten Prinzipien, angewandt auf eine Plattform, die fast überall läuft: die Angriffsfläche verkleinern, weil die Plugins das Risiko sind, zeitnah patchen, den Zugang mit MFA und wenigen Adminkonten absichern, die richtigen Signale überwachen und die Update-Kette als neuen Angriffsweg mitdenken. Der Kern ist sicher, die Erweiterungen sind es nicht, und genau dort liegt die Arbeit. Für ein Blue Team, das WordPress betreibt oder für Kunden überwacht, ist die wichtigste Haltung, die Plattform ernst zu nehmen: Sie ist so oft Angriffsziel, weil sie so verbreitet ist, und sie verdient dieselbe Sorgfalt wie jedes andere System im Netz.