ReportedIP Hive 2.1.41 – Blockierung von Tor-Ausgangs-Knoten, vertrauenswürdige Proxys und ein Sicherheits-Widget für das Dashboard
ReportedIP Hive 2.1.41 bietet nun eine optional aktivierbare Blockierung von Tor-Exit-Knoten, Quellbereichsangaben für vertrauenswürdige Proxys sowie ein Sicherheits-Widget direkt im WordPress-Dashboard. Damit findet eine Serie von fünf Veröffentlichungen ihren Abschluss, in deren Rahmen zudem zwei tatsächliche Sicherheitslücken behoben wurden: Release-Builds, die ohne die mitgelieferten Regelsätze ausgeliefert wurden, sowie Ausnahmeregelungen für Crawler, bei denen ein nicht überprüfbarer User-Agent ungeprüft akzeptiert wurde.
Laden Sie das Update über „Plugins → Nach Updates suchen“ oder von der GitHub Releases-Seite herunter; der Hardware-Schlüssel-Meilenstein, der diesem Release vorausging, wird im Bericht zu Version 2.1.36 behandelt.
Was hat sich zwischen den Versionen 2.1.37 und 2.1.41 von Hive geändert?
Innerhalb von neun Tagen, zwischen dem 06.08.2026 und dem 14.08.2026, wurden fünf Versionen veröffentlicht. Drei davon sind kleinere, gezielte Aktualisierungen; die Versionen 2.1.40 und 2.1.41 stellen die wesentlichen Neuerungen dar.
| Version | Änderung der Überschrift |
|---|---|
| 2.1.37 | Domainumzug zu reportedip.com – alle Links, der Standard-API-Endpoint und die Kontaktadressen; bei der Migration v14 wird ein gespeicherter Standard-Endpoint überschrieben, die alte Domain behält eine permanente Weiterleitung bei. |
| 2.1.38 | wp reportedip 2fa enable --method=totp Erzeugt und gibt nun einen Secret aus, anstatt eine Methode zu kennzeichnen, die niemals verifiziert werden könnte; die E-Mail-/SMS-Bestätigung sendet beim ersten Absenden einen Code, anstatt die Eingabe abzulehnen. |
| 2.1.39 | In den Release-Builds werden die gebündelten WAF-Regelsätze wieder mitgeliefert – diese hatten zuvor vollständig gefehlt – sowie vier Firewall Rules gegen die XSS-Kette beim Login (CVE-2026-64638). |
| 2.1.40 | Ein Crawler-User-Agent, dessen Identität niemand überprüfen kann, erhält keine „Block-Ladder“-Ausnahme mehr, und eindeutig böswillige Anfragen führen zur sofortigen Aufhebung der Ausnahme. |
| 2.1.41 | Blockierung von Tor-Ausgangsknoten, Quelladressbereiche für vertrauenswürdige Proxys, ein wp-admin-Sicherheits-Widget, ein „Never-Block“-Veto für verifizierte Infrastruktur, eine erweiterte IP-Abfrage sowie wettlaufsichere Versuchszähler. |
Tor-Ausgangsknoten können nun beim Login blockiert werden
Bei professionellen Installationen steht auf der Registerkarte „Schutz“ ein neuer Opt-in-Schalter zur Verfügung, der Login-Versuche von bekannten Tor-Ausgangsknoten abweist. Die Liste der Ausgangsknoten wird als neuer signierter tor_exits Regelsatz im Rahmen des regulären Rule Sync bereitgestellt und wird serverseitig zweimal täglich aktualisiert, sodass sie mit der Rotation der Ausstiegsknoten Schritt hält; bei Adressen, die die Liste noch nicht erfasst hat, greift die Community isTor Markierung der Community.
Es sind zwei absichtliche Einschränkungen integriert. Sperren sind vorübergehend – standardmäßig 24 Stunden, einstellbar über den reportedip_hive_tor_block_hours Filter – und eine Tor-Sperre wird niemals an die Community gemeldet, da der Betrieb eines Exit-Knotens kein Hinweis auf Missbrauch ist. Die Funktion ahndet ein Verhalten auf Ihrer Website, nicht die Teilnahme am Tor-Netzwerk.
„Trusted-Proxy“-Quellbereiche schließen eine Sicherheitslücke im Zusammenhang mit Spoofing von Kopfzeilen
Wenn sich Ihre Website hinter Cloudflare oder einem Reverse-Proxy befindet, liest Hive die Besucheradresse aus einem weitergeleiteten Header aus. Bislang konnte jeder, der eine direkte Verbindung zum Ursprungsserver herstellte, diesen Header selbst senden – und sich so als eine auf der Whitelist stehende Adresse ausgeben oder eine gesperrte Adresse verschleiern.
2.1.41 berücksichtigt den „Trusted IP“-Header nur dann, wenn der verbindende Peer eine der von Ihnen angegebenen Proxy-Adressen ist (eine IP-/CIDR-Liste unter „Einstellungen“ → „Allgemein“). Eine leere Liste behält das bisherige Verhalten bei, sodass bei der Aktualisierung keine Probleme auftreten. Die gleiche Bereichsprüfung ist in den Pre-WordPress-Guard integriert, der nun auch die Anforderung einer öffentlichen Adresse auf Header-Kandidaten anwendet – wodurch eine Konsistenzlücke zum WordPress-eigenen Resolver geschlossen wird.
Die Firewall vertraut den Crawlern nicht mehr blind
2.1.40 behebt den schwerwiegendsten Befund dieses Durchlaufs. Die Allowlist des Crawlers enthält 71 User-Agent-Token, doch der bot_signatures Regelsatz enthält jedoch nur Überprüfungsregeln für eine Handvoll davon. Für jedes dazwischenliegende Token gab der Verifizierer unmatched — und is_exempt_crawler() behandelte alles, was nicht als bestätigt fake als bestanden. Die Angabe, GPTBot, PerplexityBot oder UptimeRobot zu sein, reichte daher aus, um die Sperrstufe zu umgehen und den Community-Reports zu entgehen. Auf einer Produktionswebsite wurden innerhalb von drei Tagen 47 Sperren übersprungen – jede einzelne aufgrund einer Anfrage, die /.env, /config.php.bak oder /ssl/server.key aus einem Cloud-Bereich, der keinem der vom User-Agent angegebenen Nutzer zuzuordnen war.
Eine Ausnahme erfordert nun eine Regel, die ein tatsächliches Verifizierungssignal übermittelt – ein Reverse DNS-Suffix oder einen offiziellen IP-Bereich – sowie eine Einstufung, die nicht fake. Um die überprüfbare Menge bei kostenlosen Installationen aussagekräftig zu halten, wurde die mitgelieferte Basisliste um Baiduspider, LinkedInBot und Amazonbot erweitert, die alle allein durch Reverse DNS überprüfbar sind.
Der zweite Teil der Korrektur: Eindeutig böswillige Anfragen führen zum sofortigen Entzug der Ausnahmegenehmigung. Ein Treffer in einem Honeypot, ein Treffer auf einem Decoy Path oder eine WAF-Übereinstimmung in den Payload-Regelgruppen (Pfadtraversierung, Dateiprobe, Befehls- und PHP-Injektion, Webshell, Log4Shell, XXE, SSTI, NoSQL, CRLF, SSRF) führt nun zum Entzug der Crawler-Ausnahme und wird wie folgt protokolliert bot_exemption_denied. SQL Injection- und XSS-Regeln behalten bewusst die normale Funktionsweise bei – Suchbegriffe und Editorinhalte lösen diese Muster aus, und ein Kunde, der nach einer Produktnummer sucht, darf deswegen nicht ausgesperrt werden.
Diese Payload-Gruppen blockieren nun ebenfalls bereits beim ersten Treffer, anstatt auf den standardmäßigen Schwellenwert von drei zu warten. Der Schwellenwert dient dazu, dass ein False Positive lediglich eine Anfrage kostet und nicht mehr – doch beim Hochladen einer Webshell gibt es keine False-Positive-Fläche, die es zu schützen gilt, sodass das Warten dem Scanner lediglich einen Vorsprung verschafft hätte. Filterbar über reportedip_hive_waf_immediate_block_groups.
2.1.39 Die gebündelten Regelsätze wieder in die Release-Version integrieren
Dies verdient ein offenes Eingeständnis. Der Release-Workflow wurde includes, admin, assets, templates und languages – jedoch nicht data, in dem sich die vier Basis-Regelsätze befinden. In einer installierten Release-Kopie Rule_Sync::load_baseline() wurde keine Datei gefunden und eine leere Menge zurückgegeben, sodass die Firewall zurückkehrte, bevor sie irgendetwas überprüfte; die Bot-Signaturen und die Liste der Wegwerf-Domains waren aus demselben Grund leer.
Installationen, die Regelsätze über die API synchronisieren, waren davon nicht betroffen, da ein gespeicherter Regelsatz die Baseline ersetzt, anstatt mit ihr zusammengeführt zu werden – und genau aus diesem Grund blieb dies unbemerkt: Die überprüften, verbundenen Installationen funktionierten einwandfrei, während Installationen im lokalen Modus und nicht verbundene Installationen eine inaktive Firewall ausführten. Sowohl der Release-Workflow als auch der lokale Build führen nun eine Staging-Phase durch data und werden abgebrochen, sobald eine der vier Baselines im vorbereiteten Verzeichnisbaum fehlt. Falls Sie Hive im „Local Shield“-Modus ausführen, führen Sie bitte umgehend ein Update durch.
Mit derselben Veröffentlichung wurden vier Regeln des Paranoia-Levels 1 gegen CVE-2026-64638 (XSS2Shell) hinzugefügt, die am 06.08.2026 veröffentlichte Angriffskette für den WordPress-Login-Bildschirm. Die Angriffskette benötigt weder ein <script>-Tag noch einen Event-Handler — sie schmuggelt reines HTML durch ein Parser-Differential der Sanitizer und lässt ein id-Attribut eine globale JavaScript-Variable überschreiben. waf_xss_login_markup weist einen Login-Wert mit spitzer Klammer ab (nie legitim — sanitize_user() entfernt sie), waf_xss_tag_differential erkennt das Clobbering-Primitiv selbst und deckt damit die gesamte Fehlerklasse statt nur eines Advisories ab, und zwei Begleitregeln schließen die Same-Origin-Method-Execution-Eskalation. Gemessen an 12 Angriffsvarianten und 34 legitimen Requests: 12 blockiert, 0 False Positives. Das ist Defence in Depth, kein Ersatz für den Fix — WordPress 7.0.3 oder das gepatchte Release des eingesetzten Branches bleibt erforderlich.
Im wp-admin-Dashboard wird nun endlich angezeigt, was Hive gerade tut
Ein neues Sicherheits-Widget (admin/class-dashboard-widget.php) zeigt auf der Startseite von wp-admin die in den letzten 30 Tagen blockierten Angriffe, die heutigen Blockierungen, aktive IP-Sperren, die aktivierten Schutzebenen sowie den Erkennungswert an und enthält Deep-Links zum Plugin. In Multisite-Umgebungen wird das Widget auf dem Netzwerk-Dashboard angezeigt und steht Super-Admins auf den Dashboards der Unterwebsites mit netzwerkweiten Zahlen zur Verfügung.
Drei kleinere Änderungen an der Anzeige werden ebenfalls eingeführt. Ein API-Statusbalken im Sicherheits-Dashboard fasst den Verbindungsstatus, die Kontingentauslastung (mit Countdown bis zum Zurücksetzen) und den Status des Rate Limiting auf einen Blick zusammen – ausschließlich auf Basis zwischengespeicherter Daten. Die Anzeige des täglichen Kontingents wird zwischen den Cron-Läufen aktualisiert, indem die X-RateLimit-Header ausgelesen werden, die die API bereits mit jeder Antwort übermittelt. Nach einem Update zeigen die Plugin-Seiten ein einmalig schließbares „Was ist neu?“-Banner mit den Highlights der Veröffentlichung an (includes/class-whats-new.php) – das Ausblenden erfolgt benutzerspezifisch, und das Banner blockiert niemals eine Seite, wenn der Feed nicht erreichbar ist.
IP-Adressen haben im Admin-Bereich einen festen Platz erhalten
Jede IP-Adresse in den Protokollen, den Tabellen „Blockiert“, „Whitelist“ und „Top-Angreifer“ enthält nun eine Kopierfunktion, eine interne Suchfunktion sowie einen externen Link zu ihrer öffentlichen Profilseite auf ReportedIP.com; für die Top-Angreifer wurden Inline-Aktionen zum Blockieren und Entsperren hinzugefügt. Die Registerkarte „Lookup“ wurde erweitert: Sie zeigt nun den ISP, die ASN, die Nutzungsart, die Domain, die Anzahl der verschiedenen Melder sowie den Zeitpunkt der letzten Meldung an, kennzeichnet Tor-Ausgangsknoten und von der Community verifizierte Infrastruktur und bietet auf der Ergebniskarte Schnellaktionen zum Blockieren bzw. zur Aufnahme in die Whitelist an.
wp reportedip lookup(includes/class-lookup-cli.php) erweitert WP-CLI um dieselbe Suchfunktion mit Ausgabe im Tabellen-, JSON-, CSV- und YAML-Format.- Ein „Add-my-IP“-Hilfsprogramm im Whitelist-Formular fügt Ihre aktuelle Adresse mit einem Klick zur Whitelist hinzu – bei IPv6 wird das /64-Netzwerk automatisch vorausgefüllt, sodass rotierende Privatpräfixe ihre Besitzer nicht mehr aussperren. Wenn Sie Ihre eigene aktuelle IP-Adresse blockieren möchten, werden Sie nun zunächst um eine Bestätigung gebeten.
- Das Ereignisprotokoll wurde um einen Filter für den Datumsbereich erweitert, und die Zeilenaktion „Aus Protokoll entfernen“ bietet nun die Möglichkeit, die Dauer selbst festzulegen, anstatt auf feste 24 Stunden beschränkt zu sein.
Geprüfte Infrastruktur wird niemals gesperrt – und Integratoren erhalten einen stabilen Anknüpfungspunkt
Wenn der Reputationsdienst eine Adresse als kuratierte Infrastruktur kennzeichnet – Suchmaschinen-Crawler, große CDNs, Überwachungsflotten –, schreibt Hive dafür keinen lokalen Block mehr, weder über den Reputationspfad noch über die Auto-Block-Leiter, und protokolliert infrastructure_spared stattdessen. Reports werden weiterhin versendet: Sperren sind Konsequenzen, Reports sind Beweismittel.
Für Webhook-, SIEM- und Slack-Integrationen gibt es nun einen einheitlichen Anbindungspunkt: reportedip_hive_threshold_exceeded Er wird bei jeder bestätigten Sensorerkennung ausgelöst, unabhängig von den Einstellungen für automatische Blockierung und Berichterstellung. Die dokumentierte reportedip_hive_report_queued Aktion existiert nun tatsächlich (sie wird einmal pro Report ausgelöst, der in die API-Warteschlange gelangt), und die Blockierungsseite wurde reportedip_hive_access_denied zusätzlich ein reportedip_hive_blocked_page_strings Filter für White-label-Text-Überschreibungen.
Wichtige Fehlerbehebungen: unsichtbare E-Mail-Betreffzeilen, zu schnell zählende Zähler, veraltete Cache-Daten
Die auffälligste Korrektur betrifft die Benachrichtigungen und die E-Mails zur 2FA. Die Farbe der Kopfzeilenzelle wurde ausschließlich als CSS-Farbverlauf dargestellt – GMX Webmail und Outlook für Android haben linear-gradient(), was dazu führte, dass weißer Kopfzeilentext auf einer weißen Zelle erschien und Spamfilter die Nachricht mit HTML_FONT_LOW_CONTRAST. Kopfzeile und Aktionsschaltfläche haben nun einen einfarbigen indigoblauen Hintergrund (bgcolor Attribut plus background-color) und behalten den Farbverlauf als progressive Erweiterung bei; das Inline-SVG-Logo, das von beiden Clients als störende Artefakte dargestellt wurde, ist entfernt worden. Gemeldet von Benjamin Grösch – vielen Dank.
- Racesichere Versuchszähler.
track_attempt()Dies erfolgt nun als einzelner atomarer „Upsert“-Vorgang auf einem eindeutigen(ip_address, attempt_type)Schlüssel (Schema v15, mit Bereinigung doppelter Zeilen), sodass parallele Serien fehlgeschlagener Logins nicht mehr durch „Read-then-Update“-Wettläufe an Zählwerten verlieren können. - Die Backoff-Regelung bei den Rate Limits gilt endpunktbezogen. Ein 429-Fehler auf dem Berichtsweg führt nicht mehr zur Unterbrechung der Reputationsabfragen, und der Berichtsweg berücksichtigt nun den „Retry-After“-Parameter, den er zuvor ignoriert hatte.
- Der Reputations-Cache berücksichtigt die Ausführlichkeitsstufe und Ihre eigenen Reports. Ein Cache-Eintrag ohne Ausführlichkeitsangabe erfüllt nicht mehr die Anforderungen einer Abfrage mit ausführlicher Auswertungsstufe, und ein erfolgreicher eigener Report macht die im Cache gespeicherte Reputation ungültig, anstatt Daten bereitzustellen, die bis zu 24 Stunden alt sind.
- CIDR-Bereiche werden in der manuellen Blockform akzeptiert – die Durchsetzungsebenen unterstützen diese bereits seit Version 2.1.32, und die Validierung des Formulars entspricht nun ebenfalls dieser Vorgehensweise.
- Einstellungen, die ausschließlich für WooCommerce gelten, werden ohne WooCommerce ausgegraut; anstelle eines nicht funktionsfähigen Umschaltfelds wird ein Hinweis angezeigt, und die Kontakt-URL der gesperrten Seite im Multisite-Modus ist nun wieder netzwerkweit erreichbar.
- Barrierefreiheit. Fokusringe bleiben auch im Windows-Modus „Hoher Kontrast“ erhalten, die Funktionen „Erzwungene Farben“ und „Reduzierte Bewegung“ decken das Admin-Designsystem ab, Symbolschaltflächen erfüllen die Anforderungen an 40-Pixel-Touch-Zielflächen bei groben Zeigern, AJAX-Benachrichtigungen werden über einen unaufdringlichen Live-Bereich angezeigt, und rund 90 zuvor fest codierte Admin-JS-Zeichenfolgen sind nun übersetzbar.
So führen Sie ein Update auf Hive 2.1.41 durch
Der integrierte Update-Checker fragt GitHub alle 12 Stunden ab; um die neue Version sofort herunterzuladen, öffnen Sie „Plugins“ → „Nach Updates suchen“. Die Systemvoraussetzungen bleiben unverändert: WordPress 5.9+ und PHP 8.1+. Eine manuelle Migration ist nicht erforderlich – das Upgrade-Verfahren führt die Migration v14 (Umschreibung eines gespeicherten Standard-API-Endpunkts auf reportedip.com) und das Schema v15 automatisch durch.