Die Kernaussage: Die überwältigende Mehrheit der WordPress-Hacks lässt sich auf eine kleine Anzahl gut verstandener Schwachstellen zurückführen — veraltete Plugins und Themes, schwache Admin-Zugangsdaten, SQL-Injection in verwundbarem Code, Cross-Site-Scripting und offenliegende XML-RPC-Endpunkte — jede mit einer spezifischen, bekannten Lösung statt einer vagen "Sicherheit verbessern"-Empfehlung.
Warum WordPress ein so häufiges Ziel ist
WordPress betreibt einen großen Anteil aller Websites — W3Techs verfolgt seit mehreren Jahren durchgängig einen Anteil von über 40% des gesamten Webs. Genau diese Größenordnung macht es zum Ziel: Eine einzelne, in einem populären Plugin entdeckte Schwachstelle kann potenziell auf Zehntausenden von Sites ausgenutzt werden, die noch die verwundbare Version verwenden, was automatisierte Massen-Scan-Angriffe für einen Angreifer lohnender macht, als es eine individuell gebaute Site je rechtfertigen würde.
Das ist wichtiger Kontext, weil es das Problem korrekt neu einordnet: Der WordPress-Kern selbst ist bei den meisten Angriffen nicht der schwache Punkt. Das umgebende Plugin- und Theme-Ökosystem ist es, zusammen mit grundlegenden Konfigurationsentscheidungen, die vollständig in der Kontrolle des Site-Betreibers liegen.
Veraltete Plugins und Themes
Sicherheitsforschung findet durchgängig, dass veraltete Plugins und Themes mit öffentlich bekannten Schwachstellen der mit Abstand größte Angriffsvektor für WordPress-Kompromittierungen sind — weit vor Kern-Schwachstellen oder gezielten, individuellen Angriffen. Sobald eine Schwachstelle öffentlich bekannt gemacht wird (selbst wenn bereits ein Patch veröffentlicht wurde), beginnen automatisierte Scanner innerhalb von Stunden, das Web nach Sites zu durchsuchen, die noch die verwundbare Version ausführen.
Die Lösung ist unkompliziert, erfordert aber Disziplin: Aktiviere automatische Updates für Plugins und Themes, wo möglich, entferne jedes Plugin, das nicht mehr aktiv gepflegt wird (prüfe das "zuletzt aktualisiert"-Datum im WordPress-Plugin-Verzeichnis), und prüfe die Schwachstellenhistorie neuer Plugins vor der Installation über eine Datenbank wie die WPScan-Schwachstellendatenbank.
Schwache oder wiederverwendete Admin-Zugangsdaten
Brute-Force-Login-Versuche gegen wp-login.php sind ständiges Hintergrundrauschen im Web — automatisierte Bots probieren gängige Benutzername-/Passwort-Kombinationen gegen jede WordPress-Site aus, die sie finden, und ein schwaches oder wiederverwendetes Passwort verwandelt dieses Hintergrundrauschen in eine echte Kompromittierung.
Die Lösung: Erzwinge starke, eindeutige Passwörter für jedes Admin-Konto, aktiviere Zwei-Faktor-Authentifizierung, benenne den standardmäßigen "admin"-Benutzernamen um oder beschränke den Zugriff darauf, falls er noch verwendet wird, und begrenze Login-Versuche, um automatisierte Brute-Force-Tools zu verlangsamen.
SQL-Injection in verwundbaren Plugins
SQL-Injection erlaubt es einem Angreifer, eine Datenbankabfrage über das eigene Eingabefeld eines Plugins zu manipulieren — ein Kontaktformular, ein Suchfeld, einen URL-Parameter —, das nicht ordnungsgemäß bereinigt, was eingegeben wird, wodurch potenziell die gesamte WordPress-Datenbank einschließlich Benutzeranmeldedaten offengelegt oder verändert werden kann.
Die Lösung entspricht größtenteils der für veraltete Plugins: SQL-Injection-Schwachstellen finden sich fast immer in bestimmten Plugin-Versionen und werden nach Meldung schnell gepatcht, sodass aktuelle Updates die große Mehrheit dieser Lücken schließen, bevor sie auf einer bestimmten Site überhaupt ausgenutzt werden.
Cross-Site-Scripting (XSS)
XSS erlaubt es einem Angreifer, über ein unbereinigtes Eingabefeld schädliches JavaScript in eine Seite einzuschleusen, das dann im Browser jedes Besuchers dieser Seite läuft — wodurch potenziell Admin-Sitzungs-Cookies gestohlen oder Besucher auf eine schädliche Site umgeleitet werden. Kommentarfelder, Kontaktformulare und Plugin-Einstellungen, die Benutzereingaben nicht escapen, sind die häufigsten Eintrittspunkte.
Die Lösung: Dieselbe Update-Disziplin gilt, da XSS-Schwachstellen typischerweise plugin-spezifisch sind und schnell gepatcht werden; eine Web Application Firewall (in vielen Sicherheits-Plugins enthalten) fügt eine Schicht hinzu, die bekannte XSS-Injektionsmuster blockieren kann, noch bevor ein Patch angewendet wird.
XML-RPC-Missbrauch
WordPress' XML-RPC-Schnittstelle, ursprünglich für Remote-Publishing-Tools gebaut, ist zu einem häufigen Vektor für zwei spezifische Angriffe geworden: Brute-Force-Login-Versuche, die über die Pingback-Methode umgeleitet werden, um normale Ratenbegrenzung zu umgehen, und die Nutzung des XML-RPC-Endpunkts einer Site als Verstärker bei DDoS-Angriffen gegen andere Ziele.
Die Lösung: Deaktiviere XML-RPC vollständig, es sei denn, die Site ist aktiv auf ein Plugin (meist Jetpack) oder eine App angewiesen, die es benötigt — für die meisten Sites schließt dies eine Angriffsfläche ohne funktionalen Nachteil.
Unsichere Dateiberechtigungen
Übermäßig freizügige Datei- und Ordnerberechtigungen — oft auf ihren Standardwerten belassen oder während der Fehlerbehebung gelockert und nie zurückgesetzt — erlauben es einem Angreifer, der irgendeinen Zugriffspunkt auf dem Server erlangt, Kerndateien zu ändern, eine Hintertür zu platzieren oder sensible Konfigurationsdaten wie Datenbank-Zugangsdaten in wp-config.php zu lesen.
Die Lösung: WordPress' eigene Dokumentation empfiehlt 644 für Dateien und 755 für Verzeichnisse als sichere Basis, wobei wp-config.php idealerweise noch stärker abgesichert werden sollte, da sie Datenbank-Zugangsdaten direkt enthält.
Schnellreferenztabelle
| Schwachstelle | Häufiger Eintrittspunkt | Primäre Lösung |
|---|---|---|
| Veraltete Plugins/Themes | Bekannte, offengelegte CVEs | Auto-Updates aktivieren, ungepflegte Plugins entfernen |
| Schwache Admin-Zugangsdaten | wp-login.php-Brute-Force | Starke Passwörter, 2FA, Login-Versuchsbegrenzung |
| SQL-Injection | Unbereinigte Plugin-Eingabefelder | Plugins auf gepatchte Versionen aktuell halten |
| Cross-Site-Scripting (XSS) | Kommentar-/Kontaktformularfelder | Plugins aktualisieren, Web Application Firewall nutzen |
| XML-RPC-Missbrauch | Pingback-Brute-Force, DDoS-Relay | XML-RPC deaktivieren, falls nicht aktiv benötigt |
| Unsichere Dateiberechtigungen | Serverseitige Fehlkonfiguration | 644 für Dateien, 755 für Verzeichnisse |
Eine praktische Härtungs-Checkliste
- Alles nach einem Zeitplan aktualisieren, nicht reaktiv — WordPress-Kern, jedes Plugin und das aktive Theme, idealerweise mit aktivierten automatischen Updates für kleinere Releases.
- Ungenutzte Plugins und Themes vollständig entfernen, nicht nur deaktivieren — ein inaktives, aber installiertes Plugin mit bekannter Schwachstelle kann in manchen Angriffsketten immer noch ausgenutzt werden.
- Zwei-Faktor-Authentifizierung für jedes Konto mit Veröffentlichungs- oder Admin-Zugriff erzwingen, nicht nur für das primäre Admin-Konto.
- XML-RPC deaktivieren, es sei denn, eine spezifische, aktiv genutzte Integration benötigt es.
- Sicherheitsänderungen zuerst auf einer Staging-Kopie testen, da Härtungsschritte wie Berechtigungsänderungen oder das Deaktivieren von Funktionen gelegentlich ein davon abhängiges Plugin brechen können.
Über neue Schwachstellen informiert bleiben
Schwachstellendatenbanken wie WPScan und Patchstack verfolgen neu offengelegte WordPress-Plugin- und Theme-Schwachstellen, sobald sie veröffentlicht werden, und viele Sicherheits-Plugins beziehen Daten aus denselben Quellen, um Site-Betreiber zu alarmieren, wenn ein installiertes Plugin ein bekanntes Problem hat. Einen dieser Feeds zu abonnieren, statt ein Problem im Nachhinein zu bemerken, ist der Unterschied zwischen Patchen innerhalb von Stunden nach Offenlegung und Patchen, nachdem ein automatisierter Scanner die Lücke bereits gefunden hat.
Häufige Fehler, die zu einer Kompromittierung führen
- Annehmen, ein Sicherheits-Plugin allein sei ausreichend, obwohl es eine bekannte Schwachstelle in veralteter, noch auf der Site laufender Software nicht rückwirkend patchen kann.
- Ungenutzte Plugins deaktivieren statt löschen, wodurch bekannt verwundbarer Code auf dem Server verbleibt, selbst wenn er nicht aktiv läuft.
- Dasselbe Admin-Passwort über mehrere Kundensites hinweg wiederverwenden, wodurch ein einziges geleaktes Zugangsdatum zu einer Multi-Site-Kompromittierung wird.
- Härtung der Dateiberechtigungen ignorieren, weil es als einmalige Einrichtungsaufgabe statt als wiederkehrender Wartungspunkt betrachtet wird.
- Aus einem alten Backup wiederherstellen, ohne zu prüfen, ob es auch eine seither gepatchte Schwachstelle wiederherstellt, wodurch eine frühere Korrektur unbemerkt rückgängig gemacht wird.
Zusammenfassung
Kurz gesagt: Die Schwachstellen, die WordPress-Sites tatsächlich kompromittieren, sind eine gut dokumentierte, vorhersehbare Gruppe — vor allem veraltete Plugins und Themes, dazu schwache Zugangsdaten, SQL-Injection, XSS, XML-RPC-Missbrauch und lockere Dateiberechtigungen — jede mit einer spezifischen, bekannten Lösung statt eines vagen Aufrufs, "sicherer zu werden". Konsequente Updates und eine Handvoll konkreter Härtungsschritte schließen die überwältigende Mehrheit realer Angriffe, genau die Scan- und Dokumentationsarbeit, bei der unser Erdo CRA Compliance-Plugin neben breiteren EU-Compliance-Anforderungen helfen soll.