WordPress unter Beschuss: Die sechs häufigsten Angriffsarten – und wie Sie sie wirklich abwehren

Von /

Ein Vertiefungsbeitrag für Webdesigner, die ihre KMU-Kunden jenseits von Plugin-Klicks schützen wollen.

In unserem Grundlagenbeitrag zur WordPress-Absicherung haben wir gezeigt, wie Sie mit Cloudflare und Wordfence in 30 Minuten ein solides Sicherheitsfundament legen. Das reicht für die meisten KMU-Websites aus – aber es beantwortet eine Frage nicht: Wovor genau schützen diese Werkzeuge eigentlich?

Dieser Beitrag geht einen Schritt tiefer. Er richtet sich an Webdesigner, die ihre Kunden nicht nur beraten, sondern verstehen wollen, warum bestimmte Maßnahmen wirken und wo die Grenzen fertiger Plugins liegen. Denn wer die Angriffsarten kennt, erkennt auch, welche Verteidigung gegen welche Bedrohung hilft – und welche bewusste Lücken im Schutzschild bleiben.

Warum überhaupt Schutzschichten?

Ein Grundprinzip der IT-Sicherheit lautet Defense in Depth – „Verteidigung in der Tiefe“. Die Idee: Verlassen Sie sich nie auf eine einzige Schutzmaßnahme. Wenn ein Angreifer eine Hürde überwindet, soll die nächste bereits wartet. Wordfence allein ist besser als nichts, Cloudflare allein ist besser als nichts – aber beide zusammen plus serverseitige Härtung plus saubere Konfiguration ist deutlich mehr als die Summe ihrer Teile.

Warum das wichtig ist, zeigt ein einfaches Gedankenexperiment: Was passiert, wenn Wordfence durch ein fehlerhaftes Update ausfällt? Oder wenn ein anderer Plugin-Konflikt es deaktiviert? Ohne zusätzliche Schichten fällt dann der gesamte Schutz weg. Mit Schichten bleibt mindestens ein Teil des Schutzes bestehen.

Gehen wir die wichtigsten Angriffsarten durch.

1. Brute-Force-Angriffe auf den Login

Was passiert da?

Bots rufen Ihre Login-Seite (/wp-login.php) auf und probieren stumpf Benutzername/Passwort-Kombinationen durch – oft tausende pro Stunde. In den allermeisten Fällen raten sie auf den Benutzernamen admin, weil das bis WordPress 3.0 der Standardwert bei der Installation war und auf unzähligen älteren Seiten immer noch existiert.

Warum das funktioniert

WordPress verrät von sich aus, ob ein Benutzername existiert. Der Grund: Bei falschem Benutzernamen zeigt das Login „Unbekannter Benutzername“, bei richtigem Benutzernamen und falschem Passwort zeigt es „Passwort falsch“. Ein Bot weiß also sofort, wann er beim Namen richtig liegt und nur noch das Passwort erraten muss.

Typische Gegenmaßnahmen

  • Rate Limiting: Wordfence und auch Plugins wie Limit Login Attempts Reloaded sperren IP-Adressen nach wenigen Fehlversuchen aus.
  • Zwei-Faktor-Authentifizierung (2FA): Das wirksamste Einzelmittel. Selbst ein erratenes Passwort nützt nichts ohne den zweiten Faktor.
  • Starke Passwörter: Mindestens 16 Zeichen, kein Wörterbuchwort. Ein Passwortmanager ist für Ihre Kunden Pflicht, kein Komfort.
  • Kein Benutzer namens admin: Klingt banal, reduziert aber das Log-Rauschen massiv. Der Angriff wird dadurch nicht unmöglich, aber die dummen Bots laufen ins Leere. Gezielte Angreifer finden den echten Namen trotzdem – dazu gleich mehr.
  • Login-URL verstecken: Plugins wie WPS Hide Login verschieben /wp-login.php auf eine andere Adresse. Das ist reine „Security by Obscurity“ – kein echter Schutz, aber ein wirksamer Bot-Filter.

Was oft übersehen wird

Brute-Force läuft nicht nur über /wp-login.php, sondern auch über die XML-RPC-Schnittstelle (/xmlrpc.php). Diese alte Schnittstelle erlaubt Login-Versuche im Bulk – ein einziger Request kann hunderte Passwörter testen. Wenn Ihre Kunden keine externen Dienste nutzen, die XML-RPC brauchen (Jetpack, mobile Apps, Pingbacks), sollten Sie die Schnittstelle komplett deaktivieren:

// In functions.php oder als Must-Use-Plugin
add_filter('xmlrpc_enabled', '__return_false');

Oder sauberer auf Webserver-Ebene via .htaccess:

<Files "xmlrpc.php">
    Require all denied
</Files>

2. Benutzernamen-Enumeration

Was passiert da?

Bevor ein Angreifer Passwörter rät, will er den Benutzernamen kennen. WordPress bietet dafür gleich mehrere Wege, die alle öffentlich zugänglich sind – außer Sie stopfen sie aktiv zu:

  • https://ihre-seite.de/?author=1 leitet standardmäßig auf /author/username/ um und verrät so den Login-Namen.
  • https://ihre-seite.de/wp-json/wp/v2/users listet per JSON-Antwort alle Benutzer mit veröffentlichten Beiträgen auf.
  • https://ihre-seite.de/wp-sitemap-users-1.xml ist die Core-Sitemap seit WordPress 5.5 und enthält ebenfalls alle Autoren.
  • Im HTML-Quelltext von Blogposts tauchen Benutzernamen in CSS-Klassen wie body class="... author-soenke ..." auf.

Warum das Problem unterschätzt wird

Viele Webdesigner denken: „Wordfence blockiert das doch.“ Stimmt teilweise – im aktiven Betrieb. Aber sobald das Plugin deaktiviert, neu installiert oder durch einen Konflikt lahmgelegt ist, liegen die Daten sofort wieder offen. Ein Single Point of Failure.

Typische Gegenmaßnahmen

Der saubere Weg ist, die Enumeration auf mehreren Ebenen zu blockieren – am besten per Must-Use-Plugin, das im Ordner wp-content/mu-plugins/ liegt und sich nicht über die Admin-Oberfläche deaktivieren lässt:

<?php
/**
 * Plugin Name: Disable User Enumeration
 * Description: Blockt Author-Archive, REST-Users-Endpoint und Sitemap-Users.
 */

// REST-API: /wp/v2/users komplett sperren
add_filter('rest_endpoints', function ($endpoints) {
    if (isset($endpoints['/wp/v2/users'])) {
        unset($endpoints['/wp/v2/users']);
    }
    if (isset($endpoints['/wp/v2/users/(?P<id>[\d]+)'])) {
        unset($endpoints['/wp/v2/users/(?P<id>[\d]+)']);
    }
    return $endpoints;
});

// ?author=N blockieren
add_action('template_redirect', function () {
    if (is_author() || !empty($_GET['author'])) {
        wp_safe_redirect(home_url(), 301);
        exit;
    }
});

// User aus Core-Sitemap entfernen
add_filter('wp_sitemaps_add_provider', function ($provider, $name) {
    return ($name === 'users') ? false : $provider;
}, 10, 2);

Zusätzlich lohnt ein Blick in die Datenbanktabelle wp_users. WordPress generiert den user_nicename (den öffentlichen Slug) standardmäßig aus dem user_login – beide sind also meist identisch. Wenn Sie den user_nicename auf einen anderen Wert setzen, verrät auch das HTML nicht mehr den echten Login-Namen. Das geht nur direkt per SQL, nicht über die Admin-Oberfläche:

UPDATE wp_users 
SET user_nicename = 'autor-anzeige' 
WHERE user_login = 'geheimer-loginname';

Wichtig: Vorher ein Backup anlegen, und danach einmal den Cache leeren. Und: Der user_login selbst bleibt unverändert – den sollte niemand ändern, er ist Primärreferenz in zu vielen Stellen der Datenbank.

3. Ausnutzung veralteter Plugins und Themes

Was passiert da?

Das mit Abstand häufigste Einfallstor in WordPress-Installationen sind nicht WordPress selbst, sondern Drittanbieter-Plugins. Sicherheitsforscher finden regelmäßig Schwachstellen in populären Plugins – manche davon kritisch. Sobald eine Schwachstelle veröffentlicht ist, scannen Bots innerhalb weniger Stunden das gesamte Internet nach Installationen, die den Patch noch nicht eingespielt haben.

Typische Angriffsmuster

  • SQL Injection: Ein Plugin verarbeitet Benutzereingaben unzureichend und erlaubt Angreifern, eigene SQL-Statements in Datenbankabfragen einzuschleusen. Ergebnis: Auslesen der Benutzerdatenbank inklusive Passwort-Hashes.
  • Remote Code Execution (RCE): Besonders gefährlich. Der Angreifer kann PHP-Code ausführen und damit faktisch die Kontrolle über den Server übernehmen.
  • Arbitrary File Upload: Ein Upload-Formular prüft den Dateityp nicht richtig – der Angreifer lädt statt eines Bildes eine PHP-Datei hoch und ruft sie anschließend direkt auf.
  • Privilege Escalation: Ein angemeldeter Benutzer mit eingeschränkten Rechten kann sich selbst Admin-Rechte zuweisen.

Typische Gegenmaßnahmen

  • Automatische Updates für Core, Plugins und Themes aktivieren. In der wp-config.php: define('WP_AUTO_UPDATE_CORE', true); Für Plugins funktioniert das seit WordPress 5.5 direkt in der Admin-Oberfläche.
  • Minimale Plugin-Landschaft: Jedes Plugin ist eine potenzielle Angriffsfläche. Faustregel: Weniger als 20 aktive Plugins, alle aktiv gepflegt, keine Karteileichen. Ein Plugin, dessen letztes Update zwei Jahre zurückliegt, ist keine Option – auch wenn es noch funktioniert.
  • Theme-Herkunft prüfen: „Nulled Themes“ aus dubiosen Quellen enthalten praktisch immer Backdoors. Nur Themes aus dem offiziellen Repository oder von etablierten Anbietern.
  • Vulnerability-Monitoring: Wordfence meldet bekannte Schwachstellen in installierten Plugins. Für größere Umgebungen lohnt ein Blick auf patchstack.com oder wpscan.com, die Sicherheitsdatenbanken zu WordPress-Plugins pflegen.

4. Suche nach falsch abgelegten Konfigurationsdateien

Was passiert da?

Bots scannen systematisch nach Dateien, die nicht öffentlich sein sollten, es aber versehentlich sind. Typische Ziele:

  • .env, .env.production, .env.backup
  • wp-config.php.bak, wp-config.old, wp-config.php~
  • database.sql, backup.sql, dump.sql
  • .git/config, .git/HEAD (ganze Git-Repos im Webroot!)
  • /phpinfo.php, /info.php, /test.php

Das klingt absurd, passiert aber ständig: Ein Entwickler legt schnell eine Sicherheitskopie der wp-config.php an, nennt sie wp-config.php.bak – und weil diese Endung vom Webserver nicht als PHP interpretiert wird, liefert der Server die Datei im Klartext aus. Inklusive Datenbank-Zugangsdaten.

Typische Gegenmaßnahmen

Erste Regel: Keine Backups im Webroot. Nie. Für echte Backups siehe Punkt 6.

Zweite Regel: Gefährliche Endungen per Webserver-Konfiguration sperren. In der .htaccess:

# Versteckte Dateien blockieren (.env, .git etc.)
<FilesMatch "^\.">
    Require all denied
</FilesMatch>

# Backup-Endungen blockieren
<FilesMatch "\.(bak|old|backup|sql|swp|~)$">
    Require all denied
</FilesMatch>

# wp-config.php zusätzlich explizit schützen
<Files "wp-config.php">
    Require all denied
</Files>

Dritte Regel: /phpinfo.php-Dateien niemals auf Live-Systemen vergessen. Sie verraten PHP-Version, geladene Module, Pfade und oft auch Datenbank-Informationen – ein Eldorado für Angreifer.

5. SQL Injection und Cross-Site-Scripting (XSS)

Diese beiden Klassiker betreffen seltener WordPress-Core (der ist gut geprüft), sondern fast immer Plugins mit eigener Datenbankkommunikation oder Formularverarbeitung.

SQL Injection versucht, eigene Datenbankbefehle in Parameter einzuschleusen. Ein Beispiel: Ein Plugin erzeugt eine URL wie /?produkt=42 und verwendet den Parameter unbehandelt in einer SQL-Abfrage. Der Angreifer ersetzt den Wert durch 42 UNION SELECT user_login, user_pass FROM wp_users – und bekommt die Zugangsdaten zurückgeliefert.

Cross-Site-Scripting (XSS) schleust JavaScript-Code in die Ausgabe Ihrer Website. Typisches Ziel: Ein Kommentarfeld, das Eingaben nicht ordentlich maskiert. Der eingeschleuste Code läuft dann im Browser anderer Besucher – zum Beispiel um Session-Cookies zu stehlen oder Besucher auf Phishing-Seiten umzuleiten.

Typische Gegenmaßnahmen

Als Webdesigner haben Sie hier drei Hebel:

  • Web Application Firewall (WAF): Sowohl Wordfence als auch Cloudflare erkennen typische SQL-Injection- und XSS-Muster und blockieren sie. Die Cloudflare-WAF in der Free-Version ist rudimentär, in den bezahlten Tarifen deutlich besser.
  • Plugin-Hygiene (siehe Punkt 3). Die meisten Lücken stecken in schlecht gepflegten Plugins.
  • Content Security Policy (CSP): Ein HTTP-Header, der dem Browser vorschreibt, von welchen Quellen er Skripte laden darf. Macht XSS deutlich schwerer auszunutzen. Einrichtung per .htaccess:
Header set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' data:;"

Achtung: CSP kann Themes und Plugins brechen, die externe Skripte laden (Google Fonts, Analytics, Einbettungen). Schrittweise einführen, zuerst im Report-Only-Modus testen. Für Kunden, die externe Dienste nutzen, ist das ein echtes Projekt – kein Copy&Paste.

6. Komplettübernahme und was dann passiert

Was passiert da?

Hat ein Angreifer es geschafft, reicht meistens ein Admin-Zugang oder eine RCE-Lücke – und die Website gehört ihm. Was dann üblicherweise passiert:

  • Spam-Versand: Der kompromittierte Server verschickt tausende Spam-Mails, bis die Server-IP auf Blacklisten landet und der Hoster die Seite sperrt.
  • Crypto-Mining: Im Hintergrund läuft ein Miner und verbraucht CPU-Ressourcen. Fällt oft erst durch explodierende Hoster-Rechnungen auf.
  • Phishing-Hosting: Auf Unterseiten der Kunden-Website werden Phishing-Kopien bekannter Marken (Sparkasse, DHL, Microsoft) abgelegt. Die Besucher-Website funktioniert scheinbar normal, aber /dhl-sendung/ zeigt eine gefälschte DHL-Seite.
  • SEO-Spam: Der Angreifer injiziert Links zu fragwürdigen Zielseiten (Viagra, Casino, gefälschte Markenartikel) in den WordPress-Inhalt. Oft nur sichtbar, wenn der Besucher über Google kommt – in der Admin-Ansicht bleibt alles normal.
  • Botnetz-Teilnahme: Der Server wird in ein Netz kompromittierter Maschinen eingereiht und für Angriffe auf andere Ziele missbraucht.

Warum das für den Kunden teuer wird

Abgesehen vom direkten Schaden drohen rechtliche Folgen: DSGVO-Meldepflicht bei Datenabfluss, Haftung für von der eigenen Seite ausgehende Angriffe, Reputationsverlust bei Google („Diese Seite kann Ihren Computer schädigen“). Das kann einen KMU-Kunden tatsächlich existenziell treffen.

Die einzige echte Absicherung: saubere Backups

Alle anderen Maßnahmen reduzieren die Wahrscheinlichkeit eines Einbruchs. Nur Backups sorgen dafür, dass ein erfolgreicher Einbruch nicht das Ende bedeutet. Drei Regeln:

  1. Automatisch. Backups, die man manuell starten muss, werden vergessen.
  2. Extern. Ein Backup auf demselben Server ist kein Backup – wird der Server kompromittiert, ist auch das Backup kompromittiert. Sinnvolle Ziele: externer Cloud-Speicher, Hetzner Storage Box, separater Server.
  3. Geprüft. Ein Backup, das Sie noch nie zurückgespielt haben, ist keines. Mindestens einmal im Jahr einen Restore auf einem Test-System durchspielen.

Bewährte Plugins für automatisierte, externe Backups: UpdraftPlus, BackWPup, Duplicator Pro. Für Kunden mit höheren Anforderungen lohnt sich ein Blick auf BlogVault oder Managed-WordPress-Hoster, die Backups bereits auf Infrastrukturebene mitliefern.

Die Prioritätenliste für Ihre Kunden

Wenn Sie aus diesem Beitrag nur eine Reihenfolge mitnehmen, dann diese:

  1. Starke Passwörter + 2FA für alle Admin-Accounts – das wirkt gegen den häufigsten Angriff.
  2. Automatische Updates für Core und Plugins – das schließt das häufigste Einfallstor.
  3. Externe, automatische, getestete Backups – das ist Ihre Rückversicherung, wenn trotzdem etwas passiert.
  4. Cloudflare + Wordfence einrichten (siehe Grundlagenbeitrag) – das filtert den Großteil der automatisierten Angriffe.
  5. Minimale Plugin-Landschaft und konsequente Plugin-Hygiene – das reduziert die Angriffsfläche.
  6. Härtung per .htaccess und Must-Use-Plugin – das macht Sie unabhängig von Plugin-Verfügbarkeit.
  7. XML-RPC und User-Enumeration gezielt abschalten – das eliminiert zwei oft übersehene Vektoren.

Die Punkte 1–3 sind Pflicht. Punkte 4–5 sind Standard. Punkte 6–7 sind das, was professionelle Webdesign-Betreuung von einem halbherzigen „Wir haben da ein Plugin installiert“ unterscheidet.

Fazit

WordPress ist nicht unsicher – WordPress ist beliebt. Und weil es beliebt ist, ist es das Lieblingsziel automatisierter Angriffe. Wer die Angriffsarten kennt, kann gezielt dagegen arbeiten: Brute-Force mit Rate Limiting und 2FA, Enumeration mit gezielten Filtern, Plugin-Lücken mit Updates und Hygiene, Konfigurations-Leaks mit Webserver-Regeln, Injection-Angriffe mit WAF und Plugin-Auswahl, den Worst Case mit Backups.

Kein einzelnes Werkzeug deckt all das ab. Aber die Kombination aus Cloudflare, Wordfence, serverseitiger Härtung, sauberer Konfiguration und externen Backups bringt eine WordPress-Website auf ein Sicherheitsniveau, das für 99% der KMU-Szenarien mehr als ausreichend ist – und das ganz ohne laufende Software-Lizenzen.

Sie betreuen WordPress-Websites für KMU und möchten Ihre Betreuungsleistung um eine fundierte Sicherheitsebene erweitern? Oder brauchen Unterstützung bei der Härtung eines konkreten Kundenprojekts? Sprechen Sie uns an.

Ähnliche Beiträge

Nach oben scrollen