ReportedIP Hive 2.1.66: una regla para WPForms, Forminator y cualquier otro formulario
ReportedIP Hive 2.1.66 cierra una serie de cuatro versiones en dos días: la protección de formularios llega a WPForms, Forminator y Gravity Forms, la comprobación de cálculo queda vinculada a tu propio sitio, y todos los formularios protegidos siguen una sola regla: un campo señuelo rellenado se rechaza, se bloquea y se notifica en el primer intento, en las diez superficies que el plugin cubre ahora. La misma serie corrige un envío de Elementor rechazado que aun así mandaba su correo, un registro de Ultimate Member que el script de prueba nunca veía y un contador de spam en comentarios que casi ningún spammer alcanzaba.
Actualiza desde el administrador de WordPress o descarga el ZIP actual en la página del producto Hive. Los adaptadores para plugins de formularios de terceros forman parte del plan Business, Contact Form 7 está cubierto en todos los planes; la lista de funciones por plan está en la página de documentación del plugin Hive.
Qué cambió entre 2.1.62 y 2.1.66
Cuatro versiones salieron el 23 y el 24 de septiembre de 2026. Esto es lo que suman.
| Versión | Fecha | Cambio principal |
|---|---|---|
| 2.1.63 | 23 sep. | Adaptador de Gravity Forms, Contact Form 7 gratis en todos los planes, el cortafuegos detecta el directory traversal con doble codificación, el spam en comentarios se bloquea por un veredicto y no por un contador |
| 2.1.64 | 23 sep. | Comprobación de cálculo vinculada a una tarea emitida por tu propio sitio, firmada y de un solo uso; ningún visitante pierde un mensaje por ella |
| 2.1.65 | 24 sep. | Adaptador para WPForms y WPForms Lite, corregida la fuga de correo en Elementor, detectado el envío por jQuery de Ultimate Member, tarjeta de Extended Protection en PHP-FPM |
| 2.1.66 | 24 sep. | Adaptador de Forminator, una regla para cada formulario, bloqueo y notificación en el primer intento con un señuelo rellenado, la lista blanca se comprueba en el despachador |
La protección de formularios cubre ahora siete plugins de formularios
Tres adaptadores llegaron en tres versiones. Gravity Forms con la 2.1.63, WPForms y WPForms Lite con la 2.1.65, Forminator con la 2.1.66. Cada uno tiene su propio interruptor en la página Protección, bajo Protección de formularios, cada uno se detecta por la clase del propio plugin, y cada uno rechaza a un bot en el formulario: un error de validación que el remitente lee encima del formulario, ninguna entrada escrita, ningún correo enviado, nada que caiga en una carpeta de spam que nadie mira. Junto con Contact Form 7, Formidable Forms, Formidable Forms PRO, Elementor Forms y Ultimate Member, la capa juzga ahora siete plugins de formularios más los formularios de comentarios, registro y restablecimiento de contraseña del propio WordPress, diez superficies en total.
| Plugin de formularios | Desde | Plan | Dónde cae el veredicto |
|---|---|---|---|
| Contact Form 7 | 2.1.58 | Todos los planes | Hook de validación, rechazo mostrado en el formulario |
| Formidable Forms y Formidable Forms PRO | 2.1.58 | Business | Hook de validación, rechazo mostrado en el formulario |
| Elementor Forms (Elementor PRO) | 2.1.58 | Business | Error de campo desde la 2.1.65, que detiene todas las acciones de envío, correo incluido |
| Ultimate Member | 2.1.61 | Business | Formularios de inicio de sesión, registro y contraseña; un registro pasa además por las reglas de registro |
| Gravity Forms | 2.1.63 | Business | Error de validación a nivel de formulario, los formularios de varias páginas se juzgan en la última, los envíos por la API nunca |
| WPForms y WPForms Lite | 2.1.65 | Business | Error de cabecera en el hook de procesamiento, tras la validación de campos del plugin |
| Forminator | 2.1.66 | Business | Lista de errores del envío, antes de construir la entrada y antes de que salga el correo |
La 2.1.63 también movió la línea de los planes. Contact Form 7, el formulario de contacto más común, está cubierto en todos los planes y el inicio rápido lo activa allí donde el plugin está instalado; Ultimate Member pasó de Professional a Business, junto a los demás adaptadores avanzados. Un sitio en Professional con el interruptor de Ultimate Member activado conserva el valor guardado y aún puede desactivarlo; el adaptador se retira hasta que el plan vuelva a cubrirlo. La guía de Gravity Forms y la guía de WPForms y Forminator recorren los adaptadores hook a hook.
Todos los formularios protegidos leen la misma regla
Hasta la 2.1.66, las superficies no coincidían sobre la prueba más clara que produce esta capa. Un campo señuelo rellenado, el campo invisible que ninguna persona puede ver, es automatización sin explicación inocente. Los seis adaptadores de terceros rechazaban ese envío y contaban la dirección. El formulario de registro de WordPress y el restablecimiento de contraseña miraban solo uno de los cuatro veredictos y dejaban pasar a un bot que rellenaba todos los campos, el oculto incluido. La decisión vive ahora en un solo lugar, ReportedIP_Hive_Form_Proof::consequence(), y todas las superficies la llaman: un registro con un señuelo rellenado se rechaza con una frase que el remitente lee, y la dirección gasta el mismo presupuesto que le habría costado un comentario o un formulario de contacto.
Nada cambia para un visitante sin JavaScript. Su envío lleva un señuelo vacío y ningún campo de prueba, que es un veredicto distinto: en un formulario de contacto se rechaza con un mensaje que explica el motivo, en el formulario de comentarios cuesta un paso de moderación, y en ninguno de los dos cuenta para un bloqueo.
Un bot de formularios se bloquea y se notifica en su primer intento
Rellenar un campo oculto requiere una máquina, así que esperar a un segundo y un tercer intento antes de actuar solo daba al remitente dos pasadas gratis y dejaba a la comunidad sin el informe. Un señuelo rellenado va ahora directo a la escalera de bloqueo y al informe a la comunidad, tal como el filtro de comentarios trata la misma prueba desde la 2.1.52. El informe nombra el formulario por el que llegó el envío en lugar de decir «suspicious activity», y un comentario que era spam seguro nombra las señales que delataron al remitente en lugar de «1 spam comments in 0 minutes», una frase que además lanzaba un aviso de PHP mientras se construía.
Una dirección en la lista blanca ya no puede ser bloqueada por un sensor rápido
La lista blanca se comprobaba al contar los intentos, no al actuar sobre ellos, así que cualquier sensor lo bastante seguro como para actuar al momento pasaba de largo. El filtro de comentarios y la capa de formularios son así de seguros. La consulta está ahora en el despachador al que acaba llegando cada sensor, de modo que una dirección de tu lista de permitidos nunca queda bloqueada por una comprobación que se salta el contador.
La comprobación de cálculo está vinculada a tu sitio
Antes de la 2.1.64, la comprobación de cálculo plantaba su tarea en la propia página, con un valor inicial que dependía solo de la hora. Un script que descargaba la página una vez conocía el señuelo, el campo de prueba y la tarea, y la resolvía en unos milisegundos. Ahora el navegador obtiene una tarea del Endpoint del propio sitio: firmada con la sal del sitio, válida diez minutos, aceptada una sola vez y más difícil cuanto más rápido pide tareas una red. La página no lleva más que la dirección del Endpoint, idéntica para cada visitante, así que una caché de página completa, LiteSpeed, WP Rocket o una CDN siguen sirviéndola sin cambios; la tarea viaja en un POST que ninguna caché guarda. Verificado contra el mismo script: rechazado sin tarea, rechazado con una tarea gastada, rechazado con una manipulada, aceptado con una nueva, exactamente una vez. La tarea horaria y su filtro reportedip_hive_form_proof_buckets han desaparecido.
Ningún visitante pierde un mensaje por ella
- Cada rechazo se comunica al remitente en el formulario del que vino.
- Una tarea que el servidor no puede emitir se entrega con dificultad cero en vez de retenerse, y un fallo del verificador responde con un aprobado.
- Una actualización del plugin reinicia el día de gracia y purga la caché de páginas, así que una página cacheada por la versión anterior sigue funcionando.
- Un navegador que envía antes de que vuelva su tarea se retiene como máximo ocho segundos y luego se manda tal como lo envió el visitante.
- La tarea no está vinculada a la dirección del visitante, así que un teléfono que cambia de red entre la carga de la página y el envío no se rechaza.
- Sin HTTPS la tarea no lleva aritmética, pero conserva su firma, su caducidad y su uso único.
- La etiqueta script lleva
data-cfasync="false"para el Rocket Loader de Cloudflare ydata-nowprocketpara WP Rocket, y el Endpoint se pide con el esquema de la página, así que un proxy que termina TLS no se topa con un bloqueo de contenido mixto.
Tres rechazos que no hacían lo que decían
Un envío de Elementor rechazado seguía mandando el correo del formulario. El adaptador entregaba su rechazo a Elementor PRO solo como mensaje, y el manejador ejecuta todas las acciones de envío, correo incluido, mientras no tenga ningún error de campo. Al remitente se le decía que el formulario había fallado cuando el correo ya había salido. Desde la 2.1.65 el rechazo es también un error de campo, lo que detiene el envío antes de que se ejecute ninguna acción; la especificación de navegador comprueba el receptor de correo en ambos sentidos, un POST desnudo rechazado no envía nada, un navegador real envía exactamente uno.
Los registros de Ultimate Member fallaban la comprobación de cálculo. Ultimate Member envía sus formularios con un submit disparado por jQuery, que no produce ningún evento submit nativo, así que el script de prueba nunca veía el envío y un visitante que hacía clic antes de que volviera la tarea era rechazado como no probado. El script escucha ahora también los submits disparados por jQuery y trata un envío preparado en el último segundo como el mismo, porque Gravity Forms dispara ese mismo submit de jQuery justo después de su propio hook de preenvío. Todos los adaptadores tienen ahora una especificación de navegador con el cálculo exigido: Contact Form 7, Elementor, Formidable, Gravity Forms, WPForms y Ultimate Member.
Un formulario cargado después de la primera pasada nunca podía aprobar. El script de prueba leía el reto una sola vez, cuando la página estaba lista; un formulario que llegaba después, en una ventana emergente o renderizado de nuevo tras una validación fallida, no encontraba ninguna respuesta calculada esperando. Desde la 2.1.63 el script vuelve a leer el reto y reinicia el reloj cada vez que un plugin de formularios avisa de un nuevo renderizado, y desde la 2.1.64 un envío sin respuesta en reserva se retiene mientras se obtiene una.
El spam en comentarios se bloquea por un veredicto, no por un contador
El filtro de comentarios detectaba y archivaba spam desde la 2.1.52, pero la consecuencia dependía por completo de un contador de frecuencia: cinco comentarios rechazados de una dirección en sesenta minutos. Medido durante trece días en una revista en producción, el 56 por ciento de las direcciones que enviaban spam publicaban exactamente un comentario y el resto repartía los suyos a lo largo de horas, así que 104 de 109 direcciones nunca podían alcanzar el umbral por evidente que fuera el spam. Desde la 2.1.63 un veredicto que se sostiene por sí solo ya no espera a un segundo comentario: un campo señuelo rellenado, o una puntuación igual o superior a CERTAIN con al menos un motivo que un lector no puede producir (sin user-agent de navegador, marcado de enlaces pegado, un ancla escrita a mano, un TLD desechable, una URL como nombre de autor, un cuerpo ya visto), bloquea y notifica la dirección en el acto. Las puntuaciones formadas solo por señales blandas siguen pasando por el contador, así que alguien que navega sin JavaScript y enlaza su propio sitio sigue archivándose solo para revisión.
El propio contador está ahora en tres comentarios rechazados al día, frente a cinco por hora. Cinco en sesenta minutos es una ráfaga que casi ningún spammer produce, por eso el contador casi nunca la alcanzaba, y la tabla de intentos se reiniciaba de todos modos tras sesenta minutos de inactividad, así que una ventana más larga en los ajustes nunca veía más que el recuento reiniciado. La migración de esquema v18 pasa las instalaciones que aún llevan el par antiguo al nuevo; un valor que un operador fijó por sí mismo se deja como está. El mismo par rige los adaptadores de formularios.
El directory traversal con doble codificación ya no pasa el cortafuegos
La regla de traversal del conjunto base conocía ../, ..%2f y %2e%2e/, pero no %2e%2e%2f con la barra codificada, ni el doble codificado %252e%252e%252f ni la forma UTF-8 sobrelarga. La forma con doble codificación es exactamente de lo que trata la corrección de resolución de plantillas de WordPress 7.1.2 (CVE-2026-87902): PHP decodifica la consulta una vez, WordPress decodificaba pagename una segunda vez, así que el atacante envía la forma con doble codificación y el cortafuegos no veía nada que conociera. Desde la 2.1.63 la regla coincide con todas las codificaciones en el cable, en ambas capas del cortafuegos, y se mantiene en silencio ante file..txt o per_page=2..5. Los sitios en modo Community Network reciben la misma regla con la próxima sincronización del conjunto de reglas.
Correcciones menores que importan en una instalación real
- La tarjeta «Activar Extended Protection» nunca aparecía en sitios con PHP-FPM. El Dashboard preguntaba si el servidor lee
.htaccess, pero la configuración en un clic escribe un.user.inibajo PHP-FPM, CGI y LiteSpeed, así que nginx y la mayoría de los hostings gestionados nunca recibían la sugerencia. La tarjeta sigue la misma detección que usa la pestaña Servidor. - La regla fuera de pantalla del campo señuelo gana al reinicio de elementos de un plugin de formularios, que había puesto el campo en la página para que un visitante lo rellenara.
- Un rechazo por reputación en la comunidad encima de un formulario de terceros hablaba de un restablecimiento de contraseña. Un formulario de contacto rechazado lo dice ahora con sus propias palabras.
- Tres cadenas en alemán de la página Protección mostraban diéresis rotas tras un viaje de ida y vuelta por Latin-1 en la 2.1.61; la puerta de i18n rechaza ahora un archivo de traducción con ese patrón.
- Cuatro pantallas de administración mantenían su propia lista de adaptadores de formularios y no habían crecido con la tabla. Ahora leen la tabla, así que un nuevo adaptador aparece a la vez en la nota de estado bloqueado, en el enlace directo de preparación y en la acción del Dashboard.
- Añadir un formulario protegido es una sola llamada. La regla, el texto, la fila de registro y el contador están detrás de un único punto de entrada, y una prueba nombra el archivo cuando una nueva superficie empieza a leer veredictos por su cuenta.
Qué cambia para una flota gestionada
Se añadieron dos claves al esquema de ajustes remotos, reportedip_hive_form_proof_wpforms y reportedip_hive_form_proof_forminator, ambas activadas por defecto desde Business a través de la recomendación del inicio rápido; nada se eliminó ni cambió de naturaleza. Un dashboard que no haya recargado el esquema sigue funcionando. El par del contador de comentarios pasa por la migración v18 salvo que un operador lo haya fijado, y el filtro eliminado reportedip_hive_form_proof_buckets solo afectaba a un sitio que lo hubiera enganchado.
La 2.1.66 sigue a la 2.1.62, que convirtió el registro de auditoría en un historial de quién cambió qué, y a la 2.1.57, que reunió todos los ajustes en una sola página de Protección. La documentación del plugin lleva la lista actual de funciones por plan, los sensores y sus valores por defecto, y la guía del honeypot de formularios explica los cuatro veredictos que ahora comparten todas las superficies.