ReportedIP Hive 2.1.49 : audit de sécurité, standard de réglages et gestion de parc
Hive 2.1.49 a clos une série de huit versions publiées entre le 14 et le 26 août 2026 : un audit de sécurité avec neuf constats corrigés, un standard de réglages unique pour chaque voie d’écriture et une gestion de parc qui applique une même politique de sécurité à tous vos sites. La version actuelle est la 2.1.67, et les remarques ci-dessous indiquent où un menu ou une attribution de formule a changé depuis. L’interface de Hive est en anglais, les libellés sont donc cités en anglais.
Qu’est-ce qui a changé entre Hive 2.1.41 et 2.1.49 ?
- 2.1.42 ne compte plus deux fois les connexions XML-RPC échouées par mot de passe d’application.
- 2.1.44 a corrigé neuf constats issus d’un audit de sécurité de tout le code, dont quatre sur le chemin qu’une requête emprunte pour passer le contrôle de blocage et le pare-feu.
- 2.1.45 fait identifier son installation à chaque requête API, comme le font les vérifications de mises à jour de wordpress.org, et a ajouté une carte « Licensed domains ».
- 2.1.46 a rétabli les mises à jour de l’extension dans les tableaux de bord de gestion à distance, qui ne voyaient plus les mises à jour de Hive depuis la 2.1.32.
- 2.1.47 a introduit le registre des réglages et un protocole versionné de réglages à distance.
- 2.1.48 a ajouté la gestion de parc dans le cloud pour la formule Business, un transport signé Ed25519 par lequel reportedip.com applique des politiques à vos sites.
- 2.1.49 a durci ce point d’accès pour qu’un appelant non authentifié ne puisse pas savoir si un site l’a activé.
Tout ceci figure dans l’extension gratuite, sauf si une ligne nomme une formule. Le moteur de protection reste gratuit. La version précédant cette série a apporté le blocage des nœuds de sortie Tor.
Quelles failles de sécurité Hive 2.1.44 a-t-il corrigées ?
La 2.1.44 est issue d’un audit de sécurité et d’exactitude de tout le code. Chaque constat a été vérifié sur le code en fonctionnement avant d’être modifié, et chaque correction s’accompagne d’un test de non-régression.
admin-ajax.php échappait au contrôle de blocage
Le contrôle IP s’effaçait devant chaque requête AJAX, et le pare-feu ignorait tout ce que WordPress traite comme une requête d’administration. Cela inclut admin-ajax.php et admin-post.php, qui servent chaque action AJAX publique enregistrée par un site. Une adresse bloquée gardait un accès complet, et le corps de ses requêtes n’était pas inspecté. Désormais, seul WP-Cron reste exempté, les requêtes anonymes vers les deux points d’accès sont inspectées, et les appelants AJAX reçoivent une erreur JSON au lieu de la page de blocage.
Une exception du pare-feu pouvait masquer toutes les règles suivantes
Le moteur s’arrêtait à la première règle correspondante et ne la confrontait qu’ensuite aux exceptions. Une requête qui ajoutait un fragment correspondant à une règle exemptée faisait passer sa vraie charge utile à travers toute l’analyse. La vérification des exceptions se fait maintenant dans la boucle, et l’analyse continue après une correspondance exemptée.
Des requêtes encodées en pourcent contournaient trois capteurs
La fonction WordPress sanitize_text_field() supprime chaque séquence encodée en pourcent. Une requête vers /wp-login%2Ephp arrivait donc sous la forme /wp-loginphp au contrôle de la connexion masquée, et le formulaire de connexion était servi malgré tout. La connexion masquée, le détecteur de scans et les chemins leurres lisent maintenant l’adresse brute de la requête et la décodent une fois. Le pare-feu utilise le même résolveur de chemin.
Six autres constats dans la même version
- Un préfixe CIDR mal formé faisait correspondre la protection en amont de WordPress à toutes les adresses : une seule ligne de liste blanche cassée aurait laissé passer chaque requête.
- Une méthode 2FA soumise n’était jamais confrontée à la politique du site. Une méthode que la politique n’autorisait plus connectait quand même l’utilisateur si son secret était resté enregistré.
- Les codes TOTP n’étaient pas à usage unique. Un code intercepté en transit restait valable pour le reste de son pas de temps. Hive enregistre désormais le pas accepté, comme le recommande la RFC 6238.
- Les deux routes REST publiques de la 2FA se terminent par
wp_set_auth_cookie()et acceptaient les appels d’autres origines. Elles les refusent désormais. - Les blocages et déblocages mettaient jusqu’à cinq minutes à s’appliquer, car le verdict d’accès restait en cache. Chaque modification de blocage le vide désormais.
- Un en-tête d’IP client approuvé sans sources de proxy est accepté de n’importe quel pair. Ce comportement reste pour des raisons de compatibilité, mais l’enregistrement de cette combinaison affiche désormais un avertissement.
Si votre site est derrière un proxy inverse ou un CDN, renseignez le champ « Trusted Proxy Sources ». Depuis la 2.1.56, il se trouve dans la carte de connexion sous ReportedIP Hive → Community.
Pourquoi MainWP n’affichait-il plus les mises à jour de Hive ?
À partir de la 2.1.32, le vérificateur de mises à jour n’était construit que dans les requêtes wp-admin, cron et WP-CLI. MainWP, ManageWP et les tableaux de bord comparables se synchronisent par des requêtes frontales et ne pouvaient donc ni lister ni installer une nouvelle version de Hive. Les sites qui comptaient sur un tableau de bord de gestion pour leurs mises à jour restaient sur d’anciennes versions sans aucun avertissement.
La 2.1.46 construit à nouveau le vérificateur à chaque requête et active les mises à jour automatiques de WordPress pour l’extension. Une extension de sécurité en retard sur ses propres correctifs ne protège personne. Les sites qui doivent figer une version rétablissent le contrôle manuel avec le filtre reportedip_hive_auto_update.
Comment Hive identifie-t-il son installation ?
Depuis la 2.1.45, chaque requête vers reportedip.com transmet l’adresse du site, la version de l’extension et la version de WordPress, au format User-Agent des vérifications de mises à jour de wordpress.org. En multisite, l’adresse du réseau est envoyée : un réseau compte donc pour un seul domaine sous licence. Les données des visiteurs restent limitées à l’adresse IP et au type d’événement des menaces détectées. La vérification des mots de passe auprès de Have I Been Pwned ne reçoit que le nom du produit et sa version.
La même version a ajouté la carte « Licensed domains », qui montre combien de domaines votre formule couvre et combien sont utilisés. Depuis la 2.1.54, la carte se trouve sur la page Community. Vous libérez les sites retirés dans votre compte reportedip.com sous Domaines, et un domaine qui ne se manifeste plus est libéré automatiquement au bout de 60 jours.
Qu’est-ce que le registre des réglages de Hive ?
Avant la 2.1.47, trois endroits validaient séparément les réglages de Hive : la page de réglages, l’assistant de configuration et l’import. Une voie d’écriture hors de wp-admin, comme un tableau de bord distant ou WP-CLI, n’avait aucune validation.
La 2.1.47 les a remplacés par un registre déclaratif unique. Chaque option gérée déclare une seule fois son type, sa plage, ses valeurs autorisées, la formule requise et ses effets de bord, et chaque voie d’écriture valide par ce registre. La régénération des règles de réécriture pour Hide Login et la 2FA en façade s’exécute désormais quelle que soit la voie qui a modifié la valeur. Le registre a survécu à l’assistant : depuis la 2.1.54, le guide du Quickstart décrit comment une recommandation adaptée à la formule est appliquée par ce registre, et depuis la 2.1.56 la page unique Protection enregistre chaque carte par le même pipeline.
Par-dessus se trouve un protocole versionné de réglages à distance. Un tableau de bord lit le schéma des réglages, lit les valeurs actuelles et applique un lot. Chaque clé renvoie son propre résultat : une option liée à une formule est signalée comme ignorée au lieu de faire échouer tout l’envoi.
Comment fonctionne la gestion de parc de Hive ?
La 2.1.48 a fait de ce protocole une fonction. Vous définissez une politique de sécurité une fois, vous remplacez des champs isolés là où un site a besoin d’autre chose, et vous l’envoyez. Au lancement, la politique couvrait 63 réglages répartis en sept groupes. Le registre a grandi à chaque version, et un site en 2.1.67 expose 190 réglages à la gestion de parc.
Chaque site connecté transmet à chaque appel API une empreinte de ses réglages gérés. Si vous modifiez une valeur directement sur un site, il apparaît comme divergent jusqu’au prochain envoi. Une vue de comparaison place la valeur cible à côté de la valeur réelle du site, lue en direct.
| Question | MainWP | Parc reportedip.com |
|---|---|---|
| Où gérer les politiques | Votre propre tableau de bord MainWP | Votre compte reportedip.com sous Domaines |
| Formule | Sans condition de formule | Business ou Enterprise |
| Interrupteur sur le site | Aucun | Interrupteur de gestion de parc dans le cloud |
| Authentification | Connexion MainWP Child | Requête signée Ed25519 |
Le pont MainWP est intégré à Hive : un site connecté par MainWP Child n’a besoin d’aucune extension supplémentaire. La documentation de l’intégration MainWP liste ce que le pont transmet. Le tableau de bord de parc de reportedip.com fonctionne sans MainWP et fait partie de la formule Business.
Pour autoriser le tableau de bord de parc, ouvrez ReportedIP Hive → Community et activez « Cloud fleet management via reportedip.com » dans la carte de connexion. Jusqu’à la 2.1.56, l’interrupteur se trouvait dans l’onglet General des réglages. Le site apparaît dans le tableau de bord avec sa prochaine requête API. La documentation du parc cloud détaille les prérequis, et le guide de sécurité multisite explique comment les réglages s’appliquent à un réseau.
Comment le transport cloud est sécurisé
Laisser un service écrire des réglages dans votre site n’est acceptable que si le site peut vérifier qui le demande. Le transport est désactivé par défaut, et chaque requête doit passer sept contrôles avant que quoi que ce soit ne soit écrit.
- Le propriétaire du site l’active. Sans l’interrupteur, le mode Community Network et une Community Access Key, chaque requête est refusée.
- Limitation de débit par IP sur le site.
- Une signature Ed25519 (RFC 8032) sur la charge utile exacte, vérifiée avec une clé publique fournie dans l’extension. La clé privée ne quitte jamais le service.
- Une fenêtre de fraîcheur de cinq minutes sur l’horodatage de la requête.
- Des identifiants de requête à usage unique, pour qu’une requête interceptée ne puisse pas être rejouée.
- Une liaison au destinataire : tout autre site rejette une enveloppe adressée à un site donné.
- Une preuve dérivée de la clé d’accès du site, qui lie la requête au compte propriétaire du site.
La 2.1.49 a ajouté une propriété. Une requête à la signature invalide et une requête vers un site qui n’a jamais activé la fonction reçoivent désormais la même erreur générique : un balayage d’Internet ne révèle donc plus quels sites utilisent la gestion de parc. Le site consigne la vraie raison dans son journal de sécurité.
Quelles corrections mineures la série contenait-elle ?
- L’activation de l’extension n’échoue plus par une erreur fatale lorsque Extended Protection est actif, ce qui touchait aussi l’activation réseau.
- Les connexions XML-RPC échouées par mot de passe d’application comptaient deux fois dans le seuil anti-force brute. Une tentative compte désormais une fois.
- Le filtre de type d’événement des journaux connaît App Password Failed.
- Les points forts de version dans la bannière de mise à jour ne s’arrêtent plus au milieu d’une phrase.
- Le bouton « Reset API statistics » ne faisait rien sur le Security Dashboard, car son gestionnaire n’était lié que sur la page System Status.
- Les pages d’administration ne défilent plus latéralement sur mobile. Les tableaux défilent dans leur propre conteneur, et les en-têtes de cartes passent à la ligne.
Comment obtenir ces changements aujourd’hui ?
Chaque version depuis la 2.1.49 les contient, et depuis la 2.1.46 Hive installe ses mises à jour lui-même via les mises à jour automatiques de WordPress. Pour récupérer tout de suite la version actuelle, ouvrez Extensions et cliquez sur « Vérifier les mises à jour » dans la ligne de Hive, ou mettez à jour depuis votre tableau de bord de gestion. Pour une nouvelle installation, téléchargez le ZIP actuel depuis la page produit de Hive.
Aucune modification de configuration n’est nécessaire. La gestion de parc dans le cloud reste désactivée jusqu’à ce que vous l’activiez site par site. Si un site a utilisé une version entre la 2.1.32 et la 2.1.45, vérifiez une fois à la main la version installée, car un tableau de bord de gestion a pu afficher un numéro périmé.
Questions fréquentes
Quelle formule faut-il pour la gestion de parc dans le cloud ?
La gestion de parc depuis reportedip.com nécessite la formule Business ou Enterprise, Hive 2.1.48 ou plus récent, le mode Community Network et une Community Access Key. Le propriétaire du site doit en plus activer l’interrupteur sur la page Community. Les réglages que la formule du site ne couvre pas sont ignorés lors d’un envoi, jamais imposés.
Pourquoi mon site n’apparaît-il pas dans le tableau de bord de parc ?
Presque toujours, l’interrupteur de gestion de parc dans le cloud est encore désactivé, comme par défaut. Activez-le sous ReportedIP Hive → Community, dans la carte de connexion. L’effet n’est pas immédiat : le site se signale avec sa prochaine requête API vers reportedip.com, et il doit fonctionner en mode Community Network.
Un scanner peut-il savoir si mon site utilise la gestion de parc ?
Depuis Hive 2.1.49, il ne le peut plus. Une requête vers un site sans la fonction et une requête à la signature invalide reçoivent la même erreur d’authentification générique, avec le statut HTTP 401. Le site écrit la vraie raison dans son propre journal de sécurité : vous voyez toujours les tentatives échouées, les tiers n’apprennent rien.