Websites herunterladen, die Wordfence Login Security nutzen

Über Wordfence Login Security

Die Entscheidung für ein eigenes Login-Plugin ist enger gefasst als die für eine Sicherheitssuite, und genau darin liegt das Signal. Wordfence Login Security gibt es, weil manche Administratoren Zwei-Faktor-Authentifizierung, ein CAPTCHA auf der Login-Seite und Schutz für XML-RPC in WordPress wollen, ohne gleich eine Firewall und einen Malware-Scanner einzuführen. Defiant Inc. veröffentlichte das Plugin 2019 unter der Lizenz GPL v3. Es ist in PHP geschrieben und bildet den herausgelösten Teil eines viel größeren Produkts, der einzeln für alle angeboten wird, die nur diesen Teil wollten.

Der Einsatz beschreibt daher einen Administrator mit einer eigenen Meinung. Entweder besetzt bereits ein konkurrierendes Sicherheitsprodukt den Platz der Firewall, und der Login-Bereich war die verbliebene Lücke, oder die Website wird bewusst schlank gehalten, und der Betreiber hat die eine Schutzmaßnahme gewählt, die gegen den Credential-Stuffing-Traffic hilft, den jede WordPress-Installation abbekommt, ob jemand hinschaut oder nicht. In beiden Fällen ist der Betreiber derselbe Typ Mensch: jemand, der sich ein Login-Protokoll angesehen und bewusst entschieden hat, statt eine Voreinstellung hinzunehmen. Stand Oktober 2026 erfassen wir das Plugin auf 1.534 Websites.

An den Versionsangaben wird eine Liste von Sicherheits-Plugins operativ interessant, und gerade hier muss man sie am sorgfältigsten lesen. Über die Installationen hinweg, deren Version wir ermitteln können, tauchen 19 verschiedene Versionen auf, und Version 9.0.1 kehrt bei einem großen Teil davon wieder. Bei einem Plugin, dessen ganzer Zweck die Härtung der Authentifizierung ist, ist eine so breite Versionsstreuung schon für sich ein Befund, denn eine Installation, die zurückbleibt, schützt den Login mit einem Stand, dem bereits veröffentlichte Korrekturen fehlen.

Die Versionsnummern stammen hier nicht aus einem Admin-Bereich, denn auf einen solchen hat kein Crawler Zugriff. Wir leiten die Version aus Asset-URLs ab, die sie als Query-Parameter tragen, aus Readme-Dateien, die manche Installationen öffentlich lesbar lassen, und aus anderen Fingerprints, die eine Installation ungewollt preisgibt. Eine Website, die diese entfernt oder hinter einem Cache oder Optimierer liegt, der Asset-URLs umschreibt, liefert überhaupt keine Version statt einer falschen. Die Zahl 19 erfasst also nur die tatsächlich beobachtbaren Versionen, und die Aufschlüsselung nach Versionen deckt nur einen Teil von insgesamt 1.534 Websites ab, nicht alle.

Für eine einzelne Domain ist die Frage so einfach, dass eine Einzelabfrage sie klärt: Hat diese Website eine Login-Härtung im Einsatz? Fragen zum gesamten Bestand sind grundsätzlich anders und lassen sich nicht Abfrage für Abfrage zusammensetzen. Welche Hosting-Plattformen lassen ihre WordPress-Flotten auf alten Plugin-Builds laufen? Verbreitet sich ein neues Release innerhalb von Tagen oder über Quartale? Wie groß ist der erreichbare Markt für ein konkurrierendes Zwei-Faktor-Produkt wirklich, und welcher Teil dieses Marktes zahlt derzeit nichts für die Funktion?

Sicherheitsanbieter, die die Größe eines Segments abschätzen, Forscher, die das Patch-Verhalten in einem Ökosystem messen, und Hosting-Anbieter, die prüfen, was ihre eigenen Kunden tatsächlich betreiben, brauchen alle dasselbe: jede Domain, ihr Plugin und die jeweils ermittelbare Version, zusammen in einer Datei. Muster im Patch-Verhalten zeigen sich zwischen Websites und nicht innerhalb einer einzelnen, und genau diese Ebene erreicht eine Einzelabfrage pro Domain nicht.