Hive 2.1.51 : Protection contre les inscriptions indésirables et restriction des accès pour WordPress
ReportedIP Hive 2.1.51, sorti le 9 septembre 2026, intègre cinq nouvelles protections, dont trois sont gratuites dans toutes les formules. Cette version comble également une faille du Hardening Mode qui existait depuis la version 2.0.8 et qui permettait aux Logins à la vitrine WooCommerce de lire les seuils assouplis lors d’une attaque coordonnée.
La mise à jour s’installe comme n’importe quelle autre version. Les sites qui utilisent le plan du site des utilisateurs de WordPress sont invités à lire d’abord la dernière section.
Nouveautés de Hive 2.1.51
| Fonctionnalité | Plan | Fonctionnalités |
|---|---|---|
| Défense de l’enregistrement | Gratuit, plus complet dans la version Professional | Noms d’utilisateur interdits, règles relatives aux adresses e-mail, limite du nombre d’inscriptions par adresse IP, blocage des noms d’utilisateur inconnus |
| Commutateurs de verrouillage d’accès | Gratuit | Désactive la REST API, XML-RPC, les flux, l’accès « guest » à wp-admin, l’utilisation de PHP dans le dossier « uploads » et les empreintes de version |
| Registre d’état de préparation du système | Gratuit | Douze détecteurs destinés à repérer les défaillances silencieuses des différents éléments d’un dispositif |
| Blocage des comptes et sessions | Business | Bloque un compte sans le supprimer, répertorie et met fin aux sessions actives |
| Déclencheurs adaptatifs à deux facteurs | Professional | Sept règles de passage à un niveau supérieur par rôle, en fonction du nombre de nouveaux pays, adresses IP, réseaux, appareils ou sessions |
La protection des inscriptions couvre toutes les surfaces d’inscription
Jusqu’à la version 2.1.51, le capteur d’enregistrement n’effectuait qu’une seule tâche : il vérifiait si le domaine de l’adresse e-mail figurait dans une liste d’adresses éphémères. Il s’agit désormais d’un ensemble de règles, implémenté dans class-registration-guard.php avec quinze options associées.
- Les noms d’utilisateur interdits s’ajoutent à une liste de base intégrée comprenant dix noms de rôles ; ainsi,
admin,administrator,rootainsi que leurs variantes sont refusés sans aucune configuration. - Règles d’autorisation ou de blocage des e-mails, évaluées en parallèle de la liste des adresses temporaires. Les relais de confidentialité tels que « Hide My Email » d’Apple et « Firefox Relay » sont autorisés par défaut.
- Une Rate Limit pour le taux d’inscription par adresse IP : trois inscriptions toutes les 60 minutes par défaut. Cette période est plafonnée à 60 minutes, car le compteur de tentatives partagé se réinitialise toutes les heures.
- Un blocage par option d’activation pour les tentatives de connexion avec des noms d’utilisateur inexistants, ce qui correspond à ce que génèrent en masse les attaques par « Credential Stuffing ».
Ces règles s’appliquent au formulaire d’inscription de WordPress, à WooCommerce, aux inscriptions sur les sites Multisite et aux utilisateurs créés par programmation ; ainsi, un thème ou un plugin qui appelle wp_insert_user() ne peut pas les contourner. Dix entrées simples par liste sont gratuites sur tous les forfaits. La formule Professional supprime cette limite, accepte /regex/ les modèles et ajoute l’inscription par liste blanche, grâce à laquelle les comptes ne peuvent être créés qu’à partir des plages d’adresses IP répertoriées et nulle part ailleurs. La liste complète des options figure dans la documentation relative aux règles d’inscription.
Le verrouillage d’accès désactive les fonctionnalités que le site n’utilise pas
La plupart des installations WordPress intègrent des interfaces que leurs propriétaires n’utilisent jamais. Une nouvelle section de la page « Pare-feu » permet de les désactiver ; cette fonctionnalité est gratuite sur tous les forfaits et toutes les options sont désactivées par défaut :
- La REST API destinée aux visiteurs non connectés, ou à toute personne n’appartenant pas à un ensemble donné de rôles et d’espaces de noms.
- XML-RPC et les pingbacks.
- Flux.
- L’espace d’administration destiné aux visiteurs non connectés.
- Exécution de scripts PHP dans le dossier « uploads », enregistrés dans le dossier « uploads »
.htaccesssur Apache. Pour les serveurs nginx et inconnus, récupérez l’extrait de code à coller. - Les identifiants de version dans le code source de la page.
Six de ces éléments ont été intégrés au score de renforcement de la sécurité, et les pondérations existantes ont été revues à la baisse afin que le total reste égal à 100. Les scores varient de quelques points après la mise à jour, sans qu’aucun paramètre n’ait été modifié. Détails : Commutateurs de verrouillage d’accès.
Douze détecteurs pour les pannes que personne ne remarque
Un plugin de sécurité qui a cessé de fonctionner sans que l’on s’en aperçoive est pire que s’il n’existait pas, car le Dashboard continue d’afficher un état normal. Le nouveau registre de préparation surveille douze conditions : une file d’attente de garde pré-WordPress non accessible en écriture, un cron bloqué ou désactivé, un Trusted Proxy Header configuré sans plages de proxy, un schéma de base de données obsolète, une couche communautaire dégradée, des quotas de Mail Relay ou de SMS Relay épuisés, une distribution de courrier défaillante, une extension de chiffrement manquante et une file d’attente de Reports qui ne cesse de s’allonger.
Les problèmes en cours s’affichent sur la page « État du système » avec leur niveau de gravité, leur date d’apparition, un lien vers le paramètre concerné et un lien vers la documentation. Les avertissements et les recommandations peuvent être ignorés pendant sept jours, contrairement aux problèmes critiques. Le widget du Dashboard affiche le nombre de problèmes et wp reportedip status les indique dans un nouveau issues champ. Voir « État de préparation du système ».
Bloquer un compte sans le supprimer
Dans la formule Business, il est désormais possible de bloquer un compte depuis sa page de profil, depuis la liste des utilisateurs ou à l’aide de wp reportedip user block. Un compte bloqué conserve ses publications, ses commandes et ses médias, mais ne peut plus se connecter, ni authentifier un mot de passe d’application, ni procéder à une réinitialisation de mot de passe. Toutes ses sessions et tous ses Trusted Devices sont supprimés dès que le blocage est activé.
L’écran associé, accessible sous « Utilisateurs », « Sessions », répertorie toutes les sessions actives en indiquant l’utilisateur, l’heure de connexion, l’heure d’expiration, l’adresse IP et l’appareil, et permet de mettre fin à une seule session ou à toutes les sessions d’un utilisateur. Il n’est jamais possible de mettre fin à votre propre session en cours à partir de cette liste. Les blocages restent en vigueur et peuvent toujours être levés, même après l’expiration d’un abonnement ; ainsi, une licence expirée ne peut jamais empêcher un utilisateur d’accéder au système. Détails : Contrôle des comptes utilisateurs et sessions.
Déclencheurs adaptatifs à deux facteurs par rôle
Les Trusted Devices sont pratiques, mais ils constituent également une faille que les pirates cherchent à exploiter. Dans la version Professional, sept déclencheurs d’authentification renforcée peuvent désormais être activés par rôle : un nouveau pays, une nouvelle adresse IP, un nouveau réseau, un nouvel appareil, tous les N jours, toutes les N connexions et plus de N sessions simultanées. Un utilisateur correspondant à ces critères se voit demander à nouveau l’authentification à deux facteurs, même si le cookie du Trusted Device est présent.
Deux barrières de sécurité sont fournies avec le produit. Les utilisateurs dont la méthode n’est pas configurée ne sont jamais bloqués, et le rôle d’administrateur ne peut être activé qu’après qu’un administrateur a réussi une authentification à deux facteurs sur ce site. L’Allowlist IP de la 2FA et le reportedip_2fa_bypass filtre continuent de contourner les déclencheurs. Voir « Déclencheurs adaptatifs de renforcement de la sécurité ».
The hardening mode gap that remontait à la version 2.0.8
The Hardening Mode strengthens the failure threshold for Login on a network-wide scale for one hour when a coordinated attack is detected. Deux capteurs n’ont jamais détecté ces valeurs renforcées : le moniteur de connexion WooCommerce, qui couvre « Mon compte » et le processus de paiement classique, ainsi que le moniteur de mot de passe d’application. Tous deux ont continué à lire la configuration allégée, si bien qu’un botnet ciblant les formulaires de la vitrine a pu mener à bien une attaque que le formulaire de connexion aurait normalement bloquée.
Cette faille remonte à la version 2.0.8, lorsque le Hardening Mode a été intégré pour la première fois. Les sites ne disposant ni de WooCommerce ni de mots de passe d’application n’ont jamais été affectés. Les deux moniteurs font désormais passer leurs seuils par le même dispositif de limitation que wp-login, tout comme la simulation de seuil côté administration, et un test de parité au niveau du code source fait échouer la compilation si un futur capteur lit un seuil de Login sans passer par ce dispositif.
Une norme de configuration : 169 options, dont 71 accessibles à distance
Soixante-dix options se trouvaient en dehors du registre des paramètres, ce qui signifiait que MainWP et la flotte cloud ne pouvaient pas les gérer et que l’exportation JSON ne les incluait pas : les en-têtes de sécurité, la paire proxy de confiance, le mot de passe d’application et les limites REST, la fenêtre d’anomalie géographique, le moniteur de connexion WooCommerce, la sonde Hide Login, la politique de mot de passe, les paramètres de mise en cache et de file d’attente des rapports, ainsi que le badge de pied de page. Toutes ces options figurent désormais dans le registre, avec un seul module de nettoyage au lieu de plusieurs.
Il convient de noter trois conséquences. Les 169 options sont désormais toutes accompagnées d’une description d’une phrase ; ainsi, MainWP et la flotte affichent désormais du texte réel au lieu d’une simple étiquette. Le catalogue d’exportation est dérivé du registre plutôt que d’être géré séparément, car les deux s’étaient écartés de cinquante-cinq clés. Enfin, un fichier de paramètres importé ne peut plus écrire quoi que ce soit au-delà du filtre de sécurité : l’ancien chemin d’accès brut a disparu, ce qui était particulièrement important pour l’en-tête « IP client de confiance », où une valeur arbitraire est la condition préalable pour effectuer du Spoofing simultanément sur tous les capteurs, la Whitelist et la liste noire.
Aucune clé d’option n’ayant été modifiée, les politiques de flotte enregistrées et les règles de remplacement par site restent inchangées après la mise à jour. Les deux Dashboards nécessitent un rechargement du schéma pour afficher le nouveau regroupement.
Avant la mise à jour : le plan du site utilisateur disparaît
Un changement va surprendre les utilisateurs. wp-sitemap-users-1.xml n’existe plus lorsque le blocage de l’User Enumeration est activé, et cette option est activée par défaut ; la plupart des sites perdent donc ce fichier avec cette mise à jour. C’est un choix délibéré : cette même protection bloque déjà ?author= ainsi que la route REST des utilisateurs, et le plan du site était la seule liste de noms d’utilisateurs encore publiée sur le site. Les moteurs de recherche n’en ont pas besoin, et les pages d’archives des auteurs restent explorables si vous les gardez publiques sous « Protection » et « Détection ».
Version 2.1.51
La Full Edition interroge GitHub Releases toutes les 12 heures ; la mise à jour apparaît donc automatiquement sur la page « Plugins ». Pour l’obtenir immédiatement, téléchargez le fichier ZIP correspondant à la version 2.1.51 sur GitHub et remplacez l’installation existante. Les migrations s’exécutent de manière idempotente lors de l’activation ; le schéma de la base de données est à la version 16.
- Documentation complète du plugin, comprenant les douze détecteurs de disponibilité et la référence WP-CLI
- Les formules et ce que chaque niveau permet de débloquer, si vous hésitez entre la formule « Professional » et la formule « Business »