ReportedIP Hive 2.1.41 — Blocage des nœuds de sortie Tor, proxys de confiance et widget de sécurité pour le Dashboard
ReportedIP Hive 2.1.41 ajoute un blocage optionnel des nœuds de sortie Tor, des plages d’adresses source de proxys de confiance et un widget de sécurité directement accessible depuis le Dashboard WordPress. Cette version vient clore une série de cinq mises à jour qui ont également corrigé deux véritables failles de pare-feu : des versions livrées sans leurs jeux de règles intégrés, et des exemptions pour les robots d’indexation qui acceptaient sans vérification un user-agent non vérifiable.
Vous pouvez télécharger la mise à jour via « Plugins → Vérifier les mises à jour » ou depuis la page GitHub Releases ; l’étape relative à la clé matérielle qui a précédé cette version est décrite dans le compte-rendu de la version 2.1.36.
Quels sont les changements entre les versions 2.1.37 et 2.1.41 de Hive ?
Cinq versions ont été publiées en neuf jours, entre le 06/08/2026 et le 14/08/2026. Trois d’entre elles sont mineures et ciblées ; ce sont les versions 2.1.40 et 2.1.41 qui constituent l’essentiel de ces mises à jour.
| Version | Modification du titre |
|---|---|
| 2.1.37 | Transfert du domaine vers reportedip.com — tous les liens, l’Endpoint API par défaut et les coordonnées ; la migration v14 remplace l’Endpoint par défaut enregistré, tandis que l’ancien domaine conserve une redirection permanente. |
| 2.1.38 | wp reportedip 2fa enable --method=totp génère et affiche désormais un mot de passe secret au lieu de signaler une méthode qui ne pourrait jamais être validée ; le système de vérification par e-mail/SMS envoie un code dès le premier envoi au lieu de rejeter la demande. |
| 2.1.39 | Les versions finales intègrent à nouveau les ensembles de règles WAF fournis — qui avaient complètement disparu — ainsi que quatre Firewall Rules destinées à contrer la chaîne d’attaques XSS sur l’écran de Login lié à la vulnérabilité CVE-2026-64638. |
| 2.1.40 | Un agent utilisateur de type « crawler » dont l’identité ne peut être vérifiée ne bénéficie plus d’une exemption de « block-ladder », et les requêtes manifestement malveillantes entraînent la révocation immédiate de cette exemption. |
| 2.1.41 | Blocage des nœuds de sortie Tor, plages d’adresses source des proxys de confiance, widget de sécurité pour wp-admin, droit de veto « ne jamais bloquer » pour les infrastructures vérifiées, recherche d’adresses IP plus complète et compteurs de tentatives à l’abri des conflits de concurrence. |
Les nœuds de sortie Tor peuvent désormais être bloqués lors du Login
Les installations professionnelles disposent désormais d’un nouveau bouton d’activation/désactivation dans l’onglet « Protection » qui rejette les tentatives de Login provenant de nœuds de sortie Tor connus. La liste des nœuds de sortie est fournie sous la forme d’un nouvel ensemble de règles signé tor_exits via la Rule Sync régulière et est actualisée deux fois par jour côté serveur, ce qui lui permet de suivre le rythme des rotations des nœuds de sortie ; pour les adresses que la liste n’a pas encore répertoriées, la communauté isTor prend le relais.
Deux limites intentionnelles sont intégrées. Les blocages sont temporaires — 24 heures par défaut, réglables via le reportedip_hive_tor_block_hours filtre — et un blocage lié à Tor n’est jamais signalé à la communauté, car l’exploitation d’un nœud de sortie ne constitue pas une preuve d’abus. Ce commutateur sanctionne un comportement sur votre site, et non la participation au réseau Tor.
Les plages de sources de proxy de confiance comblent une faille liée au Spoofing d’en-tête
Si votre site est hébergé derrière Cloudflare ou un proxy inverse, Hive lit l’adresse du visiteur à partir d’un en-tête redirigé. Jusqu’à présent, toute personne se connectant directement à l’origine pouvait envoyer elle-même cet en-tête — et ainsi se faire passer pour une adresse figurant sur la liste Whitelist, ou masquer une adresse bloquée.
La version 2.1.41 ne prend en compte l’en-tête d’adresse IP de confiance que lorsque le pair qui se connecte correspond à l’une des adresses proxy que vous avez déclarées (une liste d’adresses IP/CIDR accessible sous Paramètres → Général). Une liste vide conserve le comportement précédent, ce qui garantit la compatibilité lors de la mise à jour. La même vérification de plage est intégrée au filtre pré-WordPress, qui applique désormais également l’exigence d’adresse publique aux en-têtes candidats — comblant ainsi un écart de parité avec le résolveur intégré à WordPress.
Le pare-feu a cessé de se fier aveuglément aux robots d’indexation
La version 2.1.40 corrige le problème le plus grave mis en évidence lors de cette exécution. La liste blanche du robot d’indexation contient 71 identifiants d’agent utilisateur, mais le bot_signatures jeu de règles ne fournit des règles de vérification que pour une poignée d’entre eux. Pour chaque token intermédiaire, le vérificateur renvoyait unmatched — et is_exempt_crawler() traitait tout ce qui n’était pas confirmé fake comme un résultat satisfaisant. Il suffisait donc de se faire passer pour GPTBot, PerplexityBot ou UptimeRobot pour échapper à l’échelle de blocage et éviter les signalements de la communauté. Sur un site de production, 47 blocages ont été ignorés en trois jours — tous concernant des requêtes testant /.env, /config.php.bak ou /ssl/server.key provenant d’une plage d’adresses cloud n’appartenant à aucun des identifiants de l’agent utilisateur revendiqués.
Une exemption nécessite désormais une règle qui envoie un véritable signal de vérification — un suffixe Reverse DNS ou une plage d’adresses IP officielle — ainsi qu’un verdict qui ne soit pas fake. Afin de garantir la pertinence de l’ensemble vérifiable pour les installations gratuites, la base de référence intégrée a été enrichie de Baiduspider, LinkedInBot et Amazonbot, tous vérifiables par Reverse DNS uniquement.
Deuxième volet de la correction : les requêtes manifestement malveillantes entraînent la révocation immédiate de l’exemption. Un déclenchement de Honeypot, un déclenchement de Decoy Path ou une correspondance WAF dans les groupes de règles de charge utile (traversée de chemin, sondage de fichier, injection de commande et PHP, webshell, Log4Shell, XXE, SSTI, NoSQL, CRLF, SSRF) entraîne désormais le retrait de l’exemption accordée au robot d’indexation et est consigné comme bot_exemption_denied. Les règles relatives à la SQL Injection et à la XSS conservent délibérément la hiérarchie habituelle : les termes de recherche et le contenu de l’éditeur déclenchent bien ces modèles, et un client recherchant un code produit ne doit pas se voir bloquer l’accès pour cette raison.
Ces mêmes groupes de Payloads utiles se déclenchent désormais dès le premier résultat positif, au lieu d’attendre le seuil par défaut de trois. Ce seuil a été défini pour qu’un False Positive ne coûte qu’une seule requête et rien de plus — mais le téléchargement d’un webshell ne présente aucun risque de False Positive justifiant une protection ; par conséquent, attendre ne faisait que donner une longueur d’avance au scanner. Filtrable via reportedip_hive_waf_immediate_block_groups.
2.1.39 Réintégrer les ensembles de règles groupés dans la version finale
Celle-ci mérite une confession sans détours. Le processus de mise en production a été mis en place includes, admin, assets, templates et languages — mais pas data, où se trouvent les quatre ensembles de règles de base. Dans une copie de version installée, Rule_Sync::load_baseline() n’a trouvé aucun fichier et a renvoyé un ensemble vide ; le pare-feu est donc revenu sans avoir inspecté quoi que ce soit ; les signatures de bots et la liste des domaines jetables étaient vides pour la même raison.
Les installations qui synchronisent des ensembles de règles depuis l’API n’ont pas été affectées, car un ensemble de règles stocké remplace la configuration de référence au lieu de fusionner avec celle-ci — ce qui explique précisément pourquoi ce problème est resté invisible : les installations connectées qui ont été examinées fonctionnaient correctement, tandis que les installations en mode local et non connectées exécutaient un pare-feu inactif. Le workflow de publication et la compilation locale effectuent désormais une mise en attente data et s’interrompent si l’une des quatre configurations de référence est absente de l’arborescence de préparation. Si vous utilisez Hive en mode « Local Shield », effectuez la mise à jour sans tarder.
Cette même version a ajouté quatre règles « Paranoia-Level-1 » visant à contrer la vulnérabilité CVE-2026-64638 (XSS2Shell), la chaîne d’attaques ciblant l’écran de connexion de WordPress publiée le 06/08/2026. Cette chaîne ne nécessite ni balise <script> ni gestionnaire d’événement — elle fait passer du HTML brut à travers un différentiel d’analyse des sanitiseurs et laisse un attribut id écraser une variable globale JavaScript. waf_xss_login_markup rejette toute valeur de login contenant un chevron (jamais légitime — sanitize_user() les supprime), waf_xss_tag_differential détecte la primitive de clobbering elle-même et couvre donc toute la classe de bug plutôt qu’un seul avis, et deux règles complémentaires ferment l’escalade Same-Origin-Method-Execution. Mesuré sur 12 variantes d’attaque et 34 requêtes légitimes : 12 bloquées, 0 faux positif. C’est de la défense en profondeur, pas un substitut au correctif — WordPress 7.0.3, ou la version corrigée de votre branche, reste requis.
Le Dashboard wp-admin affiche enfin ce que fait Hive
Un nouveau widget de sécurité (admin/class-dashboard-widget.php) affiche sur la page d’accueil de wp-admin les attaques bloquées au cours des 30 derniers jours, les blocages du jour, les adresses IP activement bloquées, les couches de protection activées et le score de détection, avec des liens directs vers le plugin. Sur Multisite, le widget apparaît sur le Dashboard du réseau et, pour les super-administrateurs, sur les Dashboard des sous-sites avec des chiffres à l’échelle du réseau.
Trois autres modifications mineures en matière de visibilité sont également introduites. Une barre d’état de l’API sur le Dashboard de sécurité résume en un coup d’œil l’état de la connexion, du quota (avec compte à rebours de réinitialisation) et de la Rate Limit, en s’appuyant uniquement sur des données mises en cache. L’affichage du quota quotidien reste à jour entre les exécutions cron grâce à la lecture des en-têtes X-RateLimit que l’API envoie déjà à chaque réponse. Et après une mise à jour, les pages des plugins affichent une bannière « Nouveautés » pouvant être masquée une seule fois et présentant les points forts de la version (includes/class-whats-new.php) — la fermeture est spécifique à chaque utilisateur, et la bannière ne bloque jamais l’affichage d’une page lorsque le flux est inaccessible.
Les adresses IP ont désormais le même statut que les autres éléments dans l’interface d’administration
Chaque adresse IP figurant dans les journaux, les tables « bloquées », « Whitelist » et « principaux attaquants » comporte désormais une fonction de copie, une recherche interne et un lien externe vers sa page de profil publique sur ReportedIP.com ; les principaux attaquants disposent désormais d’actions intégrées « Bloquer » / « Débloquer ». L’onglet « Recherche » a lui aussi été amélioré : il affiche désormais le FAI, l’ASN, le type d’utilisation, le domaine, le nombre de signalements distincts et la date du dernier signalement ; il signale les nœuds de sortie Tor et les infrastructures vérifiées par la communauté, et propose des actions rapides « Bloquer » / « Ajouter à la Whitelist » directement sur la fiche de résultat.
wp reportedip lookup(includes/class-lookup-cli.php) permet d’effectuer la même recherche dans WP-CLI avec une sortie au format table, JSON, CSV et YAML.- Une fonctionnalité « Ajouter mon IP » intégrée au formulaire de Whitelist permet d’ajouter votre adresse actuelle à la Whitelist en un seul clic. Pour les adresses IPv6, elle renseigne automatiquement le réseau /64, ce qui évite que les préfixes résidentiels à rotation n’empêchent leurs propriétaires d’accéder au site. Le blocage de votre propre adresse IP actuelle nécessite désormais une confirmation préalable.
- Le journal des événements dispose désormais d’un filtre par plage de dates, et l’action « Bloquer la ligne du journal » propose désormais de choisir une durée au lieu d’une durée fixe de 24 heures.
Les infrastructures vérifiées ne sont jamais bloquées — et les intégrateurs bénéficient d’un point d’ancrage stable
Lorsque le service de réputation classe une adresse comme « infrastructure contrôlée » — robots d’indexation des moteurs de recherche, principaux CDN, parcs de surveillance —, Hive ne génère plus de blocage local pour celle-ci, ni via le chemin de réputation ni via l’échelle de blocage automatique, et enregistre infrastructure_spared à la place. Les Reports continuent d’être envoyés : les blocages sont des conséquences, les Reports constituent des preuves.
Pour les intégrations Webhook, SIEM et Slack, il existe désormais un point de connexion unique et stable : reportedip_hive_threshold_exceeded il se déclenche à chaque détection confirmée par un capteur, quels que soient les paramètres de blocage automatique et de notification. L’action documentée reportedip_hive_report_queued existe désormais bel et bien (elle se déclenche une fois par rapport entrant dans la file d’attente de l’API), et la page de blocage a été reportedip_hive_access_denied d’un reportedip_hive_blocked_page_strings filtre permettant de remplacer le texte en White-label.
Corrections à connaître : titres de messages invisibles, compteurs de course, cache obsolète
La modification la plus visible concerne les e-mails de notification et de 2FA. La cellule d’en-tête ne conservait sa couleur que sous forme de dégradé CSS — GMX Webmail et Outlook pour Android linear-gradient(), ce qui laissait le texte de l’en-tête en blanc sur une cellule blanche et permettait aux filtres anti-spam d’attribuer un score élevé au message HTML_FONT_LOW_CONTRAST. L’en-tête et le bouton d’appel à l’action ont désormais un fond indigo uni (bgcolor attribut plus background-color) et conservent le dégradé à titre d’amélioration progressive ; le logo SVG intégré, que les deux clients affichaient sous forme d’artefacts parasites, a disparu. Signalé par Benjamin Grösch — merci.
- Compteurs de tentatives sécurisés contre les conflits de concurrence.
track_attempt()Il s’agit désormais d’une seule opération « upsert » atomique sur une clé unique(ip_address, attempt_type)(schéma v15, avec nettoyage des lignes en double) ; ainsi, les rafales parallèles d’échecs de Login ne peuvent plus entraîner de perte de comptage due à des conflits de concurrence de type « lecture puis mise à jour ». - Le délai de réinitialisation de la Rate Limit s’applique à chaque Endpoint. Une erreur 429 sur le chemin de rapport n’interrompt plus les requêtes de vérification de réputation, et ce chemin respecte désormais l’en-tête « Retry-After », qu’il ignorait auparavant.
- Le cache de réputation tient compte du niveau de détail et de vos propres rapports. Une entrée de cache non détaillée ne répond plus à une requête détaillée, et un rapport réussi invalide la réputation mise en cache au lieu de fournir des données datant de moins de 24 heures.
- Les plages CIDR sont acceptées dans le formulaire de blocage manuel : les couches d’application les prenaient en charge depuis la version 2.1.32, et la validation du formulaire est désormais conforme.
- Les paramètres spécifiques à WooCommerce apparaissent en gris lorsqu’il n’est pas installé ; ils sont accompagnés d’une note explicative à la place d’un bouton bascule qui ne sert à rien, et l’URL de contact de la page bloquée en mode Multisite fonctionne à nouveau à l’échelle du réseau.
- Accessibilité. Les anneaux de mise au point restent visibles en mode « Contraste élevé » de Windows ; les blocs de couleurs imposées et de mouvements réduits s’intègrent au système de conception de l’interface d’administration ; les boutons iconiques respectent les cibles tactiles de 40 px avec des pointeurs de grande taille ; les notifications AJAX sont signalées via une zone interactive discrète ; et environ 90 chaînes de code JavaScript de l’interface d’administration, auparavant codées en dur, sont désormais traduisibles.
Comment effectuer la mise à jour vers Hive 2.1.41
L’outil de vérification des mises à jour intégré interroge GitHub toutes les 12 heures ; pour récupérer la nouvelle version immédiatement, ouvrez Plugins → Vérifier les mises à jour. La configuration requise reste inchangée : WordPress 5.9+ et PHP 8.1+. Aucune migration manuelle n’est nécessaire : la procédure de mise à jour exécute automatiquement la migration v14 (réécriture d’un point de terminaison API par défaut stocké vers reportedip.com) et le schéma v15.