Hive 2.1.66 : une règle pour chaque formulaire

ReportedIP Hive 2.1.66 soumet chaque formulaire protégé à une seule règle : un bot qui remplit le champ leurre caché est refusé, bloqué et signalé dès sa première tentative, sur les 10 surfaces de formulaire couvertes par l’extension. Cette version clôt une série de quatre versions publiées les 23 et 24 septembre 2026, qui a ajouté Gravity Forms, WPForms et Forminator, lié la vérification par calcul à votre propre site et bloqué le spam de commentaires dès le premier verdict clair.

Mettez à jour depuis l’administration WordPress ou téléchargez le ZIP actuel sur la page produit de Hive. Le fonctionnement de la protection des formulaires est expliqué dans le guide du honeypot de formulaire ; cet article consigne ce qui a changé dans ces quatre versions. L’interface de Hive est en anglais, les libellés cités restent donc en anglais.

Qu’est-ce qui a changé entre Hive 2.1.62 et 2.1.66 ?

Quatre versions sont sorties en deux jours.

Version	Date	Changement principal
2.1.63	23 septembre 2026	Adaptateur Gravity Forms, Contact Form 7 dans toutes les formules, spam de commentaires bloqué sur un verdict clair, traversée de répertoires doublement encodée détectée par le pare-feu
2.1.64	23 septembre 2026	Vérification par calcul liée à une tâche signée et à usage unique émise par votre propre site
2.1.65	24 septembre 2026	Adaptateur WPForms, fuite de mails Elementor corrigée, inscriptions Ultimate Member réparées
2.1.66	24 septembre 2026	Adaptateur Forminator, une règle pour tous les formulaires, blocage dès la première tentative pour un champ leurre rempli

Quels formulaires Hive protège-t-il depuis la 2.1.66 ?

Trois adaptateurs sont arrivés en trois versions : Gravity Forms avec la 2.1.63, WPForms et WPForms Lite avec la 2.1.65, Forminator avec la 2.1.66. Avec les adaptateurs déjà présents, Hive protège désormais 7 extensions de formulaires ainsi que les formulaires de commentaire, d’inscription et de mot de passe oublié de WordPress lui-même, soit 10 surfaces au total.

Formulaires	Protégés depuis	Formule
Formulaire de commentaire, inscription et mot de passe oublié	2.1.53	Toutes les formules
Contact Form 7	2.1.58	Toutes les formules
Formidable Forms et Formidable Forms PRO	2.1.58	Business
Elementor Forms	2.1.58	Business
Ultimate Member	2.1.61	Business
Gravity Forms	2.1.63	Business
WPForms et WPForms Lite	2.1.65	Business
Forminator	2.1.66	Business

La 2.1.63 a aussi déplacé la limite entre les formules. Contact Form 7, le formulaire de contact le plus répandu, est passé de Professional à toutes les formules, Free compris, et l’assistant de démarrage l’active partout où l’extension est installée. Ultimate Member est passé de Professional à Business, à côté des autres adaptateurs avancés. Un site Professional où l’interrupteur Ultimate Member était déjà activé garde la valeur enregistrée et peut toujours le désactiver ; l’adaptateur reste en retrait tant que la formule ne le couvre pas. La vérification par calcul en plus de la preuve demande la formule Professional ou supérieure.

Chaque adaptateur a son propre interrupteur sous ReportedIP Hive > Protection, carte Form Protection. Le comportement de chaque extension est décrit dans les guides consacrés à Gravity Forms et à WPForms et Forminator.

Que signifie une règle pour tous les formulaires ?

Avant la 2.1.66, les formulaires ne traitaient pas de la même façon la preuve la plus nette que produit cette couche. Un champ leurre rempli, ce champ invisible qu’aucune personne ne voit, n’a pas d’explication innocente. Les adaptateurs pour les extensions tierces refusaient un tel envoi, tandis que le formulaire d’inscription et celui du mot de passe oublié de WordPress le laissaient passer. Depuis la 2.1.66, une décision commune sert chaque surface : le même verdict entraîne la même conséquence, le même message et la même entrée de journal.

Un bot de formulaire est bloqué et signalé dès sa première tentative

Remplir un champ caché demande une machine : attendre d’autres tentatives n’offrait donc à l’expéditeur que des essais gratuits. Un champ leurre rempli mène désormais directement à l’échelle de blocage et, en mode Community Network, au signalement à la communauté, comme sur le formulaire de commentaire depuis la 2.1.63. Le signalement nomme le formulaire par lequel l’envoi est arrivé au lieu d’un « suspicious activity » générique.

Aucun envoi refusé ne disparaît en silence

Chaque adaptateur suit la même règle de conséquence : un expéditeur refusé voit un message au niveau du formulaire. Hive ne range jamais un envoi dans le dossier spam de l’extension de formulaires et ne le supprime jamais sans un mot, car personne ne lit un dossier spam et un verdict erroné passerait inaperçu. Un visiteur dont le navigateur n’a pas exécuté le script est refusé avec un message qui en donne la raison, et cette adresse ne compte jamais pour un blocage. Depuis la 2.1.67, le formulaire de commentaire refuse un tel envoi de la même manière.

Une adresse en liste blanche n’est plus bloquée par un capteur rapide

Jusqu’à la 2.1.66, la liste blanche était vérifiée au moment du comptage des tentatives, pas quand un capteur agissait immédiatement. Le filtre de commentaires et la couche des formulaires agissent tous deux immédiatement, une adresse en liste blanche pouvait donc quand même être bloquée. La vérification de la liste blanche se trouve désormais dans l’étape que chaque capteur franchit avant un blocage.

Pourquoi la vérification par calcul est-elle liée à votre propre site ?

Avant la 2.1.64, la vérification par calcul plaçait sa tâche dans la page. Un script qui récupérait la page une fois pouvait y lire les noms des champs et la tâche, puis la résoudre en quelques millisecondes. Depuis la 2.1.64, le navigateur récupère la tâche auprès de votre propre site : signée, valable peu de temps, acceptée une seule fois et plus difficile quand un même réseau demande beaucoup de tâches. La page reste identique pour chaque visiteur, les caches de page complète comme WP Rocket, LiteSpeed ou un CDN continuent donc de fonctionner.

La vérification est conçue pour qu’aucun vrai visiteur ne perde un message :

Chaque refus est affiché à l’expéditeur au niveau du formulaire.
Si le site ne peut pas émettre de tâche, ou si la vérification elle-même échoue, l’envoi passe.
Une mise à jour de l’extension ouvre une nouvelle période de grâce et vide le cache de pages, pour que les pages mises en cache par l’ancienne version continuent de fonctionner.
Un visiteur qui clique sur Envoyer avant l’arrivée de la tâche est retenu un instant, puis l’envoi part.
La tâche n’est pas liée à l’adresse du visiteur, un téléphone qui change de réseau n’est donc pas refusé.
Le script se soustrait à Cloudflare Rocket Loader et à la combinaison des scripts de WP Rocket.

La vérification par calcul demande la formule Professional ou supérieure. Les sites sans HTTPS gardent la tâche signée et à usage unique, sans le calcul.

Quels bugs les quatre versions ont-elles corrigés ?

Un envoi Elementor refusé envoyait quand même le mail du formulaire. Depuis la 2.1.65, le refus arrête l’envoi avant qu’une action Elementor ne s’exécute, mail compris.
Les inscriptions Ultimate Member échouaient à la vérification par calcul. Le script de preuve ne voyait pas la manière dont Ultimate Member envoie ses formulaires, un visiteur rapide était donc refusé. Corrigé dans la 2.1.65.
Un formulaire chargé plus tard ne pouvait jamais passer. Les formulaires dans des fenêtres surgissantes ou affichés de nouveau après une validation échouée ne trouvaient aucune réponse prête. Depuis la 2.1.63, le script prépare de nouveau chaque formulaire qui apparaît.
La carte Extended Protection manquait sous PHP-FPM. La suggestion Switch on Extended Protection du tableau de bord n’apparaissait jamais sous nginx et chez la plupart des hébergeurs infogérés. Depuis la 2.1.65, elle utilise la même détection que l’onglet Server.
Un formulaire de contact refusé parlait d’une réinitialisation de mot de passe. Depuis la 2.1.63, chaque formulaire a sa propre formulation.
Trois textes allemands affichaient des umlauts illisibles sur la page Protection. Corrigé dans la 2.1.63.

Comment Hive bloque-t-il le spam de commentaires depuis la 2.1.63 ?

Le filtre de commentaires détectait et classait le spam depuis la 2.1.52, mais le blocage dépendait d’un compteur de fréquence que la plupart des spammeurs n’atteignaient jamais. Mesuré sur 13 jours sur un magazine en ligne, 104 des 109 adresses de spam ne pouvaient jamais l’atteindre, parce qu’elles publiaient une seule fois ou étalaient leurs commentaires sur plusieurs heures. Depuis la 2.1.63, un verdict clair n’attend plus un deuxième commentaire : un champ leurre rempli, ou un score de spam appuyé sur des signaux qu’un lecteur humain ne produit pas, bloque et signale l’adresse immédiatement.

Les commentaires suspects sur la seule base de signaux faibles passent toujours par le compteur, si bien qu’un lecteur habituel qui met un lien vers son propre site finit au pire en modération. La valeur par défaut du compteur a reçu une fenêtre plus longue dans la même version. Les installations encore sur l’ancienne valeur par défaut ont été mises à jour, une valeur que vous aviez choisie vous-même est restée intacte.

Quelle faille du pare-feu la 2.1.63 a-t-elle comblée ?

La règle de base contre la traversée de répertoires ne reconnaissait pas les formes doublement encodée et UTF-8 surlongue de ../. La forme doublement encodée est celle qu’exploite CVE-2026-87902, corrigée dans WordPress 7.1.2 : PHP décode la requête une fois, et WordPress décodait le nom de la page une seconde fois. Depuis la 2.1.63, la règle reconnaît chaque encodage dans les deux couches du pare-feu et reste silencieuse sur des points inoffensifs comme file..txt. Les sites en mode Community Network ont reçu la règle lors de la synchronisation suivante des règles. Le guide du pare-feu explique les deux couches.

Qu’est-ce qui change pour une flotte gérée ?

Le schéma des réglages à distance a reçu deux interrupteurs, un pour WPForms et un pour Forminator, tous deux recommandés à partir de Business dans l’assistant de démarrage. Rien n’a été retiré ni changé de nature, un tableau de bord de flotte qui n’a pas rechargé le schéma continue donc de fonctionner. Un filtre pour développeurs de l’ancienne tâche de calcul horaire a été supprimé ; il ne concernait que les sites qui l’utilisaient.

Questions sur Hive 2.1.66

Quelle formule protège WPForms et Forminator dans Hive ?

La protection de WPForms et de Forminator fait partie de la formule Business, avec Gravity Forms, Formidable Forms, Elementor Forms et Ultimate Member. Contact Form 7, le formulaire de commentaire, l’inscription et le mot de passe oublié sont protégés dans toutes les formules, Free compris. La vérification par calcul en plus de la preuve demande la formule Professional ou supérieure.

Un visiteur refusé perd-il son message ?

Un visiteur refusé voit toujours au niveau du formulaire pourquoi l’envoi n’est pas parti, et peut corriger puis renvoyer. Hive ne déplace jamais un envoi dans un dossier spam et ne le supprime jamais sans message. Si votre site ne peut pas émettre de tâche ou si la vérification échoue, l’envoi passe : une panne de votre côté ne coûte jamais son message à un vrai visiteur.

Que vérifier après la mise à jour vers la 2.1.66 ?

Ouvrez la carte Form Protection et activez chaque extension de formulaires installée que votre formule couvre ; en formule Business, l’assistant de démarrage recommande WPForms et Forminator. Lancez ensuite l’autotest sous Tools > Diagnostics, visible en Expert mode, et surveillez dans l’Event Log les envois refusés pendant les premiers jours après la mise à jour.

Pour aller plus loin

La documentation de Hive décrit la détection des bots et le spam de formulaires ainsi que la mise en cache et la compatibilité. Les articles de version précédents traitent de Hive 2.1.62 et de son journal d’audit et de Hive 2.1.57 et de son administration reconstruite.

Obtenir Hive pour WordPress

ReportedIP Hive 2.1.66 : une règle pour chaque formulaire protégé