Veröffentlichungen

Hive 2.1.51: Schutz vor unberechtigten Registrierungen und Zugriffsbeschränkung für WordPress

9. September 2026 · Patrick Schlesinger

ReportedIP Hive 2.1.51 wurde am 9. September 2026 veröffentlicht und enthält fünf neue Schutzmaßnahmen, von denen drei in jedem Tarif kostenlos verfügbar sind. Außerdem wird damit eine Lücke im Hardening Mode geschlossen die seit Version 2.0.8 bestand und dazu führte, dass bei einem koordinierten Angriff die Logins in WooCommerce-Storefronts die gelockerten Schwellenwerte auslesen konnten.

Das Update lässt sich wie jede andere Version installieren. Betreiber von Websites, die auf die WordPress-Benutzer-Sitemap angewiesen sind, sollten zunächst den letzten Abschnitt lesen.

Was ist neu in Hive 2.1.51?

Besonderheit	Plan	Funktionsweise
Eintragungsverteidigung	Kostenlos, umfangreichere Funktionen in der Professional-Version	Verbotene Benutzernamen, E-Mail-Regeln, ein Rate Limit für die Anmeldungen pro IP-Adresse, eine Sperre bei unbekannten Benutzernamen
Zugriffssperrschalter	Kostenlos	Deaktiviert die REST API, XML-RPC, Feeds, den Gastzugang zu wp-admin, PHP in Uploads sowie Versions-Fingerabdrücke
Register für die Systembereitschaft	Kostenlos	Zwölf Detektoren für die Teile einer Anlage, die ohne Vorwarnung ausfallen
Konto-Sperrung und Sitzungen	Business	Sperrt ein Konto, ohne es zu löschen, listet aktive Sitzungen auf und beendet diese
Adaptive Zwei-Faktor-Auslöser	Professional	Sieben Regeln zur Stufenanpassung pro Rolle hinsichtlich der Anzahl neuer Länder, IP-Adressen, Netzwerke, Geräte oder Sitzungen

Der Registrierungsschutz deckt alle Anmeldeoberflächen ab

Bis zur Version 2.1.51 hatte der Registrierungssensor lediglich eine Funktion: Er verglich die E-Mail-Domain mit einer Liste von Wegwerf-E-Mail-Adressen. Nun handelt es sich um einen Regelsatz, der class-registration-guard.php mit fünfzehn Optionen dahinter.

• Verbotene Benutzernamen, zusätzlich zu einer integrierten Grundauswahl von zehn Rollennamen, sodass admin, administrator, root diese sowie ihre Ableitungen werden ohne jegliche Konfiguration abgelehnt.
• Regeln zum Zulassen oder Blockieren von E-Mails, die anhand der Liste der Wegwerf-E-Mail-Adressen ausgewertet werden. Datenschutz-Relays wie „Apple Hide My Email“ und „Firefox Relay“ werden standardmäßig durchgelassen.
• Ein Rate Limit pro IP-Adresse: standardmäßig drei Anmeldungen pro 60 Minuten. Das Zeitfenster ist auf 60 Minuten begrenzt, da der gemeinsame Versuchszähler stündlich zurückgesetzt wird.
• Eine Opt-in-Sperre für Anmeldeversuche mit nicht existierenden Benutzernamen, genau solche Versuche werden bei Credential Stuffing-Angriffen in großer Zahl durchgeführt.

Die Regeln gelten für das WordPress-Registrierungsformular, WooCommerce, Multisite-Anmeldungen sowie programmgesteuert angelegte Benutzer, sodass ein Theme oder Plugin, das wp_insert_user() , kann sich diesen nicht entziehen. Zehn einfache Einträge pro Liste sind in jedem Tarif kostenlos. Der Professional-Tarif hebt die Begrenzung auf, akzeptiert /regex/ Muster an und fügt eine Registrierung ausschließlich über die Allowlist hinzu, bei der Konten nur aus aufgelisteten IP-Bereichen und von keiner anderen Stelle aus erstellt werden können. Die vollständige Liste der Optionen finden Sie in der Dokumentation zu den Registrierungsregeln.

Die Zugriffssperre deaktiviert alle Funktionen, die die Website nicht nutzt

Die meisten WordPress-Installationen enthalten Funktionen, die ihre Betreiber nie nutzen. Ein neuer Abschnitt auf der Seite „Firewall“ deaktiviert diese Funktionen, kostenlos in jedem Tarif, wobei jede Deaktivierung standardmäßig aktiviert ist:

• Die REST API für nicht angemeldete Besucher bzw. für alle Personen außerhalb einer ausgewählten Gruppe von Rollen und Namensräumen.
• XML-RPC in Verbindung mit Pingbacks.
• Feeds.
• Der Administrationsbereich für nicht angemeldete Besucher.
• PHP-Ausführung im Ordner „uploads“, in die Datei „uploads“ geschrieben .htaccess unter Apache. Für nginx und unbekannte Server erhalten Sie den Codeausschnitt zum Einfügen.
• Die Versions-Fingerabdrücke im Quellcode der Seite.

Sechs dieser Elemente wurden in die Absicherungsbewertung aufgenommen, und die bestehenden Gewichtungen wurden herabgesetzt, sodass die Gesamtsumme weiterhin 100 beträgt. Nach der Aktualisierung verschieben sich die Bewertungen um einige Punkte, ohne dass sich irgendwelche Einstellungen geändert hätten. Details: Schalter zur Zugriffsbeschränkung.

Zwölf Detektoren für die Störungen, die niemand bemerkt

Ein Sicherheits-Plugin, das unbemerkt nicht mehr funktioniert, ist schlimmer als gar keines, da das Dashboard weiterhin einen einwandfreien Zustand anzeigt. Das neue Bereitschaftsregister überwacht zwölf Zustände: eine nicht beschreibbare „Pre-WordPress“-Guard-Warteschlange, einen hängenden oder deaktivierten Cron-Job, einen „Trusted Proxy Header“, der ohne Proxy-Bereiche konfiguriert ist, ein veraltetes Datenbankschema, eine beeinträchtigte Community-Ebene, ausgeschöpfte Mail- oder SMS Relay-Kontingente, fehlgeschlagene E-Mail-Zustellungen, eine fehlende Verschlüsselungserweiterung sowie eine wachsende Berichtswarteschlange.

Offene Probleme werden auf der Seite „Systemstatus“ mit ihrem Schweregrad, dem Zeitpunkt ihres ersten Auftretens, einem Link zur zuständigen Einstellung und einem Link zur Dokumentation angezeigt. Warnungen und Hinweise können sieben Tage lang geschlossen werden, kritische Probleme hingegen nicht. Das Dashboard-Widget zeigt die Anzahl an und wp reportedip status meldet diese in einem neuen issues Feld an. Siehe „Systembereitschaft“.

Ein Konto sperren, ohne es zu löschen

Im Business-Tarif kann ein Konto nun über die Profilseite, über die Benutzerliste oder mit wp reportedip user block. Ein gesperrtes Konto behält seine Beiträge, Bestellungen und Medien bei, kann sich jedoch nicht anmelden, kein Anwendungskennwort authentifizieren und keine Kennwortzurücksetzung durchführen. Alle Sitzungen und Trusted Devices des Kontos werden in dem Moment gelöscht, in dem die Sperrung aktiviert wird.

Der zugehörige Bildschirm unter „Benutzer, Sitzungen“ listet alle aktiven Sitzungen mit Angaben zu Benutzer, Anmeldezeit, Ablaufzeit, IP-Adresse und Gerät auf und ermöglicht es, eine einzelne Sitzung oder alle Sitzungen eines Benutzers zu beenden. Ihre eigene aktuelle Sitzung kann über diese Liste niemals beendet werden. Sperren bleiben bestehen und können jederzeit aufgehoben werden, auch nach Ablauf eines Abonnements, sodass eine abgelaufene Lizenz niemals dazu führen kann, dass jemand ausgesperrt bleibt. Details: Benutzerkontensteuerung und Sitzungen.

Adaptive Zwei-Faktor-Auslöser je nach Rolle

Trusted Devices sind praktisch, stellen jedoch gleichzeitig eine Schwachstelle dar, auf die es Angreifer abgesehen haben. In der Professional-Version können nun pro Rolle sieben Auslöser für eine verstärkte Sicherheitsstufe aktiviert werden: ein neues Land, eine neue IP-Adresse, ein neues Netzwerk, ein neues Gerät, alle N Tage, alle N Anmeldungen sowie mehr als N gleichzeitige Sitzungen. Ein Benutzer, auf den diese Kriterien zutreffen, wird erneut zur Eingabe des zweiten Authentifizierungsfaktors aufgefordert, selbst wenn das Cookie für Trusted Devices vorhanden ist.

Im Lieferumfang sind zwei Schutzvorrichtungen enthalten. Benutzer ohne konfigurierte Authentifizierungsmethode werden niemals ausgesperrt, und die Administratorrolle kann erst aktiviert werden, nachdem ein Administrator eine 2FA-Authentifizierung an diesem Standort erfolgreich abgeschlossen hat. Die 2FA-IP-Allowlist und der reportedip_2fa_bypass Filter umgehen weiterhin die Auslöser. Siehe „Adaptive Step-Up-Auslöser“.

Die Lücke im „Hardening Mode“, die bis zur Version 2.0.8 zurückreichte

The Hardening Mode tightens the failed Login threshold for one hour when a coordinated attack is detected. Zwei Sensoren haben die verschärften Werte nie erfasst: der WooCommerce-Login-Überwacher, der „Mein Konto“ und den klassischen Bezahlvorgang abdeckt, sowie der Überwacher für Anwendungspasswörter. Beide lasen weiterhin die gelockerte Konfiguration aus, sodass ein Botnetz, das auf die Formulare der Storefront abzielte, einen Angriff durchführte, den das Login-Formular normalerweise gestoppt hätte.

Die Sicherheitslücke geht auf die Version 2.0.8 zurück, als der Hardening Mode erstmals eingeführt wurde. Websites ohne WooCommerce und ohne Anwendungskennwörter waren davon nie betroffen. Beide Überwachungsfunktionen durchlaufen nun ihre Schwellenwerte über dieselbe Begrenzung wie „wp-login“, ebenso wie die Simulation des Schwellenwerts auf der Administrationsseite, und ein Paritätstest auf Quellcodeebene führt zum Fehlschlagen des Builds, sollte ein zukünftiger Sensor einen Login-Schwellenwert ohne diese Begrenzung auslesen.

Ein Einstellungsstandard: 169 Optionen, davon 71 per Fernbedienung

Siebzig Optionen befanden sich außerhalb der Einstellungsregistrierung, was bedeutete, dass MainWP und die Cloud-Flotte diese nicht verwalten konnten und sie im JSON-Export nicht berücksichtigt wurden: die Security Headers, das „trusted-proxy“-Paar, das Anwendungskennwort und die REST-Limits, das Fenster für geografische Anomalien, den WooCommerce-Anmeldeüberwacher, die „Hide Login“-Prüfung, die Passwortrichtlinie, die Einstellungen für Caching und die Berichtswarteschlange sowie das Fußzeilen-Badge. Alle diese Optionen sind nun in der Konfigurationsdatenbank hinterlegt und werden durch einen einzigen Sanitizer anstelle mehrerer verarbeitet.

Drei Konsequenzen sind besonders erwähnenswert. Alle 169 Optionen verfügen nun über eine einzeilige Beschreibung, sodass MainWP und die Flotte nun echten Text anstelle einer bloßen Bezeichnung anzeigen. Der Exportkatalog wird aus der Registrierungsdatenbank abgeleitet und nicht mehr separat geführt, da sich die beiden um fünfundfünfzig Schlüssel voneinander entfernt hatten. Und eine importierte Einstellungsdatei kann nichts mehr schreiben, was den Sanitizer umgeht: Der alte Rohpfad ist weg, was vor allem für den Header „Trusted Client-IP“ von Bedeutung war, bei dem ein beliebiger Wert die Voraussetzung dafür ist, jeden Sensor, die Whitelist und die Blockliste gleichzeitig zu manipulieren.

Da keine Optionstaste geändert wurde, bleiben die gespeicherten Flottenrichtlinien und standortspezifischen Überschreibungen nach dem Update unverändert bestehen. Bei beiden Dashboards ist ein Neuladen des Schemas erforderlich, damit die neue Gruppierung angezeigt wird.

Bevor Sie das Update durchführen: Die Benutzer-Sitemap verschwindet

Eine Änderung wird die Nutzer überraschen. wp-sitemap-users-1.xml Die Datei existiert nicht mehr, solange die Sperrung der User Enumeration aktiv ist, und da diese Option standardmäßig aktiviert ist, geht diese Datei bei den meisten Websites mit diesem Update verloren. Dies ist beabsichtigt: Dieselbe Schutzmaßnahme blockiert bereits ?author= sowie die REST-Benutzerroute, und die Sitemap war die einzige verbleibende veröffentlichte Liste von Benutzernamen auf der Website. Suchmaschinen benötigen sie nicht, und Autorenarchivseiten bleiben crawlbar, wenn Sie sie unter „Schutz“ und „Erkennung“ öffentlich zugänglich halten.

Version 2.1.51

Die Full Edition fragt alle 12 Stunden die GitHub Releases ab, sodass das Update automatisch auf der Seite „Plugins“ erscheint. Um es sofort zu übernehmen, laden Sie die ZIP-Datei der Version 2.1.51 von GitHub herunter und laden Sie sie über die bestehende Installation hoch. Die Migrationen werden bei der Aktivierung idempotent ausgeführt; das Datenbankschema liegt in Version 16 vor.

• Vollständige Dokumentation zum Plugin, einschließlich der zwölf Bereitschaftsdetektoren und der WP-CLI-Referenz
• Tarife und die jeweiligen Vorteile der einzelnen Stufen, falls Sie zwischen dem „Professional“- und dem „Business“-Tarif abwägen