Wie WordPress angegriffen wird

Wenn wir bei einem Kundenblog die Login-Logs prüfen, sehen wir fast immer dasselbe Muster: hunderte fehlgeschlagene Login-Versuche mit Benutzernamen wie "admin", "administrator", "editor" oder dem Domain-Namen. Das sind Brute-Force-Attacken, und sie laufen rund um die Uhr, nachts, am Wochenende, an Feiertagen. Die Bots interessiert dein Redaktionsplan nicht.

Die Standard-Login-Seite /wp-login.php ist bei jeder WordPress-Installation an derselben Stelle. Bots kennen die Adresse und arbeiten automatisiert sogenannte Wordlists ab: kombinierte Listen aus typischen Standard-Logins (admin, administrator, editor, support, info, kontakt, dazu der Domain-Name und gängige Vornamen) und Passwort-Listen, die aus geleakten Datenbanken stammen. Bei einem schwachen Passwort und ohne Login-Limit dauert es manchmal nur Minuten.

Ein eigener Begriff, den du dabei kennen solltest, ist Credential Stuffing. Wenn ein Forum, ein Shop oder ein Tool, bei dem du irgendwann mal angemeldet warst, gehackt wurde und deine Mail-Passwort-Kombination im Darknet kursiert, probieren Bots diese Kombination automatisch auch auf WordPress-Logins durch. Das passiert ohne, dass jemand dich gezielt im Visier hat, dein Passwort steht einfach auf einer Liste, dein WordPress-Login ist auf einer zweiten Liste, der Bot kreuzt beide. Genau deshalb ist es so wichtig, dass dein WordPress-Passwort nirgendwo sonst im Einsatz ist.

Zur Geschwindigkeit: Ohne Limit kommt ein Bot je nach Server auf mehrere hundert Versuche pro Minute. Mit einer simplen Sperre nach fünf Fehlversuchen für ein paar Minuten und einem 12-stelligen Zufallspasswort wird ein Bruteforce-Versuch rechnerisch unmöglich, der Bot zieht weiter zur nächsten Domain auf seiner Liste.

Der häufigste Angriffsvektor sind aber gar nicht schwache Passwörter, sondern Plugins. Jedes Plugin ist zusätzlicher Code, der Schwachstellen enthalten kann. Wenn ein Plugin-Entwickler eine Lücke nicht rechtzeitig schließt oder du ein Update verpasst, steht die Tür offen. Wir haben Fälle gesehen, bei denen ein einziges veraltetes Kontaktformular-Plugin gereicht hat, um den gesamten Blog zu kompromittieren, inklusive der Datenbank mit allen Kommentaren, Mail-Adressen und Passwort-Hashes.

Ein konkretes, sehr deutsches Beispiel: das offizielle Plugin VG WORT METIS, das viele Foodbloggerinnen einsetzen, um die Zählpixel der VG Wort zu verwalten. Für alle Versionen bis einschließlich 2.0.1 führt die Wordfence-Datenbank eine Missing-Authorization-Schwachstelle als ungepatcht, und WordPress.org listet zugleich weiterhin 2.0.1 als aktuelle Plugin-Version (Stand Mai 2026). Die Lehre daraus: "Installiert und läuft" ist nicht dasselbe wie "sicher". Auch ein offiziell aussehendes Plugin von einer großen deutschen Verwertungsgesellschaft kann ungepatchte Lücken haben. Wir gehen in Lektion 5 ausführlicher darauf ein, wie du Plugins bewertest und welche Quellen du im Auge behalten solltest; im flankierenden Blogpost zu den 12 Sicherheitsmaßnahmen findest du außerdem die genaue Quellenkette mit den Wordfence-URLs.

Neben Login und Plugins gibt es zwei alte Schnittstellen, die WordPress mitschleppt und die Bots gezielt ansteuern.

Die erste ist XML-RPC, ein Relikt aus den Anfangsjahren, ursprünglich gedacht für externe Blog-Editoren und Trackbacks zwischen Blogs. Heute wird sie fast nur noch für gebündelte Brute-Force- und DDoS-Angriffe missbraucht: über einen einzigen XML-RPC-Aufruf lassen sich mehrere Login-Versuche gleichzeitig durchschicken, ohne dass die normale Login-Seite überhaupt beteiligt ist. Login-Limiter, die nur /wp-login.php überwachen, sehen davon nichts. Bei modernen Foodblogs braucht XML-RPC niemand mehr und kann in den allermeisten Fällen abgeschaltet werden.

Die zweite ist die REST API. Sie ist nützlich für moderne Editoren, Apps und Block-Funktionen, verrät aber in der Standardkonfiguration etwas, das sie nicht verraten sollte: Über /wp-json/wp/v2/users gibt WordPress für nicht eingeloggte Anfragen eine JSON-Liste aller Nutzer zurück, inklusive Login-Slug. Damit hat ein Bot die halbe Brute-Force-Arbeit schon gespart, er muss keine Login-Namen mehr raten, sondern bekommt sie geliefert. Wir gehen in Lektion 4 ausführlich darauf ein, wenn es um das Verstecken von Login-Namen geht; an dieser Stelle reicht es zu wissen, dass das Problem existiert und mit Bordmitteln zu lösen ist.

Was wir oft sehen: Blogs, bei denen das Admin-Passwort technisch in Ordnung ist, der Login-Slug aber öffentlich über die REST API abrufbar bleibt. Wenn ein Bot weiß, dass dein Login lisa heißt, muss er nur noch das Passwort durchprobieren, und genau dafür hat er Zeit.

Auch Kommentar-Spam klingt erst mal harmlos, ist es aber nicht. Spam-Bots posten Kommentare mit Links zu fragwürdigen Seiten, Casino-Werbung, vermeintliche Pillen, dubiose Shops, manchmal auch Phishing- oder Malware-Seiten. Wenn diese Links auf deinem Blog landen und Google sie crawlt, wirkt das auf zwei Ebenen: Erstens kann ein Klick deiner Leserin auf so einen Link sie auf eine Schadseite führen, zweitens rechnet Google den Linknachbarschafts-Effekt mit, wer sich mit Casino- und Pharma-Spam umgibt, sinkt im Ranking. Akismet oder ein vergleichbarer Spamfilter ist deshalb Pflicht, und in den meisten modernen WordPress-Setups ist er bereits dabei.

Ein wichtiger Punkt zum Schluss: WordPress selbst ist nicht unsicher. Der WordPress-Core wird von einem großen Sicherheitsteam gepflegt, Lücken werden in der Regel innerhalb weniger Tage geschlossen, Sicherheitsupdates kommen automatisch. Die Probleme entstehen fast immer eine Schicht darüber: bei veralteten Plugins, bei schwachen oder mehrfach verwendeten Passwörtern, bei fehlender Konfiguration der Schnittstellen und bei Themes aus zweifelhaften Quellen. Anders gesagt, es sind selten Zero-Days, die Foodblogs treffen, sondern Standard-Lücken, die seit Monaten dokumentiert sind.

Unser Tipp: Wenn du wissen willst, ob dein Blog gerade angegriffen wird, schau in die Server-Logs deines Hosters oder installiere vorübergehend ein Login-Logging-Plugin. Die Zahlen sind meistens überraschend hoch, selbst bei kleinen Blogs mit wenig Traffic, und sie machen den Punkt aus Lektion 1 sehr anschaulich, dass Bots keine Lieblingsblogs haben.

In den nächsten Lektionen gehen wir die Schichten der Reihe nach durch, zuerst die offensichtlichsten: Passwörter, Benutzerrollen und Zwei-Faktor-Login. Danach die etwas leiseren Stellen: REST API, XML-RPC, Plugin-Hygiene und das Backup-Konzept, das du brauchst, wenn doch mal etwas durchrutscht.