Zum Inhalt springen
Wartung & Updates

WordPress-Sicherheit 2026: Härtung und Updates

WordPress absichern 2026: Core-Härtung, Plugin-Sicherheit, Brute-Force-Schutz, Web Application Firewall und Security-Monitoring im Praxis-Leitfaden.

13 Min. Lesezeit WordPressSicherheitHärtungWAFMonitoring

Kurz und einfach erklärt

WordPress ist ein beliebtes Ziel für Angreifer. Oft kommen sie über Lücken in Erweiterungen herein.

Mit einem guten Plan kann man es Angreifern schwerer machen.

Der Beitrag zeigt die Schritte. Dazu gehören Updates und gute Werte im System. Zu viele falsche Logins werden gebremst. Ein Filter hält böse Anfragen ab. Ein Wächter meldet, was auffällt.

Wir schützen Ihre Website mit mehreren Schritten und überwachen sie.

WordPress betreibt 43 Prozent aller Websites weltweit (W3Techs, 2026) – und ist damit das bevorzugte Ziel von Angreifern. Allein im Jahr 2025 wurden 4,3 Millionen WordPress-Websites durch Schwachstellen in Plugins kompromittiert (Patchstack, 2025). Die gute Nachricht: Mit einer systematischen Härtungsstrategie lässt sich die Angriffsfläche gezielt verkleinern. Dieser Leitfaden zeigt, wie Sie Ihre WordPress-Installation in 2026 professionell absichern – von der Core-Härtung über Plugin-Sicherheit bis zum Echtzeit-Monitoring.

Das Wichtigste in Kürze

  • Der WordPress-Kern ist nicht mehr das Hauptziel: 97 Prozent der Schwachstellen liegen in Plugins und Themes (Patchstack, 2025), angeführt von Cross-Site-Scripting mit 47 Prozent (WPScan, 2025). Neue Plugin-Lücken werden binnen 24 bis 48 Stunden ausgenutzt (CISA, 2025).
  • Core-Härtung heißt konkret: Verzeichnisse auf 755, Dateien auf 644, wp-config.php auf 440 und möglichst außerhalb des Web-Root, Dateibearbeitung im Dashboard per DISALLOW_FILE_EDIT sperren, Versionsangaben entfernen und XML-RPC abschalten, wenn es nicht gebraucht wird.
  • Jedes Plugin vergrößert die Angriffsfläche, auch im deaktivierten Zustand, weil seine Dateien direkt aufrufbar bleiben. Plugins ohne Update seit über 12 Monaten gehören ausgemustert; was nicht gebraucht wird, wird gelöscht statt nur deaktiviert.
  • Login-Härtung kombiniert Rate-Limiting mit 30-minütiger IP-Sperre nach fünf Fehlversuchen, eine geänderte Login-URL, Zwei-Faktor-Authentifizierung per TOTP und das Abschalten der Benutzerauflistung über REST-API und /?author=1.
  • Eine Web Application Firewall filtert Angriffsmuster vor WordPress und überbrückt per Virtual Patching die durchschnittlich 6 Tage bis zum Plugin-Update (Patchstack, 2025). Die Content-Security-Policy startet im Report-Only-Modus, sonst brechen Editor und Einbettungen.
  • File-Integrity-Monitoring meldet neue PHP-Dateien im Upload-Ordner, die Datenbank läuft mit eigenem Tabellenpräfix und ohne DROP- oder FILE-Recht, Backups liegen verschlüsselt extern. Absolute Sicherheit entsteht daraus nicht, wohl aber Erkennung in Echtzeit.

WordPress-Bedrohungslandschaft 2026

Die WordPress-Sicherheitslandschaft hat sich in den letzten Jahren verändert. Während früher hauptsächlich der WordPress-Core Ziel von Angriffen war, entfallen heute 97 Prozent aller WordPress-Schwachstellen auf Plugins und Themes (Patchstack, 2025). Der Core selbst ist durch das WordPress-Sicherheitsteam und die große Community gut geschützt. Die eigentliche Angriffsfläche liegt in den tausenden verfügbaren Erweiterungen, die von Einzelentwicklern bis zu großen Teams mit sehr unterschiedlichen Sicherheitsstandards gepflegt werden.

Die häufigsten Angriffstypen im Jahr 2026 sind Cross-Site-Scripting (XSS) mit 47 Prozent aller gemeldeten Schwachstellen, gefolgt von SQL-Injection (15 Prozent), Broken Access Control (12 Prozent) und Cross-Site Request Forgery (CSRF) (10 Prozent) (WPScan, 2025). Brute-Force-Angriffe auf wp-login.php und XML-RPC bleiben eine konstante Bedrohung, die bei ungeschützten Installationen zu erheblichem Ressourcenverbrauch führt – auch wenn sie selten zum direkten Einbruch führen.

Automatisierte Botnets scannen das Internet kontinuierlich nach verwundbaren WordPress-Installationen. Eine neu veröffentlichte Plugin-Schwachstelle wird typischerweise innerhalb von 24 bis 48 Stunden aktiv ausgenutzt (CISA, 2025). Betreiber, die Updates verzögern oder ihre Installation nicht aktiv überwachen, setzen ihre Website und die Daten ihrer Nutzer einem erheblichen Risiko aus.

Core-Härtung

Dateiberechtigungen, wp-config.php absichern, Dateibearbeitung deaktivieren, Versionsinformationen verbergen und REST-API einschränken.

Login-Schutz

Zwei-Faktor-Authentifizierung, Login-URL ändern, Brute-Force-Schutz mit Rate-Limiting und automatischer IP-Sperre.

Datei-Integrität

Automatische Checksummen-Prüfung für Core-Dateien, Änderungsbenachrichtigungen und Erkennung unbekannter Dateien.

Web Application Firewall

Regelbasierte Filterung von Anfragen, Schutz vor SQL-Injection und XSS, virtuelle Patches für bekannte Schwachstellen.

Security-Monitoring

Echtzeit-Überwachung von Login-Versuchen, Dateiänderungen und verdächtigen Anfragen mit sofortiger Alarmierung.

Security Headers

Content-Security-Policy, X-Frame-Options, HSTS, Referrer-Policy und Permissions-Policy als zusätzliche Schutzschicht.

Core-Härtung: Die Basis jeder WordPress-Absicherung

Die Core-Härtung umfasst alle Maßnahmen, die die WordPress-Installation selbst gegen Angriffe schützen. Der erste Schritt ist die korrekte Dateiberechtigung: Verzeichnisse sollten auf 755, Dateien auf 644 und die wp-config.php auf 440 gesetzt sein. Diese Berechtigungen stellen sicher, dass der Webserver die Dateien lesen kann, aber nicht unbefugt schreiben darf. Eine zu lockere Berechtigung wie 777 auf dem Upload-Verzeichnis ist eine der häufigsten Ursachen für erfolgreiche Angriffe.

Die wp-config.php enthält die sensibelsten Informationen der Installation – Datenbankzugangsdaten, Authentication Keys und Salts. Diese Datei sollte außerhalb des Web-Root verschoben werden (WordPress unterstützt dies nativ) oder zumindest durch eine .htaccess-Regel vor direktem Zugriff geschützt werden. Zusätzlich sollte die Dateibearbeitung über das Dashboard deaktiviert werden (DISALLOW_FILE_EDIT), damit ein kompromittiertes Admin-Konto nicht direkt Schadcode in Theme- oder Plugin-Dateien einfügen kann.

Weitere Härtungsmaßnahmen betreffen die Versionsinformationen: WordPress gibt standardmäßig die installierte Version im HTML-Header, in der readme.html und über die REST-API preis. Angreifer nutzen diese Informationen, um gezielt Exploits für die installierte Version einzusetzen. Das Entfernen dieser Informationen ist eine einfache, aber wirkungsvolle Maßnahme. Ebenso sollte die XML-RPC-Schnittstelle deaktiviert werden, wenn sie nicht benötigt wird – sie ist ein beliebter Vektor für Brute-Force-Angriffe und DDoS-Verstärkung.

Plugin-Sicherheit: Die größte Angriffsfläche minimieren

Da 97 Prozent der Schwachstellen in Plugins und Themes liegen (Patchstack, 2025), ist die Plugin-Sicherheit der wichtigste Hebel für die Gesamtsicherheit. Der erste Schritt ist ein Plugin-Audit: Wie viele Plugins sind installiert? Werden alle aktiv genutzt? Wann wurden sie zuletzt aktualisiert? Wie groß ist die Nutzerbasis und wie reaktiv ist der Entwickler bei Sicherheitsproblemen? Plugins, die seit über 12 Monaten kein Update erhalten haben, sind ein erhebliches Risiko.

Die Reduktion der installierten Plugins auf das notwendige Minimum ist die effektivste Sicherheitsmaßnahme. Jedes Plugin erweitert die Angriffsfläche – auch wenn es deaktiviert ist, können seine Dateien direkt aufgerufen werden. Jedes entfernte Plugin bedeutet weniger Code, der Lücken enthalten kann, und ein Update weniger, das eingespielt werden muss. Der Plugin-Audit identifiziert überflüssige Erweiterungen und zeigt Alternativen auf, die mehrere Plugin-Funktionen in einer sicheren Lösung vereinen.

Für die verbleibenden Plugins gilt: Automatische Updates für Sicherheitspatches aktivieren, regelmäßig die Sicherheitsdatenbanken prüfen und bei bekannten Schwachstellen sofort handeln. Die WordPress-eigene Auto-Update-Funktion für Plugins (seit Version 5.5) ermöglicht eine differenzierte Steuerung: kritische Sicherheitsplugins erhalten automatische Updates, während bei Checkout- oder Shop-Plugins manuelle Freigabe nach Staging-Tests sinnvoller ist.

Brute-Force-Schutz und Login-Härtung

Brute-Force-Angriffe auf die WordPress-Login-Seite gehören zum Grundrauschen jeder öffentlichen Website. Automatisierte Skripte probieren dort laufend Kombinationen aus Benutzernamen und Passwörtern durch. Selbst wenn diese Angriffe selten zum Erfolg führen, belasten sie den Server und können bei schwachen Passwörtern zur Kompromittierung führen.

Der effektivste Schutz kombiniert mehrere Maßnahmen: Rate-Limiting begrenzt die Anzahl erlaubter Login-Versuche pro IP-Adresse – nach fünf fehlgeschlagenen Versuchen wird die IP für 30 Minuten gesperrt. Die Änderung der Login-URL von /wp-login.php auf eine individuelle Adresse eliminiert automatisierte Angriffe, die gezielt die Standard-URL ansprechen. Zwei-Faktor-Authentifizierung (2FA) macht selbst kompromittierte Passwörter wertlos, da zusätzlich ein zeitbasiertes Einmalpasswort (TOTP) erforderlich ist.

Zusätzlich empfehlen wir die Deaktivierung der Benutzerauflistung: WordPress gibt standardmäßig über die REST-API und über /?author=1 die Benutzernamen preis. Angreifer nutzen diese Information, um gezielt Passwörter für bekannte Benutzernamen zu testen. Die Deaktivierung der Benutzerauflistung in Kombination mit der Verwendung eines vom Anzeigenamen abweichenden Login-Namens erschwert Brute-Force-Angriffe erheblich.

Web Application Firewall: Angriffe filtern

Eine Web Application Firewall (WAF) analysiert den eingehenden HTTP-Traffic und blockiert bekannte Angriffsmuster, bevor sie die WordPress-Anwendung erreichen. Im Gegensatz zu einer Netzwerk-Firewall versteht die WAF die Anwendungslogik und kann SQL-Injection, XSS und Remote Code Execution erkennen und blockieren. Für WordPress-Installationen bieten sich sowohl cloudbasierte WAFs als auch serverbasierte Lösungen an.

Ein besonders wertvolles Feature moderner WAFs ist das Virtual Patching: Wenn eine Schwachstelle in einem Plugin bekannt wird, aber noch kein offizielles Update verfügbar ist, kann die WAF den spezifischen Angriffsvektor blockieren. Dies schließt das Zeitfenster zwischen Bekanntwerden der Schwachstelle und Verfügbarkeit des Updates – ein Zeitfenster, das Angreifer aktiv ausnutzen. Laut Patchstack (2025) dauert es durchschnittlich 6 Tage von der Schwachstellenveröffentlichung bis zum Plugin-Update.

Die WAF-Konfiguration erfordert Feinabstimmung: Zu strenge Regeln blockieren legitime Anfragen (False Positives), zu lockere Regeln lassen Angriffe durch. Ein professionelles Sicherheits-Setup umfasst die initiale Konfiguration, eine Lernphase mit Monitoring und die kontinuierliche Anpassung der Regelsets an die spezifische WordPress-Installation und ihre Plugins.

Security Headers richtig konfigurieren

HTTP-Security-Headers sind eine oft vernachlässigte, aber wirkungsvolle Schutzschicht. Sie instruieren den Browser des Besuchers, bestimmte Sicherheitsrichtlinien durchzusetzen. Die Content-Security-Policy (CSP) definiert, von welchen Quellen JavaScript, CSS und Bilder geladen werden dürfen – ein effektiver Schutz gegen XSS-Angriffe. X-Frame-Options verhindert Clickjacking, HSTS erzwingt die HTTPS-Verbindung und die Referrer-Policy kontrolliert, welche Informationen beim Klick auf ausgehende Links übermittelt werden.

Die Konfiguration der CSP ist für WordPress-Websites besonders anspruchsvoll, da viele Plugins und Themes Inline-JavaScript und externe Ressourcen verwenden. Eine zu restriktive CSP kann Funktionen brechen – etwa den visuellen Editor oder eingebettete Inhalte. Die professionelle Implementierung beginnt mit einer Report-Only-Phase, in der Verstöße protokolliert aber nicht blockiert werden. Nach Analyse der Reports wird die CSP schrittweise verschärft, bis ein optimaler Kompromiss zwischen Sicherheit und Funktionalität erreicht ist.

Ein vollständig konfiguriertes Set von Security Headers verbessert nicht nur die Sicherheit, sondern auch den Security-Score in Tools wie dem Mozilla Observatory. Ein A+-Rating signalisiert Besuchern und Suchmaschinen, dass die Website professionell betrieben wird. Die Headers werden auf Serverebene konfiguriert (Apache oder Nginx) und erfordern keine Änderungen an der WordPress-Installation selbst.

Datei-Integritäts-Monitoring: Veränderungen erkennen

File Integrity Monitoring (FIM) überwacht die Dateien der WordPress-Installation auf unerwartete Änderungen. Wenn ein Angreifer eine Backdoor einschleust oder eine Datei modifiziert, erkennt FIM die Änderung und alarmiert den Administrator. WordPress bietet eine eingebaute Checksummen-Prüfung für Core-Dateien – diese vergleicht die installierten Dateien mit den offiziellen Checksummen und meldet Abweichungen.

Professionelles FIM geht über die Core-Prüfung hinaus und überwacht auch Plugin-Verzeichnisse, Theme-Dateien und Upload-Ordner. Besonders der Upload-Ordner ist ein häufiges Ziel: Angreifer laden Schadcode als vermeintliche Bilddateien hoch, die dann über eine Schwachstelle in einem Plugin ausgeführt werden. FIM erkennt neue PHP-Dateien im Upload-Verzeichnis und meldet sie sofort als verdächtig.

Die Herausforderung bei FIM liegt in der Unterscheidung zwischen legitimen und verdächtigen Änderungen. Ein Plugin-Update ändert Dateien – das ist erwünscht. Auch Cache-Dateien und temporäre Dateien ändern sich regelmäßig. Ein gut konfiguriertes FIM-System kennt diese Ausnahmen und meldet nur tatsächlich verdächtige Änderungen. Die Integration in das Security-Monitoring stellt sicher, dass Alarme zeitnah ausgewertet und bearbeitet werden.

Automatische Updates und Update-Management

WordPress bietet seit Version 5.6 automatische Updates für den Core und seit Version 5.5 für Plugins und Themes. Die Frage, welche Updates automatisch eingespielt werden sollten, hängt von der Art der Website ab. Für reine Content-Websites ohne komplexe Plugins und ohne laufende Betreuung sind automatische Updates für Core-Sicherheitspatches und geprüfte Plugins ein pragmatischer Mindestschutz – mit dem Nachteil, dass ein fehlerhaftes Update ungeprüft live geht. Für Online-Shops und geschäftskritische Websites ist ein kontrollierter Prozess mit Staging-Tests sinnvoller.

So gehen wir in der Wartung geschäftskritischer WordPress-Installationen vor: Die automatischen Updates schalten wir in der Regel ab und ersetzen sie durch kontrollierte, getestete Updates. Auch Core-Sicherheitspatches (Minor-Releases) laufen zuerst über die Staging-Umgebung, Major-Releases erst nach umfassendem Test. Plugins mit bekannten Sicherheitslücken werden priorisiert aktualisiert; funktionale Plugin-Updates werden gesammelt und im festen Wartungszyklus eingespielt.

Ein oft übersehener Aspekt ist das Theme-Update: Viele WordPress-Websites nutzen ein Premium-Theme, das nicht über das offizielle WordPress-Repository aktualisiert wird. Diese Themes müssen manuell geprüft und aktualisiert werden. Child-Theme-Anpassungen können bei Theme-Updates überschrieben werden, wenn sie nicht korrekt in einem Child-Theme separiert sind. Die regelmäßige Prüfung und Aktualisierung aller Themes – aktive und inaktive – ist Bestandteil einer umfassenden Sicherheitsstrategie.

Die konsequente Anwendung des Least-Privilege-Prinzips ist dabei der effektivste Einzelansatz: Jeder Benutzer, jedes Plugin und jeder Prozess erhält nur die minimal notwendigen Berechtigungen. Ein Redakteur braucht keinen Administrator-Zugang, ein Kontaktformular-Plugin keinen Zugriff auf die Benutzertabelle. Diese Einschränkung begrenzt den Schaden, falls eine einzelne Komponente kompromittiert wird – der Angreifer erhält nur die Rechte der betroffenen Komponente, nicht die volle Kontrolle über das System.

Datenbank-Sicherheit und Backup-Strategie

Die WordPress-Datenbank enthält alle Inhalte, Benutzerkonten und Konfigurationen. Ihr Schutz hat höchste Priorität. Die Maßnahmen beginnen bei der Installation: Ein individueller Tabellenpräfix statt des Standard-Präfixes wp_ erschwert SQL-Injection-Angriffe, die auf bekannte Tabellennamen abzielen. Der Datenbankbenutzer sollte nur die minimal notwendigen Rechte besitzen – SELECT, INSERT, UPDATE, DELETE und CREATE/ALTER TABLE für Updates. Rechte wie DROP oder FILE sind nicht erforderlich und stellen ein Risiko dar.

Regelmäßige Datenbank-Backups sind die letzte Verteidigungslinie. Wenn alle anderen Maßnahmen versagen und die Website kompromittiert wird, ermöglicht ein aktuelles Backup die vollständige Wiederherstellung. Für WordPress-Websites empfehlen wir tägliche Datenbank-Backups mit einer Aufbewahrungszeit von mindestens 30 Tagen. Die Backups sollten verschlüsselt und an einem externen Speicherort abgelegt werden – nicht auf dem gleichen Server wie die WordPress-Installation.

Die umfassende WordPress-Absicherung ist kein einmaliges Projekt, sondern ein kontinuierlicher Prozess. Neue Schwachstellen werden täglich entdeckt, Angriffsmethoden entwickeln sich weiter und die WordPress-Landschaft verändert sich mit jedem Plugin-Update. Eine professionelle Wartungsstrategie kombiniert automatisierte Maßnahmen mit regelmäßiger manueller Prüfung und hält die Schutzschichten Ihrer WordPress-Website auf aktuellem Stand. Die Investition in Sicherheit ist dabei in der Regel günstiger als die Behebung eines erfolgreichen Angriffs – sowohl finanziell als auch in Bezug auf den Vertrauensverlust bei Kunden und Suchmaschinen.

Quellen und Studien

Dieser Artikel basiert auf Daten aus: W3Techs Web Technology Surveys (2026), Patchstack State of WordPress Security (2025), WPScan Vulnerability Database Report (2025), CISA Known Exploited Vulnerabilities Catalog (2025). Die genannten Zahlen können je nach Konfiguration und Hosting-Umgebung variieren.

Verwandte Artikel

Sicherheit

Rabattcodes in der Black Week: Missbrauch früh erkennen

Rabattcodes in der Black Week schützen: Codelänge, Rate-Limit am Gutscheinfeld, Alarm bei Fehlversuchen und ein Neukundenrabatt, der Mehrfachkonten standhält.

21 Min. Lesezeit
Sicherheit

WAF und Bot-Schutz im laufenden Shop-Betrieb

WAF und Bot-Management als Teil der Wartung: So schützen Sie Ihren Shop vor automatisierten Angriffen, Scraping und Fake-Traffic im laufenden Betrieb.

13 Min. Lesezeit
Wartung & Updates

WordPress-Sicherheitsupdates: Was alte Zweige noch bekommen

WordPress 7.1.2 schloss eine kritische Lücke, der Fix kam als Gefälligkeit bis 4.7 zurück. Was ältere Zweige erhalten, was nicht und wann der Sprung fällig ist.

20 Min. Lesezeit