WordPress-Security 2026: Die 12 Stellschrauben, die wirklich zählen

Die Sicherheitslage 2026

WordPress betreibt über 40 Prozent aller Websites weltweit — und ist damit das attraktivste Ziel für automatisierte Angriffe. Die gute Nachricht: der Core ist seit Jahren stabil. 90 Prozent aller erfolgreichen Angriffe nutzen drei Schwachstellen:

• veraltete oder verwaiste Plugins
• schwache Admin-Passwörter ohne Zwei-Faktor
• ungesicherter Login-Endpoint wp-login.php

Wer diese drei Themen sauber löst, blockiert den Großteil der Angriffsversuche. Die anderen neun Maßnahmen erhöhen das Niveau systematisch.

Sechs Pflicht-Maßnahmen

1. Updates konsequent

Core-Security-Updates sind seit Version 3.7 standardmäßig automatisch. Plugin- und Theme-Updates müssen aktiv gemanagt werden — idealerweise wöchentlich, bei kritischen Seiten mit Staging-Test vor Live-Deploy.

2. Starke Passwörter + Zwei-Faktor

Passwörter ab 16 Zeichen, aus einem Passwort-Manager. 2FA per TOTP-App (Aegis, Bitwarden, 1Password) für alle Administratoren — nicht per SMS. Plugin-Empfehlung: WP 2FA oder Two Factor.

3. Login-Endpoint schützen

Drei Optionen: Rate-Limiting (Plugin oder Cloudflare), Login-URL umbenennen (WPS Hide Login), IP-Whitelisting via .htaccess für kleine Admin-Teams. Kombination aus 1 und 2 ist der pragmatische Standard.

4. TLS/HTTPS ohne Mischinhalte

Let's Encrypt ist kostenlos und verlängert sich automatisch. Wichtig: keine Mischinhalte (HTTP-Bilder auf HTTPS-Seiten). HSTS-Header mit mindestens sechs Monaten Gültigkeit setzen, upgrade-insecure-requests via CSP aktivieren.

5. File-Editing im Admin deaktivieren

In wp-config.php: define('DISALLOW_FILE_EDIT', true);. Das verhindert, dass Angreifer nach einem Admin-Login direkt Code in Theme- oder Plugin-Dateien einschleusen.

6. Datei-Rechte sauber

Standard: Verzeichnisse 755, Dateien 644, wp-config.php auf 600. Owner sollte nie der Webserver-User selbst sein, sondern ein separater Deploy-User mit minimalen Rechten.

Sechs fortgeschrittene Maßnahmen

7. Web Application Firewall

Cloudflare (kostenlose Stufe ausreichend für viele Seiten), Sucuri oder selbst gehostet mit ModSecurity. Blockiert die häufigsten Injection-Muster bevor sie die Anwendung erreichen.

8. Fail2Ban auf Server-Ebene

Liest nginx- oder Apache-Logs und sperrt IPs nach mehreren fehlgeschlagenen Logins oder Scan-Mustern automatisch per iptables. Erheblich effizienter als Plugin-basierte Rate-Limits, weil der Traffic nicht mal PHP erreicht.

9. Content Security Policy

Strikte CSP-Header schränken ein, welche Skripte geladen werden dürfen. Am Anfang im Report-Only-Modus deployen, Violations sammeln, dann scharf schalten. Schutz gegen XSS, auch wenn eine Lücke im Theme existiert.

10. Unbenutzte Plugins löschen

Deaktivieren reicht nicht — der Code bleibt auf dem Server und kann angreifbar bleiben. Jedes Plugin, das nicht aktiv gebraucht wird, restlos entfernen. Themes genauso: nur ein aktives Theme, plus Twenty-X als Fallback.

11. Datenbank-Präfix und Admin-User-ID

Standard-Präfix wp_ ändern (nur bei Neu-Installation sinnvoll), Admin-User nicht auf ID 1. Beides macht generische Angriffs-Payloads teurer — keine Wunderwaffe, aber Reibung, die Bots oft abbrechen lässt.

12. XML-RPC und REST-API einschränken

XML-RPC (xmlrpc.php) ist 2026 für kaum noch etwas nötig und ein klassischer Amplifier für Brute-Force-Angriffe. Wenn keine mobile App oder Jetpack-Anbindung: komplett deaktivieren. Bei der REST-API nicht-öffentliche Endpoints mit Auth schützen.

Security-Plugins — welches wofür

Die vier bekannten:

• Wordfence — starker All-in-One, Firewall + Scanner. Kostenpflichtige Version deutlich besser. Kann bei großen Seiten ressourcenhungrig sein.
• Sucuri — guter Scanner, WAF ist SaaS (Cloud-Proxy). Für Kunden mit Hosting ohne eigene WAF-Option interessant.
• iThemes Security (jetzt Solid Security) — viele Hardening-Optionen an einem Ort, gutes Login-Schutz-Paket.
• Limit Login Attempts Reloaded — leichtgewichtig, macht nur Rate-Limiting. In Kombination mit Cloudflare oft ausreichend.

Kein Plugin ersetzt das Grundkonzept. Wer alle 12 Punkte oben umsetzt, braucht oft nur noch ein schlankes Login-Limit-Plugin plus Cloudflare.

Backup-Strategie: der nicht verhandelbare Teil

Regel: 3-2-1 — drei Kopien, zwei verschiedene Medien, eine offsite. Konkret:

• täglich automatisiertes Backup (UpdraftPlus, BackWPup, Duplicator Pro oder server-nativ)
• Ziel: anderer Server oder S3-kompatibler Storage (Hetzner Storage-Box, AWS S3, Backblaze B2)
• Aufbewahrung: mindestens 30 Tage täglich + 6 Monate wöchentlich
• Ein Restore-Test pro Quartal — ein Backup, das nie getestet wurde, ist kein Backup

DSGVO und Security — dieselbe Münze

Art. 32 DSGVO verpflichtet zu „geeigneten technischen und organisatorischen Maßnahmen". Die 12 Punkte oben sind im Kern der DSGVO-Standard für eine Website mit personenbezogenen Daten.

Zusätzlich: AV-Vertrag mit dem Hoster, Logs ohne IP-Klartext oder mit kurzer Aufbewahrung, klares Verfahren für Datenpannen-Meldung innerhalb von 72 Stunden.

Wenn es doch passiert

Angriff erkannt — die ersten vier Schritte:

1. Isolation — Seite in Wartungsmodus, Änderungen sperren
2. Snapshot — aktuelles Image für Forensik, auch wenn „alles zerstört" wirkt
3. Wiederherstellung — aus letztem sauberen Backup, nicht einfach „Plugin deaktivieren"
4. Ursachenanalyse — welches Plugin/Theme/Passwort war die Lücke? Log-Auswertung, Vergleich mit Git-Stand

Wichtig: bei personenbezogenen Daten Meldefrist prüfen. Nicht-Meldung ist meist teurer als die Panne selbst.

Fazit

WordPress-Security ist kein Produkt, sondern ein Prozess. Zwölf Stellschrauben, einmal sauber eingerichtet, blockieren über 95 Prozent der realistischen Angriffe. Der Rest ist Monitoring, Backup und die Bereitschaft, im Ernstfall schnell zu reagieren.

Zwei Dinge machen den Unterschied zwischen „sicher" und „verwundbar": Updates konsequent einspielen und Admin-Zugänge ernst nehmen. Alles andere kommt obendrauf.