ReportedIP Hive 2.1.49 : audit de sécurité, standard de réglages et gestion de parc

27 août 2026 Mise à jour 1 septembre 2026 Patrick Schlesinger

Huit versions sont sorties entre le 14 et le 26 août 2026. La série commence par une version de sécurité qui a fermé trois contournements démontrés dans le pare-feu et dans la couche 2FA, et se termine par la gestion de parc : une politique de sécurité, appliquée à chaque site que vous exploitez, depuis MainWP ou depuis votre compte reportedip.com.

Ce qui a changé entre Hive 2.1.41 et 2.1.49

2.1.44 a fermé neuf constats de sécurité, dont trois contournements démontrés du contrôle de blocage, du pare-feu et de la connexion 2FA.
2.1.45 fait en sorte que chaque requête API identifie son installation comme le font les vérifications de mise à jour de wordpress.org, et a ajouté au tableau de bord une carte des domaines sous licence.
2.1.46 a rétabli les mises à jour de l’extension pour les tableaux de bord de gestion à distance, aveugles aux mises à jour de Hive depuis la 2.1.32.
2.1.47 introduit le registre des réglages et un protocole versionné de réglages à distance, afin qu’un tableau de bord puisse lire et appliquer les réglages de Hive avec une validation par clé.
2.1.48 a ajouté la gestion de parc dans le cloud pour Business, un transport signé en Ed25519 qui permet à reportedip.com d’appliquer des politiques à vos sites.
2.1.49 a durci ce point d’accès pour qu’un appelant non authentifié ne puisse plus savoir si un site a activé la fonction.

Tout ce qui suit se trouve dans l’extension gratuite, sauf mention contraire. Le moteur de protection reste gratuit, comme toujours.

La 2.1.44 a fermé trois contournements démontrés sur un site en production

Cette version est issue d’un audit complet du chemin des requêtes. Trois constats n’avaient rien de théorique. Chacun a été reproduit sur une installation en fonctionnement avant que le correctif ne soit intégré.

admin-ajax.php se trouvait hors du contrôle de blocage

Le contrôle des adresses IP et le pare-feu s’exécutaient tous deux sur init, mais admin-ajax.php était traité comme une requête d’administration et ignoré. Une adresse bloquée pouvait continuer d’appeler n’importe quelle action AJAX publique, et les extensions qui exposent de la logique via AJAX restaient accessibles alors que la même adresse était exclue du site public. Les deux couches inspectent désormais le trafic admin-ajax.

Une exception de pare-feu pouvait masquer toutes les règles suivantes

Les exceptions servent à exempter une seule règle pour un seul chemin. Une portée mal formée empêchait le moteur d’évaluer les règles suivantes : une seule entrée erronée désactivait donc silencieusement une partie du jeu de règles. La correspondance des exceptions est maintenant limitée à chaque règle et ne peut plus interrompre l’évaluation.

Des sondes encodées en pourcentage passaient devant trois capteurs

Le détecteur de scan, la protection contre l’énumération des comptes et la sonde de connexion masquée comparaient tous les chemins après sanitize_text_field(), qui laisse les échappements en pourcentage intacts. Une requête vers %2E%2E%2Fwp-config.php ne correspondait donc pas à la liste du pot de miel. La comparaison des chemins se fait désormais sur la valeur décodée.

Six autres constats dans la même version

Une méthode 2FA transmise n’était jamais vérifiée face aux facteurs réellement enregistrés par l’utilisateur. Une connexion pouvait désigner une méthode que le compte n’avait jamais configurée.
Les codes TOTP n’étaient pas à usage unique. Un code intercepté restait valable pendant le reste de sa fenêtre de 30 secondes.
Les deux routes REST publiques de la 2FA se terminent par wp_set_auth_cookie() et acceptaient les appels d’origine croisée. Elles refusent désormais l’envoi d’un formulaire depuis une autre origine.
Les blocages et déblocages mettaient jusqu’à cinq minutes à s’appliquer, car la décision d’accès était mise en cache. Le cache est invalidé à chaque changement de blocage.
Un en-tête d’IP client configuré était accepté depuis n’importe quel pair. Les plages sources de proxy de confiance déterminent maintenant si cet en-tête est lu.
Un préfixe CIDR mal formé faisait correspondre la protection antérieure au démarrage de WordPress à toutes les adresses.

Si vous utilisez Hive sur un site avec des points d’accès AJAX publics ou derrière un proxy inverse, la 2.1.44 est la version à ne pas sauter.

Les tableaux de bord distants étaient aveugles aux mises à jour depuis la 2.1.32

Une optimisation de performance en 2.1.32 ignorait le vérificateur de mises à jour sur les requêtes du site public. MainWP, ManageWP et les outils comparables se synchronisent précisément par ces requêtes : ils n’ont donc jamais vu de nouvelle version de Hive et ne pouvaient ni la signaler ni l’installer. Les sites qui dépendaient d’un tableau de bord de gestion pour leurs mises à jour sont restés sur d’anciennes versions sans aucun avertissement.

La 2.1.46 exécute de nouveau le vérificateur dans tous les contextes de requête et active les mises à jour automatiques de WordPress pour l’extension. Une extension de sécurité incapable de se mettre à jour est un risque, ce n’est donc plus facultatif. Si votre parc semblait à jour entre la 2.1.32 et la 2.1.45, vérifiez maintenant la version installée.

Chaque requête indique désormais de quelle installation elle provient

Depuis la 2.1.45, chaque appel API transporte l’adresse du site ainsi que les versions de l’extension et de WordPress, dans le format utilisé depuis des années par les vérifications de mise à jour de wordpress.org. En multisite, l’adresse du réseau est envoyée une seule fois : un réseau compte donc pour un domaine et non pour un par sous-site.

Le tableau de bord de sécurité a reçu une carte des domaines sous licence, qui indique combien de domaines votre offre couvre et combien sont utilisés. Les sites retirés peuvent être libérés depuis l’espace client, et les domaines qui cessent de communiquer sont libérés automatiquement après 60 jours. Les services tiers ne reçoivent jamais cette identité. La vérification de mots de passe HIBP, en particulier, ne reçoit que le jeton produit et rien d’autre.

Un standard de réglages pour tous ceux qui écrivent

Les réglages de Hive étaient auparavant validés à quatre endroits différents. La page des réglages avait ses propres fonctions de nettoyage, l’assistant de configuration un deuxième jeu, l’import un troisième, et aucun n’existait en dehors de wp-admin. Une écriture à distance pouvait atteindre la base de données sans les contrôles qu’un envoi de formulaire aurait déclenchés.

La 2.1.47 a remplacé cela par un registre déclaratif unique. Chaque option gérée déclare une seule fois son type, sa plage, ses valeurs autorisées, l’offre requise et ses effets de bord. La page des réglages, l’assistant, l’import et tous les transports distants valident par la même chaîne, et le registre se charge dans tous les contextes de requête. Le rafraîchissement des règles de réécriture et les remises à zéro de cache se déclenchent désormais quel que soit l’écrivain qui a modifié la valeur, y compris WP-CLI.

Au-dessus se trouve un protocole versionné de réglages à distance. Un tableau de bord demande à un site son schéma de réglages, lit les valeurs actuelles et applique un lot. Chaque clé revient avec son propre résultat, si bien qu’une option liée à une offre est signalée comme ignorée au lieu de faire échouer l’ensemble. Le contrat est documenté dans le dépôt de l’extension et les deux tableaux de bord l’implémentent.

Gestion de parc : une politique pour tous vos sites

La 2.1.48 a transformé ce protocole en fonctionnalité. Définissez une politique de sécurité une fois, remplacez certains champs là où un site a besoin d’autre chose, puis déployez-la. Le tableau de bord gère 63 réglages répartis en sept groupes : seuils de détection, blocage et escalade, niveau du pare-feu, connexion masquée, politique 2FA, journalisation et conservation, notifications.

Chaque site transmet à chaque appel API une empreinte de ses réglages gérés. Modifiez quelque chose directement sur un site et il apparaît comme divergent jusqu’au prochain déploiement. Une vue comparative place la valeur cible à côté de la valeur réelle du site, récupérée en direct.

Deux façons de piloter cela. Le pont MainWP est intégré à Hive : un site connecté à votre tableau de bord MainWP est donc gérable sans extension enfant supplémentaire et sans extension payante. Le tableau de bord de parc de reportedip.com fait la même chose depuis votre compte, sous Domaines, et n’a besoin d’aucun MainWP. Celui-ci fait partie de l’offre Business.

Comment le transport cloud est sécurisé

Autoriser un service à écrire des réglages dans votre site n’est acceptable que si le site peut prouver qui le demande. Le transport est désactivé par défaut et chaque requête doit passer sept contrôles avant la moindre écriture.

Le propriétaire du site l’active. Sans cette bascule, le mode Community et une clé d’accès, toute requête est refusée.
Une limitation de débit par IP sur le site.
Une signature Ed25519 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 : une enveloppe adressée à un site est rejetée par tout autre site.
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é de plus. Une requête qui échoue à la vérification de signature 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 : scanner Internet ne révèle donc plus quels sites ont activé la gestion de parc. La raison réelle est consignée dans le journal de sécurité du site.

Petites corrections à connaître

L’activation réseau ne provoque plus d’erreur fatale en multisite lorsque la protection étendue est active.
Les connexions XML-RPC échouées avec mot de passe d’application comptaient double dans le seuil de force brute. Une tentative sur le réseau vaut désormais une tentative.
Le filtre des journaux connaît le type d’événement « App Password Failed ».
Les points forts de la version dans la bannière de mise à jour s’interrompaient en milieu de phrase lorsque les notes de version étaient longues.
Le bouton de remise à zéro des statistiques API du tableau de bord de sécurité ne faisait rien. Son gestionnaire n’était rattaché qu’à la page « System Status ».
Les pages d’administration ne défilent plus latéralement sur téléphone. Les tableaux défilent dans leur propre conteneur et les en-têtes de cartes passent à la ligne.

Comment passer à Hive 2.1.49

Les mises à jour arrivent par l’écran de mise à jour habituel de WordPress. Depuis la 2.1.46, les mises à jour automatiques sont activées pour l’extension : la plupart des installations sont déjà en 2.1.49 ou y arriveront dans la journée. Pour l’obtenir immédiatement, ouvrez la page des extensions et utilisez le lien de vérification des mises à jour, ou mettez à jour depuis votre tableau de bord de gestion.

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, et le réglage des proxys de confiance conserve son comportement antérieur tant que vous n’avez pas renseigné les plages sources. Si vous utilisiez une version comprise entre la 2.1.32 et la 2.1.45, vérifiez une fois la version installée à la main, car votre tableau de bord a pu annoncer un numéro obsolète.