ReportedIP Hive 2.1.66 : une règle pour WPForms, Forminator et tous les autres formulaires
ReportedIP Hive 2.1.66 clôt une série de quatre versions en deux jours : la protection des formulaires arrive sur WPForms, Forminator et Gravity Forms, la vérification par calcul est liée à votre propre site, et chaque formulaire protégé suit une seule règle : un champ leurre rempli est refusé, bloqué et signalé dès la première tentative, sur les dix surfaces que le plugin couvre désormais. La même série corrige un envoi Elementor refusé qui expédiait quand même son e-mail, une inscription Ultimate Member que le script de preuve ne voyait jamais, et un compteur de spam de commentaires que presque aucun spammeur n’atteignait.
Mettez à jour depuis l’administration WordPress ou téléchargez le ZIP actuel sur la page produit de Hive. Les adaptateurs pour les plugins de formulaires tiers font partie de la formule Business, Contact Form 7 est couvert dans chaque formule ; la liste des fonctions par formule se trouve sur la page de documentation du plugin Hive.
Ce qui a changé entre 2.1.62 et 2.1.66
Quatre versions sont sorties les 23 et 24 septembre 2026. Voici ce qu’elles donnent une fois additionnées.
| Version | Date | Changement principal |
|---|---|---|
| 2.1.63 | 23 sept. | Adaptateur Gravity Forms, Contact Form 7 gratuit dans chaque formule, traversée de répertoires à double encodage repérée par le pare-feu, spam de commentaires bloqué sur un verdict au lieu d’un compteur |
| 2.1.64 | 23 sept. | Vérification par calcul liée à une tâche émise par votre propre site, signée et à usage unique ; aucun visiteur n’y perd un message |
| 2.1.65 | 24 sept. | Adaptateur WPForms et WPForms Lite, fuite d’e-mail Elementor corrigée, envoi jQuery d’Ultimate Member détecté, carte Extended Protection sous PHP-FPM |
| 2.1.66 | 24 sept. | Adaptateur Forminator, une règle pour chaque formulaire, blocage et signalement dès la première tentative pour un leurre rempli, liste blanche vérifiée dans le répartiteur |
La protection des formulaires couvre désormais sept plugins de formulaires
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. Chacun a son propre commutateur sur la page Protection, sous Protection des formulaires, chacun est détecté par la classe du plugin concerné, et chacun refuse un bot au niveau du formulaire : une erreur de validation que l’expéditeur lit au-dessus du formulaire, aucune entrée écrite, aucun e-mail envoyé, rien qui tombe dans un dossier spam que personne ne consulte. Avec Contact Form 7, Formidable Forms, Formidable Forms PRO, Elementor Forms et Ultimate Member, la couche juge désormais sept plugins de formulaires, plus les formulaires de commentaire, d’inscription et de réinitialisation du mot de passe de WordPress lui-même, dix surfaces au total.
| Plugin de formulaires | Depuis | Formule | Où tombe le verdict |
|---|---|---|---|
| Contact Form 7 | 2.1.58 | Chaque formule | Hook de validation, refus affiché sur le formulaire |
| Formidable Forms et Formidable Forms PRO | 2.1.58 | Business | Hook de validation, refus affiché sur le formulaire |
| Elementor Forms (Elementor PRO) | 2.1.58 | Business | Erreur de champ depuis la 2.1.65, qui arrête chaque action d’envoi, e-mail compris |
| Ultimate Member | 2.1.61 | Business | Formulaires de connexion, d’inscription et de mot de passe ; une inscription passe aussi par les règles d’inscription |
| Gravity Forms | 2.1.63 | Business | Erreur de validation au niveau du formulaire, formulaires multipages jugés sur la dernière page, envois par l’API jamais jugés |
| WPForms et WPForms Lite | 2.1.65 | Business | Erreur d’en-tête sur le hook de traitement, après la validation des champs du plugin |
| Forminator | 2.1.66 | Business | Liste d’erreurs de l’envoi, avant la construction de l’entrée et avant le départ de l’e-mail |
La 2.1.63 a aussi déplacé la ligne des formules. Contact Form 7, le formulaire de contact le plus répandu, est couvert dans chaque formule et activé par le démarrage rapide partout où le plugin est installé ; Ultimate Member est passé de Professional à Business, à côté des autres adaptateurs avancés. Un site en Professional dont le commutateur Ultimate Member est activé garde sa valeur enregistrée et peut toujours le désactiver ; l’adaptateur se met en retrait jusqu’à ce que la formule le couvre à nouveau. Le guide Gravity Forms et le guide WPForms et Forminator parcourent les adaptateurs hook par hook.
Chaque formulaire protégé lit la même règle
Jusqu’à la 2.1.66, les surfaces ne s’accordaient pas sur la preuve la plus nette que produit cette couche. Un champ leurre rempli, ce champ invisible qu’aucune personne ne peut voir, est de l’automatisation sans explication innocente. Les six adaptateurs tiers refusaient un tel envoi et comptaient l’adresse. Le formulaire d’inscription de WordPress et la réinitialisation du mot de passe ne regardaient qu’un seul des quatre verdicts et laissaient passer un bot qui remplissait tous les champs, le champ caché compris. La décision vit désormais à un seul endroit, ReportedIP_Hive_Form_Proof::consequence(), et chaque surface l’appelle : une inscription avec un leurre rempli est refusée avec une phrase que l’expéditeur lit, et l’adresse dépense le même budget qu’un commentaire ou un formulaire de contact lui aurait coûté.
Rien ne change pour un visiteur sans JavaScript. Son envoi porte un leurre vide et aucun champ de preuve, ce qui est un autre verdict : sur un formulaire de contact, il est refusé avec un message qui en donne la raison, sur le formulaire de commentaire il coûte une étape de modération, et sur aucun des deux il ne compte pour un blocage.
Un bot de formulaire est bloqué et signalé dès sa première tentative
Remplir un champ caché demande une machine, alors attendre une deuxième et une troisième tentative avant d’agir n’offrait à l’expéditeur que deux passages gratuits et privait la communauté du signalement. Un leurre rempli va désormais tout droit sur l’échelle de blocage et dans le signalement communautaire, comme le filtre de commentaires traite la même preuve depuis la 2.1.52. Le signalement nomme le formulaire par lequel l’envoi est arrivé au lieu de dire « suspicious activity », et un commentaire qui était du spam certain nomme les signaux qui ont trahi l’expéditeur au lieu de « 1 spam comments in 0 minutes », une phrase qui déclenchait en plus une notice PHP pendant sa construction.
Une adresse en liste blanche ne peut plus être bloquée par un capteur rapide
La liste blanche était vérifiée au moment de compter les tentatives, pas au moment d’agir, si bien que tout capteur assez sûr de lui pour agir immédiatement passait à côté. Le filtre de commentaires et la couche des formulaires sont tous deux aussi sûrs. La consultation se trouve désormais dans le répartiteur où chaque capteur finit par arriver, si bien qu’une adresse de votre liste d’autorisation n’est jamais bloquée par une vérification qui saute le compteur.
La vérification par calcul est liée à votre site
Avant la 2.1.64, la vérification par calcul plaçait sa tâche dans la page elle-même, avec une valeur de départ qui ne dépendait que de l’heure. Un script qui récupérait la page une fois connaissait le leurre, le champ de preuve et la tâche, et la résolvait en quelques millisecondes. Le navigateur récupère désormais une tâche auprès de l’Endpoint du site : signée avec le sel du site, valable dix minutes, acceptée une seule fois, et d’autant plus difficile qu’un réseau demande des tâches vite. La page ne porte rien d’autre que l’adresse de l’Endpoint, identique pour chaque visiteur, si bien qu’un cache de page complète, LiteSpeed, WP Rocket ou un CDN continue de la servir sans changement ; la tâche voyage dans un POST qu’aucun cache ne stocke. Vérifié contre le même script : refusé sans tâche, refusé avec une tâche déjà utilisée, refusé avec une tâche altérée, accepté avec une tâche fraîche, exactement une fois. La tâche horaire et son filtre reportedip_hive_form_proof_buckets ont disparu.
Aucun visiteur n’y perd un message
- Chaque refus est annoncé à l’expéditeur par le formulaire d’où il vient.
- Une tâche que le serveur ne peut pas émettre est distribuée avec une difficulté nulle plutôt que retenue, et une panne du vérificateur répond par un passage.
- Une mise à jour du plugin relance la journée de grâce et purge le cache de pages, si bien qu’une page mise en cache par la version précédente continue de fonctionner.
- Un navigateur qui envoie avant que sa tâche soit revenue est retenu au plus huit secondes, puis expédié tel que le visiteur l’a envoyé.
- La tâche n’est pas liée à l’adresse du visiteur, si bien qu’un téléphone qui change de réseau entre le chargement de la page et l’envoi n’est pas refusé.
- Sans HTTPS, la tâche ne porte aucun calcul mais garde sa signature, son expiration et son usage unique.
- La balise script porte
data-cfasync="false"pour le Rocket Loader de Cloudflare etdata-nowprocketpour WP Rocket, et l’Endpoint est appelé avec le schéma de la page, si bien qu’un proxy qui termine TLS n’est pas arrêté par un blocage de contenu mixte.
Trois refus qui ne faisaient pas ce qu’ils annonçaient
Un envoi Elementor refusé expédiait quand même l’e-mail du formulaire. L’adaptateur remettait son refus à Elementor PRO sous forme de message seulement, et le gestionnaire exécute chaque action d’envoi, e-mail compris, tant qu’il ne détient aucune erreur de champ. L’expéditeur apprenait que le formulaire avait échoué après que l’e-mail était déjà parti. Depuis la 2.1.65, le refus est aussi une erreur de champ, ce qui arrête l’envoi avant qu’une action ne s’exécute ; la spécification navigateur vérifie le collecteur d’e-mails dans les deux sens, un POST nu refusé n’envoie rien, un vrai navigateur en envoie exactement un.
Les inscriptions Ultimate Member échouaient à la vérification par calcul. Ultimate Member envoie ses formulaires par un submit déclenché via jQuery, qui ne produit aucun événement submit natif, si bien que le script de preuve ne voyait jamais l’envoi et qu’un visiteur qui cliquait avant le retour de la tâche était refusé comme non prouvé. Le script écoute désormais aussi les submits déclenchés par jQuery et traite un envoi préparé dans la dernière seconde comme le même, parce que Gravity Forms déclenche le même submit jQuery juste après son propre hook de pré-envoi. Chaque adaptateur a désormais une spécification navigateur avec le calcul exigé : Contact Form 7, Elementor, Formidable, Gravity Forms, WPForms et Ultimate Member.
Un formulaire chargé après le premier passage ne pouvait jamais passer. Le script de preuve lisait le défi une seule fois, quand la page était prête ; un formulaire rendu plus tard, dans une fenêtre surgissante ou de nouveau après une validation échouée, ne trouvait aucune réponse calculée en attente. Depuis la 2.1.63, le script relit le défi et relance l’horloge dès qu’un plugin de formulaires signale un nouveau rendu, et depuis la 2.1.64 un envoi sans réponse en réserve est retenu pendant qu’une réponse est récupérée.
Le spam de commentaires est bloqué sur un verdict, pas sur un compteur
Le filtre de commentaires détectait et classait le spam depuis la 2.1.52, mais la conséquence reposait entièrement sur un compteur de fréquence : cinq commentaires rejetés d’une même adresse en soixante minutes. Mesuré sur treize jours sur un magazine en production, 56 pour cent des adresses spammeuses postaient exactement un commentaire et les autres étalaient les leurs sur des heures, si bien que 104 adresses sur 109 ne pouvaient jamais atteindre le seuil, aussi évident que soit le spam. Depuis la 2.1.63, un verdict qui tient seul n’attend plus un deuxième commentaire : un champ leurre rempli, ou un score égal ou supérieur à CERTAIN avec au moins une raison qu’un lecteur ne peut pas produire (pas d’user-agent de navigateur, balisage de lien collé, ancre tapée à la main, TLD jetable, URL en guise de nom d’auteur, corps déjà vu), bloque et signale l’adresse sur-le-champ. Les scores bâtis uniquement sur des signaux faibles continuent de passer par le compteur, si bien qu’une personne qui navigue sans JavaScript et met un lien vers son propre site est toujours seulement classée pour relecture.
Le compteur lui-même est désormais à trois commentaires rejetés par jour, contre cinq par heure auparavant. Cinq en soixante minutes est une rafale que presque aucun spammeur ne produit, ce qui explique que le compteur ne l’atteignait presque jamais, et la table des tentatives repartait de toute façon après soixante minutes d’inactivité, si bien qu’une fenêtre plus longue dans les réglages ne voyait jamais plus que le compte redémarré. La migration de schéma v18 fait passer les installations qui portent encore l’ancienne paire sur la nouvelle ; une valeur qu’un opérateur a réglée lui-même n’est pas touchée. La même paire régit les adaptateurs de formulaires.
La traversée de répertoires à double encodage ne passe plus le pare-feu
La règle de traversée du jeu de base connaissait ../, ..%2f et %2e%2e/, mais pas %2e%2e%2f avec la barre oblique encodée, pas le double encodage %252e%252e%252f et pas la forme UTF-8 surlongue. La forme à double encodage est exactement ce dont traite le correctif de résolution de modèles de WordPress 7.1.2 (CVE-2026-87902) : PHP décode la requête une fois, WordPress décodait pagename une deuxième fois, donc l’attaquant envoie la forme à double encodage et le pare-feu ne voyait rien qu’il connaisse. Depuis la 2.1.63, la règle reconnaît chaque encodage sur le fil, dans les deux couches du pare-feu, et reste silencieuse sur file..txt ou per_page=2..5. Les sites en mode Community Network reçoivent la même règle avec la prochaine synchronisation des règles.
Des corrections plus petites qui comptent sur une vraie installation
- La carte « Activer Extended Protection » n’apparaissait jamais sur les sites PHP-FPM. Le Dashboard demandait si le serveur lit
.htaccess, mais la configuration en un clic écrit un.user.inisous PHP-FPM, CGI et LiteSpeed, si bien que nginx et la plupart des hébergeurs infogérés ne recevaient jamais la suggestion. La carte suit la même détection que l’onglet Serveur. - La règle hors écran du champ leurre l’emporte sur la remise à zéro d’éléments d’un plugin de formulaires, qui avait fait apparaître le champ sur la page où un visiteur pouvait le remplir.
- Un refus pour réputation communautaire au-dessus d’un formulaire tiers parlait d’une réinitialisation de mot de passe. Un formulaire de contact refusé le dit désormais avec ses propres mots.
- Trois chaînes allemandes de la page Protection affichaient des trémas abîmés après un aller-retour Latin-1 dans la 2.1.61 ; la barrière i18n refuse désormais un fichier de traduction qui porte ce motif.
- Quatre écrans d’administration gardaient leur propre liste d’adaptateurs de formulaires et n’avaient pas grandi avec la table. Ils lisent désormais la table, si bien qu’un nouvel adaptateur apparaît aussitôt dans la note d’état verrouillé, dans le lien profond de préparation et dans l’action du Dashboard.
- Ajouter un formulaire protégé tient en un appel. La règle, la formulation, la ligne de journal et le compteur sont derrière un point d’entrée unique, et un test nomme le fichier quand une nouvelle surface se met à lire les verdicts toute seule.
Ce que cela change pour une flotte gérée
Deux clés ont été ajoutées au schéma des réglages à distance, reportedip_hive_form_proof_wpforms et reportedip_hive_form_proof_forminator, toutes deux activées par défaut à partir de Business via la recommandation du démarrage rapide ; rien n’a été retiré ni changé de nature. Un dashboard qui n’a pas rechargé le schéma continue de fonctionner. La paire du compteur de commentaires passe par la migration v18 sauf si un opérateur l’a réglée, et le filtre retiré reportedip_hive_form_proof_buckets ne concernait qu’un site qui l’avait branché.
La 2.1.66 fait suite à la 2.1.62, qui a fait de la piste d’audit un registre de qui a changé quoi, et à la 2.1.57, qui a réuni chaque réglage sur une seule page Protection. La documentation du plugin tient la liste actuelle des fonctions par formule, les capteurs et leurs valeurs par défaut, et le guide du honeypot de formulaire explique les quatre verdicts que toutes les surfaces partagent désormais.