WordPress 2026 härten — die Checkliste, die wir auf Kundensites tatsächlich anwenden
19. Mai 2026 · 1 Min. Lesezeit · von Sudhanshu K.
Die meisten „Top 50 WordPress-Sicherheitstipps"-Artikel sind Rauschen. Sie listen „nutze ein starkes Passwort" neben echten Kontrollen auf, und der Leser hat keine Möglichkeit zu unterscheiden, was wichtig ist.
Dies ist die Checkliste, die wir auf jeder neuen WordPress-Site anwenden, die in das Managed Hosting kommt. Jeder Punkt ist hier, weil wir den verhinderten Angriff in den letzten 18 Monaten bei einem echten Kunden gesehen haben. Wenden Sie die Kontrollen dieser Liste an, und Sie wehren rund 95 % dessen ab, was an WordPress-Origins ankommt.
Der wp-config-Hardening-Pass
define('DISALLOW_FILE_EDIT', true);
define('DISALLOW_FILE_MODS', true);
define('WP_AUTO_UPDATE_CORE', 'minor');
define('FORCE_SSL_ADMIN', true);
define('WP_DEBUG', false);Die beiden wirksamsten Kontrollen: DISALLOW_FILE_EDIT entfernt den Theme-/Plugin-Editor im Dashboard, sodass ein kompromittierter Admin keine Webshell über die UI ablegen kann. DISALLOW_FILE_MODS blockiert Plugin-/Theme-Installationen komplett — das Richtige für Sites, deren Deployments über CI laufen.
Der vollständige Beitrag behandelt:
- Dateisystem-Berechtigungen und der
noexec-Mount aufwp-content/uploads, der die meisten Webshells neutralisiert - Deaktivieren von XML-RPC (oder Rate-Limiting) — der
system.multicall-Brute-Force-Verstärker - REST-API-Endpunkte, die Benutzernamen verraten, und wie man sie sauber blockiert
- Fail2ban-Jails, die fehlgeschlagene
wp-login.php-POSTs tatsächlich zählen - 2FA-Pflicht (mindestens TOTP, WebAuthn für kleine Teams)
- AIDE/Tripwire File-Integrity-Monitoring als Auffangnetz nach einer Kompromittierung
- Plugin- und Theme-Allowlisting — das Problem mit verwaisten Plugins
Wir liefern dieses Baseline auf jeder gemanagten WordPress-Installation aus.
Vollständiger Artikel verfügbar
Vollständigen Artikel lesen