WordPress-Sicherheit: Schwachstellen, Härtung und Best Practices

WordPress ist das meistgenutzte Content-Management-System der Welt und betreibt schätzungsweise rund 43 % aller Websites im Internet. Diese enorme Verbreitung macht WordPress gleichzeitig zum attraktivsten Angriffsziel unter allen CMS-Plattformen. Automatisierte Scanner durchsuchen das Netz kontinuierlich nach bekannten WordPress-Schwachstellen, veralteten Plugin-Versionen und schwachen Zugangsdaten. Wer eine WordPress-Installation betreibt - ob als Unternehmenswebsite, Blog oder Onlineshop - muss die spezifischen Sicherheitsrisiken kennen und aktiv gegensteuern.

WordPress-Marktanteil und Sicherheitsrelevanz

Die Beliebtheit von WordPress basiert auf einfacher Bedienbarkeit, einer riesigen Plugin-Bibliothek (über 60.000 Erweiterungen im offiziellen Verzeichnis) und einer aktiven Community. Genau diese Stärken werden jedoch zur Schwäche, sobald Sicherheit vernachlässigt wird.

Kennzahlen (2025): Rund 43 % aller Websites weltweit laufen auf WordPress, bei den Top-1-Million-Sites sind es ca. 34 %. Die WPScan-Datenbank führt über 50.000 bekannte Schwachstellen; täglich kommen 5-10 neue hinzu (Plugins/Themes). Automatisierte Bots scannen permanent nach /wp-login.php, Brute-Force-Angriffe sind der häufigste Angriffsvektor, und Plugin-Schwachstellen verursachen über 90 % aller WordPress-Kompromittierungen.

Besonders kritisch ist der Einsatz in Unternehmen. Eine kompromittierte Firmenwebsite kann nicht nur reputativen Schaden verursachen, sondern als Einfallstor für weitergehende Angriffe auf die interne Infrastruktur dienen - zum Beispiel durch Phishing-Seiten, Drive-by-Downloads oder SEO-Spam, der den Google-Ranking-Verlust beschleunigt.

Häufige Schwachstellen in WordPress-Installationen

Plugins - die größte Angriffsfläche

Über 90 % aller WordPress-Sicherheitsvorfälle gehen auf Schwachstellen in Plugins zurück. Der Grund liegt in der Heterogenität der Plugin-Entwicklerschaft: Jeder kann ein Plugin veröffentlichen, ohne dass ein Sicherheitsaudit stattfindet. Häufige Schwachstellenklassen in Plugins sind:

• Cross-Site Scripting (XSS): Ungefilterte Benutzereingaben landen in der Ausgabe und ermöglichen das Einschleusen von JavaScript-Code.
• SQL-Injection: Datenbankabfragen werden ohne ausreichende Parametrisierung gebaut, sodass Angreifer eigene SQL-Befehle einschleusen können.
• Broken Access Control: Fehlende Berechtigungsprüfungen erlauben es unauthentifizierten Nutzern, auf administrative Funktionen zuzugreifen.
• Datei-Upload-Schwachstellen: Unzureichend validierte Upload-Mechanismen erlauben das Hochladen von PHP-Webshells.

Ein besonderes Risiko entsteht, wenn Plugins den Eigentümer wechseln. Plugins mit hunderttausenden Installationen sind attraktive Kaufziele - ein neuer Entwickler kann Schadcode einschleusen oder sicherheitsrelevante Updates verzögern. Wie der Blogbeitrag zu WordPress-Sicherheitslücken in Firmenwebsites zeigt, ist dieses Szenario kein theoretisches Risiko, sondern wiederholt in der Praxis eingetreten.

Themes

Themes sind mehr als nur visuelle Hüllen. Viele populäre Themes integrieren eigene Framework-Bibliotheken, Page-Builder-Funktionen und Drittanbieter-Scripts - jede dieser Abhängigkeiten ist eine potenzielle Schwachstelle. Besonders gefährlich sind Themes, die ungefiltert Shortcodes oder Widget-Inhalte in PHP evaluieren oder externe JavaScript-Bibliotheken von CDNs nachladen, die nicht unter der eigenen Kontrolle stehen.

WordPress Core

Der WordPress Core selbst gilt als vergleichsweise sicher. Das Entwicklungsteam veröffentlicht regelmäßige Sicherheitsupdates, und die Community meldet Schwachstellen über ein strukturiertes Disclosure-Programm. Dennoch: Wer Core-Updates ignoriert, riskiert bekannte Schwachstellen, für die öffentlich verfügbare Exploits existieren.

Brute Force gegen wp-login.php

Der Standard-Login-Pfad /wp-login.php ist jedem Angreifer bekannt. Automatisierte Bots probieren täglich Millionen von Passwort-Kombinationen - oft mit Credential-Listen aus vorherigen Datenlecks. Ohne Schutzmaßnahmen ist ein schwaches Passwort schnell geknackt.

SQL-Injection und XSS

WordPress nutzt intern die $wpdb-Klasse für Datenbankabfragen. Korrekt eingesetzt mit $wpdb->prepare() ist das sicher - viele Plugin-Entwickler umgehen diese Funktion jedoch, was zu SQL-Injection-Schwachstellen führt. XSS-Schwachstellen entstehen häufig durch unsachgemäßen Einsatz von echo ohne vorherige Sanitierung mit Funktionen wie esc_html(), esc_attr() oder wp_kses().

Härtungsmaßnahmen

Updates konsequent einhalten

Das wichtigste und gleichzeitig am häufigsten vernachlässigte Sicherheitsmerkmal ist aktuell gehaltene Software:

Update-Checkliste: WordPress Core (automatische Minor-Updates aktivieren), Plugins (wöchentlich prüfen, sofort bei Security-Updates), Themes (regelmäßig aktualisieren, inaktive entfernen), PHP-Version (mind. PHP 8.2, EOL-Versionen meiden), MySQL/MariaDB (aktuell halten, nicht als Root betreiben).

Automatische Core-Updates aktivieren in wp-config.php:

define('WP_AUTO_UPDATE_CORE', true);

Nicht genutzte Plugins und Themes sollten nicht nur deaktiviert, sondern vollständig gelöscht werden. Deaktivierte Plugins bleiben auf dem Server und können weiterhin ausgenutzt werden.

Starke Passwörter und Benutzerverwaltung

• Adminkonten mit einem generischen Namen wie admin oder administrator sind ein offensichtliches Angriffsziel. Beim Erstellen der WordPress-Installation sollte ein nicht erratbarer Benutzername gewählt werden.
• Alle Accounts sollten starke, einzigartige Passwörter verwenden (mind. 20 Zeichen, zufällig generiert mit einem Passwort-Manager).
• Das Prinzip der minimalen Rechtevergabe gilt auch für WordPress: Autoren benötigen keine Administrator-Rechte.
• Ungenutzte Benutzerkonten sind regelmäßig zu entfernen.

Zwei-Faktor-Authentifizierung (2FA)

2FA für alle Adminkonten ist ein einfaches, aber hocheffektives Mittel gegen Brute-Force-Angriffe und Credential-Stuffing. Empfohlene Plugins: WP 2FA oder Two Factor Authentication. Alternativ kann 2FA direkt über einen vorgelagerten Reverse Proxy (z. B. Authentik, Authelia) erzwungen werden.

wp-config.php absichern

Die Konfigurationsdatei enthält Datenbankzugangsdaten und Sicherheitsschlüssel - sie gehört besonders geschützt:

// Sicherheitsschlüssel - aus https://api.wordpress.org/secret-key/1.1/salt/ generieren
define('AUTH_KEY',         'einzigartiger-langer-zufalls-string');
define('SECURE_AUTH_KEY',  'einzigartiger-langer-zufalls-string');

// Debug-Modus in Produktion deaktivieren
define('WP_DEBUG', false);
define('WP_DEBUG_LOG', false);
define('WP_DEBUG_DISPLAY', false);

// Datei-Bearbeitung im Admin-Backend deaktivieren
define('DISALLOW_FILE_EDIT', true);

// Plugin- und Theme-Installation einschränken
define('DISALLOW_FILE_MODS', true);

// Datenbankpräfix anpassen (nicht wp_ verwenden)
$table_prefix = 'a7site_';

// wp-config.php außerhalb des Web-Roots legen
// (eine Verzeichnisebene oberhalb von /public_html/)

Die wp-config.php selbst sollte außerhalb des Document-Root liegen oder per .htaccess vor direktem Zugriff geschützt werden:

<Files wp-config.php>
  Order allow,deny
  Deny from all
</Files>

Dateiberechtigungen

Falsch gesetzte Dateiberechtigungen sind ein häufiges Einfallstor. Die empfohlenen Berechtigungen für eine WordPress-Installation unter Linux:

# Verzeichnisse
find /var/www/wordpress -type d -exec chmod 755 {} \;

# Dateien
find /var/www/wordpress -type f -exec chmod 644 {} \;

# wp-config.php besonders restriktiv
chmod 600 /var/www/wordpress/wp-config.php

# Upload-Verzeichnis: kein PHP-Execution
# Über .htaccess in wp-content/uploads/:
# <Files *.php>
#   Deny from all
# </Files>

Der Webserver-Prozess (z. B. www-data) sollte Eigentümer der Dateien sein, aber keine Schreibrechte auf kritische Konfigurationsdateien besitzen.

XML-RPC deaktivieren

Die xmlrpc.php-Schnittstelle ermöglicht Remote-Zugriff auf WordPress und wird häufig für Brute-Force-Angriffe und DDoS-Amplification-Attacken missbraucht. Sofern keine Anwendungen diese Schnittstelle benötigen (z. B. mobile Apps oder Fernpublizierung), sollte sie vollständig deaktiviert werden:

# .htaccess
<Files xmlrpc.php>
  Order Deny,Allow
  Deny from all
</Files>

// Alternativ per Plugin-Hook:
add_filter('xmlrpc_enabled', '__return_false');

Security Plugins

Etablierte Security Plugins wie Wordfence, Sucuri Security oder iThemes Security bieten einen zusätzlichen Schutzlayer:

• Web Application Firewall (WAF) mit Signatur-basierter Filterung
• Login-Schutz (Rate Limiting, IP-Sperrlisten, Lockout nach Fehlversuchen)
• Integritätsprüfung von Core-Dateien
• Malware-Scan des Dateisystems
• Security-Event-Logging

Security Plugins ersetzen keine ordentliche Grundhärtung, sind aber eine sinnvolle Ergänzung.

Webserver-Konfiguration

HTTP-Security-Header

Security-Header sind eine einfach umzusetzende Maßnahme mit hohem Wirkungsgrad. Sie werden im Webserver (Apache, Nginx) oder per Plugin gesetzt:

# Nginx-Beispiel
add_header X-Content-Type-Options    "nosniff" always;
add_header X-Frame-Options           "SAMEORIGIN" always;
add_header X-XSS-Protection          "1; mode=block" always;
add_header Referrer-Policy           "strict-origin-when-cross-origin" always;
add_header Permissions-Policy        "camera=(), microphone=(), geolocation=()" always;
add_header Content-Security-Policy   "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; font-src 'self';" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

Der Content-Security-Policy-Header ist besonders wirksam gegen XSS-Angriffe - erfordert aber sorgfältige Konfiguration, da zu restriktive Einstellungen die Seite funktional beeinträchtigen können.

TLS-Konfiguration

Moderne TLS-Konfiguration ist Pflicht:

• Ausschließlich TLS 1.2 und TLS 1.3 erlauben (TLS 1.0 und 1.1 abschalten)
• Starke Cipher Suites verwenden (AEAD-Cipher priorisieren)
• HTTP Strict Transport Security (HSTS) mit langer max-age aktivieren
• HTTP-Anfragen automatisch auf HTTPS umleiten
• Let's Encrypt für kostenlose, automatisch erneuerte Zertifikate nutzen

Das Mozilla SSL Configuration Generator (ssl-config.mozilla.org) liefert produktionsreife Webserver-Konfigurationen für alle gängigen Server.

Verzeichnis-Browsing und Versionsinformationen verstecken

# Apache: Verzeichnis-Listing deaktivieren
Options -Indexes

# WordPress-Version aus HTML-Quelltext entfernen
remove_action('wp_head', 'wp_generator');

# Nginx: Serverversion verstecken
server_tokens off;

Backup-Strategie

Ein funktionierendes Backup ist die wichtigste Recovery-Maßnahme nach einem Sicherheitsvorfall. Für WordPress bedeutet das:

Ein vollständiges Backup umfasst: Datenbankdump (wp_*-Tabellen via mysqldump oder Plugin), wp-content/uploads/ (Medienbibliothek), wp-content/themes/ (aktives Theme + Anpassungen), wp-content/plugins/ (alternativ frisch installieren) und wp-config.php (Konfiguration).

Backup-Strategie nach der 3-2-1-Regel: 3 Kopien der Daten auf 2 verschiedenen Medien/Speicherorten, davon 1 Kopie geografisch getrennt (off-site). Frequenz: Datenbankbackup täglich, Voll-Backup wöchentlich, Aufbewahrung 30 Tage rolling plus monatliche Snapshots für ein Jahr.

Empfohlene Backup-Plugins: UpdraftPlus, BackWPup, Duplicator. Externe Speicherziele: S3, Backblaze B2, SFTP auf separatem Server.

Backups müssen regelmäßig auf Wiederherstellbarkeit getestet werden. Ein Backup, das im Notfall nicht funktioniert, ist wertlos.

Monitoring und Incident Response

Was überwacht werden sollte

• Login-Versuche: Fehlgeschlagene Login-Versuche, ungewöhnliche IP-Adressen
• Dateiänderungen: Änderungen an Core-Dateien, Themes und Plugins
• Neue Benutzerkonten: Unerwartete Admin-Accounts sind ein starkes Kompromittierungssignal
• Ausgehender Traffic: Ungewöhnliche ausgehende Verbindungen vom Webserver
• HTTP-Access-Logs: Massenhafte Scans gegen wp-login.php, xmlrpc.php, bekannte Plugin-Pfade
• Datenbankabfragen: Anomalien im Query-Log können auf SQL-Injection hindeuten

Anzeichen einer Kompromittierung

Typische Indikatoren für eine kompromittierte WordPress-Installation:

• Unbekannte PHP-Dateien in wp-content/uploads/ (Webshells)
• Neue Admin-Benutzer mit unbekannten E-Mail-Adressen
• Weiterleitungen auf externe (Spam-)Domains
• Google Search Console meldet Malware oder Deceptive Content
• Hoster sperrt Account wegen Spam-Versand
• Ungewöhnliche Cronjobs in der Datenbank (wp_cron)
• Base64-kodierter Code in wp-config.php oder functions.php

Incident Response - erste Schritte

1. Website sofort in den Wartungsmodus versetzen oder vom Netz nehmen
2. Hosting-Provider informieren und auf Malware-Scan warten
3. Alle Passwörter zurücksetzen (WordPress, FTP, Datenbank, Hoster-Panel)
4. Alle Admin-Accounts und aktiven Sessions löschen
5. Sauberes Backup einspielen (vor dem Infektionszeitpunkt)
6. WordPress Core, alle Plugins und Themes frisch installieren
7. wp-config.php neu generieren (neue Sicherheitsschlüssel)
8. Ursache analysieren: welches Plugin / welche Schwachstelle war das Einfallstor?
9. Sicherheitslücke schließen, bevor die Site wieder online geht

WordPress-Alternativen: ein kurzer Ausblick

Wer sich die Komplexität einer WordPress-Härtung ersparen möchte, sollte alternative Architekturen erwägen:

Headless CMS

Ein Headless CMS (z. B. Strapi, Contentful, Sanity, Directus) trennt die Content-Verwaltung vom Frontend vollständig. Die Administratoroberfläche ist nicht öffentlich zugänglich, und das Frontend ist eine eigenständige Applikation ohne direkte CMS-Exposition. Angriffsfläche und Betriebsaufwand reduzieren sich erheblich.

Static Site Generators

Static Site Generators (SSG) wie Astro, Hugo, Eleventy oder Next.js exportieren Websites als reine HTML/CSS/JS-Dateien ohne serverseitige Laufzeitkomponenten. Es gibt keine Datenbank, kein Login-Formular und keinen dynamischen Code, der ausgenutzt werden könnte. Sicherheitsrisiken durch CMS-Schwachstellen entfallen damit vollständig - der Kompromiss ist eine geringere redaktionelle Flexibilität im Vergleich zu vollwertigen CMS-Plattformen.

Die Entscheidung für oder gegen WordPress sollte immer im Kontext der verfügbaren Ressourcen für laufende Wartung und Sicherheit getroffen werden. Eine schlecht gewartete WordPress-Installation ist ein erhebliches Sicherheitsrisiko - eine regelmäßig gepflegte, korrekt gehärtete Installation kann aber sicher betrieben werden.