Hive 2.1.51 : protection des inscriptions et verrouillage des accès pour WordPress

9 septembre 2026 Mise à jour 29 septembre 2026 Patrick Schlesinger

ReportedIP Hive 2.1.51 est sortie le 9 septembre 2026 avec cinq nouvelles protections, dont trois gratuites dans toutes les formules : des règles d’inscription, des interrupteurs de verrouillage des accès et un registre de l’état du système. La version a aussi fermé une faille du mode de durcissement, ouverte depuis la version 2.0.8 : pendant une attaque coordonnée, les connexions à la boutique WooCommerce lisaient encore les seuils assouplis.

La version actuelle est la 2.1.67. Les remarques ci-dessous indiquent où un menu ou un chiffre a changé depuis. Si votre site utilise le sitemap WordPress des utilisateurs, lisez la section qui lui est consacrée avant la mise à jour. L’interface de Hive est en anglais, les libellés sont donc cités tels quels.

Quoi de neuf dans Hive 2.1.51 ?

Fonction	Formule	Ce qu’elle fait
Règles d’inscription	Gratuite, étendue avec Professional	Noms d’utilisateur interdits, règles d’e-mail, limite d’inscriptions et blocage des noms d’utilisateur inconnus
Verrouillage des accès	Gratuite	Coupe l’API REST, XML-RPC, les flux, wp-admin pour les visiteurs, le PHP dans les uploads et les empreintes de version
Registre de l’état du système	Gratuite	Signale les parties d’une installation qui tombent en panne sans bruit
Déclencheurs adaptatifs de double authentification	Professional	Sept règles par rôle qui redemandent le second facteur
Blocage de comptes et sessions	Business	Bloque un compte sans le supprimer et met fin à ses sessions

Le moteur de protection reste gratuit. Depuis la version 2.1.56, les anciennes pages Settings et Firewall ne forment plus qu’une page, ReportedIP Hive → Protection, où chaque domaine est une carte : Registration Rules, Access Lockdown, Adaptive Step-Up et les autres citées plus bas.

Comment Hive bloque-t-il les fausses inscriptions WordPress ?

Jusqu’à la 2.1.51, le capteur d’inscription ne faisait qu’une chose : il comparait le domaine de l’adresse e-mail à une liste de services de mail jetables. Depuis la 2.1.51, c’est un ensemble de règles en quatre parties :

Des noms d’utilisateur interdits en plus d’une liste intégrée de dix noms système : admin, administrator, root, sysadmin, superadmin, webmaster, hostmaster, postmaster, support et moderator. Ils sont refusés sans aucune configuration et ne comptent pas dans la limite gratuite d’entrées.
Des règles d’e-mail pour autoriser ou bloquer, vérifiées en même temps que la liste des mails jetables. Les relais de confidentialité comme « Masquer mon adresse e-mail » d’Apple et Firefox Relay passent par défaut.
Une limite d’inscriptions par adresse IP, qui refuse les inscriptions suivantes dès qu’une adresse crée des comptes plus vite qu’une personne ne le ferait.
Un blocage facultatif des tentatives de connexion avec des noms d’utilisateur qui n’existent pas, le motif que les campagnes de credential stuffing produisent en masse.

Les règles s’appliquent au formulaire d’inscription WordPress, à WooCommerce, aux inscriptions Multisite et aux utilisateurs créés par du code : un thème ou une extension qui appelle wp_insert_user() ne passe pas à côté. Dix entrées simples par liste sont gratuites dans toutes les formules. Professional supprime la limite, accepte les motifs /regex/ et ajoute l’inscription sur liste d’autorisation seulement, où les comptes ne peuvent être créés que depuis des plages IP listées. Toutes les options figurent dans la documentation des règles d’inscription.

Les bots qui remplissent le formulaire d’inscription lui-même sont un autre problème. Hive les traite avec la protection des formulaires décrite dans le guide du honeypot de formulaire.

Quelles interfaces WordPress le verrouillage des accès peut-il couper ?

La plupart des installations WordPress exposent des interfaces que leurs propriétaires n’utilisent jamais. Les interrupteurs de verrouillage des accès les coupent, gratuitement dans toutes les formules, et chaque interrupteur est désactivé par défaut :

L’API REST pour les visiteurs non connectés, ou pour tous ceux qui sont hors d’un ensemble choisi de rôles et d’espaces de noms.
XML-RPC avec les pingbacks.
Les flux RSS et Atom.
L’espace d’administration pour les visiteurs non connectés.
L’exécution de PHP dans le dossier des uploads, inscrite dans le .htaccess de ce dossier sous Apache. nginx et les serveurs inconnus reçoivent un extrait à coller.
Les empreintes de version dans le code source de la page.

Dans la 2.1.51, les interrupteurs se trouvaient dans une section de la page Firewall. Depuis la 2.1.56, ils forment la carte Access Lockdown sous ReportedIP Hive → Protection. Six d’entre eux comptent dans le score de durcissement, et les anciens poids ont été abaissés pour que le total reste à 100. Détails : interrupteurs de verrouillage.

Comment Hive remarque-t-il que la protection ne fonctionne plus ?

Une extension de sécurité qui a cessé de fonctionner sans bruit est pire que rien, car le tableau de bord a toujours l’air en bonne santé. Le registre de l’état du système a démarré avec 12 détecteurs : une file d’attente non inscriptible pour la garde en amont de WordPress, un cron bloqué ou désactivé, un en-tête de proxy de confiance sans plages de proxy, un schéma de base de données obsolète, une connexion dégradée au réseau communautaire, des quotas épuisés sur le relais mail ou SMS, des envois de mail en échec, une extension de chiffrement manquante et une file de signalements qui grossit.

Les problèmes ouverts apparaissent sur la page System Status avec leur gravité, le moment de leur première apparition, un lien vers le réglage concerné et un lien vers la documentation. Les avertissements et les conseils peuvent être masqués pendant sept jours, les problèmes critiques non. wp reportedip status les liste dans son champ issues. Avec la 2.1.67, le registre compte 19 détecteurs : la 2.1.56 a ajouté six vérifications de conseil, par exemple pour un administrateur sans second facteur, et la 2.1.58 une pour les extensions de formulaire dont la protection est disponible mais désactivée. Voir les vérifications de l’état du système.

Comment bloquer un utilisateur WordPress sans supprimer son compte ?

Avec la formule Business, un compte peut être bloqué depuis sa page de profil, depuis la liste des utilisateurs ou avec wp reportedip user block. Un compte bloqué conserve ses articles, ses commandes et ses médias, mais ne peut plus se connecter, utiliser un mot de passe d’application ni terminer une réinitialisation du mot de passe. Chaque session et chaque appareil de confiance du compte prennent fin au moment où le blocage est posé.

La page Sessions, sous Utilisateurs, liste chaque session active avec l’utilisateur, l’heure de connexion, l’expiration, l’adresse IP et l’appareil, et met fin à une session ou à toutes les sessions d’un utilisateur. Votre propre session en cours ne peut pas être fermée depuis cette liste. Les blocages restent en vigueur et peuvent toujours être levés, même après l’expiration d’une formule, si bien qu’une licence expirée ne laisse jamais personne enfermé dehors. Détails : contrôle des comptes utilisateurs.

Quand Hive redemande-t-il le second facteur ?

Les appareils de confiance sont pratiques, et c’est aussi la faille que vise un attaquant. Avec Professional, sept déclencheurs peuvent être définis 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 concerné doit fournir à nouveau le second facteur, même avec le cookie d’un appareil de confiance.

Deux garde-fous l’accompagnent. Les utilisateurs sans méthode configurée ne sont jamais bloqués, et le rôle administrateur ne peut être activé qu’après qu’un administrateur a réussi une vérification à deux facteurs sur ce site. La liste d’autorisation IP de la 2FA et le filtre reportedip_2fa_bypass contournent toujours les déclencheurs. Les réglages se trouvent dans la carte Adaptive Step-Up de la page Protection. Voir les déclencheurs adaptatifs.

Quelle faille du mode de durcissement la 2.1.51 a-t-elle fermée ?

Le mode de durcissement, disponible à partir de Professional, resserre pour une durée limitée et sur tout le réseau le seuil des connexions échouées lorsqu’une attaque coordonnée est détectée. Deux capteurs ne voyaient jamais les valeurs plus strictes : le moniteur de connexion WooCommerce, qui couvre Mon compte et le checkout classique, et le moniteur des mots de passe d’application. Un botnet qui visait les formulaires de la boutique continuait face à la configuration assouplie.

La faille remontait à la 2.0.8, la version qui a introduit le mode de durcissement. Les sites sans WooCommerce et sans mots de passe d’application n’ont jamais été concernés. Les deux moniteurs lisent désormais leurs seuils à travers la même limite que wp-login, et un test automatique fait échouer le build si un futur capteur lit un seuil de connexion sans elle.

Qu’est-ce qui a changé dans les réglages avec la 2.1.51 ?

Soixante-dix options vivaient hors du registre des réglages. MainWP et la gestion de parc dans le cloud ne pouvaient donc pas les gérer, et l’export JSON les omettait. Parmi elles figuraient les en-têtes de sécurité, la paire en-tête et plages de proxy, la politique de mots de passe et le badge de pied de page. Toutes sont désormais des options du registre, contrôlées par une seule routine de nettoyage au lieu de plusieurs.

Les 169 options de la 2.1.51 portent toutes une description d’une phrase, si bien que MainWP et le parc affichent un vrai texte au lieu d’un simple libellé. Un fichier de réglages importé ne peut plus rien écrire en contournant cette routine. C’était surtout important pour l’en-tête de l’IP client, où une valeur arbitraire permettrait à un attaquant de falsifier l’adresse sur laquelle s’appuient chaque capteur, la liste blanche et la liste de blocage. Aucune clé d’option n’a changé, les politiques de parc enregistrées ont donc survécu à la mise à jour.

Pourquoi le sitemap WordPress des utilisateurs a-t-il disparu ?

Depuis la 2.1.51, wp-sitemap-users-1.xml n’existe plus tant que Block user enumeration est activé, et cette option est activée par défaut. Le même réglage bloquait déjà ?author= et la route REST des utilisateurs, et le sitemap était la dernière liste publiée de noms d’utilisateur du site. Les moteurs de recherche n’en ont pas besoin. Si votre thème utilise les pages d’auteur, activez Keep author archives reachable dans la carte Detection & Thresholds de la page Protection.

Comment obtenir ces changements aujourd’hui ?

Toutes les versions depuis la 2.1.51 les contiennent, et Hive installe lui-même ses mises à jour via les mises à jour automatiques de WordPress. Pour récupérer tout de suite la version actuelle, ouvrez Extensions et recherchez les mises à jour sur la ligne de Hive. Pour une nouvelle installation, téléchargez le ZIP actuel depuis la page produit de Hive. Les fonctions de chaque formule figurent sur la page des tarifs.

Pour comprendre pourquoi les noms d’utilisateur comptent pour un attaquant, l’aide-mémoire OWASP sur l’authentification traite de l’énumération des comptes et des messages d’erreur neutres.

Questions fréquentes

Les règles d’inscription sont-elles gratuites ?

Les règles d’inscription sont gratuites dans toutes les formules, avec dix entrées simples par liste, plus la liste intégrée de dix noms système, la limite d’inscriptions et le blocage des noms d’utilisateur inconnus. Professional supprime la limite d’entrées, accepte les expressions régulières et ajoute l’inscription depuis des plages IP autorisées uniquement. Rien de ce qui était gratuit avant la 2.1.51 n’est passé dans une formule payante.

Bloquer un utilisateur supprime-t-il son contenu ?

Le blocage conserve le compte et tout ce qui lui appartient : articles, commandes WooCommerce et médias restent en place. L’utilisateur ne peut plus se connecter, utiliser un mot de passe d’application ni réinitialiser son mot de passe, et toutes ses sessions prennent fin aussitôt. Bloquer demande la formule Business, lever un blocage fonctionne dans toutes les formules.

Le verrouillage des accès peut-il gêner une extension ou une application ?

Un interrupteur peut gêner une extension ou une application qui dépend de l’interface qu’il ferme. L’application mobile WordPress et certains services de sauvegarde utilisent XML-RPC ou l’API REST, et les thèmes headless lisent l’API REST. Chaque interrupteur est désactivé par défaut : vérifiez quels services utilisent une interface avant de la couper.