ReportedIP Hive 2.1.66: una regla para cada formulario protegido
ReportedIP Hive 2.1.66 somete cada formulario protegido a una sola regla: un bot que rellena el campo señuelo oculto se rechaza, se bloquea y se notifica en su primer intento, en las 10 superficies de formulario que cubre el plugin. Esta versión cierra una serie de cuatro versiones publicadas el 23 y el 24 de septiembre de 2026, que añadió Gravity Forms, WPForms y Forminator, vinculó la comprobación de cálculo a tu propio sitio y bloqueó el spam en comentarios desde el primer veredicto claro.
Actualiza desde el administrador de WordPress o descarga el ZIP actual desde la página de producto de Hive. Cómo funciona la protección de formularios se explica en la guía del honeypot de formulario; esta entrada recoge lo que cambió en estas cuatro versiones. La interfaz de Hive está en inglés, así que las etiquetas citadas también lo están.
¿Qué cambió entre Hive 2.1.62 y 2.1.66?
Salieron cuatro versiones en dos días.
| Versión | Fecha | Cambio principal |
|---|---|---|
| 2.1.63 | 23 de septiembre de 2026 | Adaptador para Gravity Forms, Contact Form 7 en todos los planes, spam en comentarios bloqueado ante un veredicto claro, recorrido de directorios con doble codificación detectado por el firewall |
| 2.1.64 | 23 de septiembre de 2026 | Comprobación de cálculo vinculada a una tarea firmada y de un solo uso emitida por tu propio sitio |
| 2.1.65 | 24 de septiembre de 2026 | Adaptador para WPForms, fuga de correos de Elementor corregida, registros de Ultimate Member reparados |
| 2.1.66 | 24 de septiembre de 2026 | Adaptador para Forminator, una regla para todos los formularios, bloqueo en el primer intento para un campo señuelo relleno |
¿Qué formularios protege Hive desde la 2.1.66?
Llegaron tres adaptadores 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. Junto con los adaptadores que ya existían, Hive protege ahora 7 plugins de formularios además de los formularios de comentarios, registro y restablecimiento de contraseña del propio WordPress, 10 superficies en total.
| Formularios | Protegidos desde | Plan |
|---|---|---|
| Formulario de comentarios, registro y restablecimiento de contraseña | 2.1.53 | Todos los planes |
| Contact Form 7 | 2.1.58 | Todos los planes |
| Formidable Forms y 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 y WPForms Lite | 2.1.65 | Business |
| Forminator | 2.1.66 | Business |
La 2.1.63 también movió el límite entre planes. Contact Form 7, el formulario de contacto más extendido, pasó de Professional a todos los planes, Free incluido, y el asistente de inicio lo activa allí donde el plugin está instalado. Ultimate Member pasó de Professional a Business, junto a los demás adaptadores avanzados. Un sitio Professional que ya tenía activado el interruptor de Ultimate Member conserva el valor guardado y puede seguir desactivándolo; el adaptador queda en pausa hasta que el plan vuelva a cubrirlo. La comprobación de cálculo además de la prueba requiere el plan Professional o superior.
Cada adaptador tiene su propio interruptor en ReportedIP Hive > Protection, tarjeta Form Protection. Lo que ocurre en cada plugin se explica en las guías de Gravity Forms y de WPForms y Forminator.
¿Qué significa una regla para todos los formularios?
Antes de la 2.1.66, los formularios no trataban igual la prueba más clara que produce esta capa. Un campo señuelo relleno, ese campo invisible que ninguna persona ve, no tiene explicación inocente. Los adaptadores para plugins de terceros rechazaban un envío así, mientras que el formulario de registro y el de restablecimiento de contraseña de WordPress lo dejaban pasar. Desde la 2.1.66, una decisión común sirve a cada superficie: el mismo veredicto lleva a la misma consecuencia, el mismo mensaje y la misma entrada en el registro.
Un bot de formularios se bloquea y se notifica en su primer intento
Rellenar un campo oculto requiere una máquina, así que esperar más intentos solo le regalaba al remitente pruebas gratis. Un campo señuelo relleno lleva ahora directamente a la escalera de bloqueo y, en modo Community Network, a la notificación a la comunidad, como en el formulario de comentarios desde la 2.1.63. La notificación nombra el formulario por el que llegó el envío en lugar de un genérico «suspicious activity».
Ningún envío rechazado desaparece en silencio
Cada adaptador sigue la misma regla de consecuencias: un remitente rechazado ve un mensaje en el formulario. Hive nunca guarda un envío en la carpeta de spam del plugin de formularios ni lo descarta sin decir nada, porque nadie lee una carpeta de spam y un veredicto erróneo pasaría desapercibido. Un visitante cuyo navegador no ejecutó el script se rechaza con un mensaje que explica el motivo, y esa dirección nunca cuenta para un bloqueo. Desde la 2.1.67, el formulario de comentarios rechaza un envío así de la misma manera.
Un sensor rápido ya no bloquea una dirección de la lista blanca
Hasta la 2.1.66, la lista blanca se comprobaba al contar los intentos, no cuando un sensor actuaba de inmediato. El filtro de comentarios y la capa de formularios actúan ambos de inmediato, así que una dirección de la lista blanca podía acabar bloqueada. La comprobación de la lista blanca está ahora en el paso por el que pasa cada sensor antes de un bloqueo.
¿Por qué la comprobación de cálculo está vinculada a tu propio sitio?
Antes de la 2.1.64, la comprobación de cálculo colocaba su tarea en la propia página. Un script que descargaba la página una vez podía leer los nombres de los campos y la tarea, y resolverla en milisegundos. Desde la 2.1.64, el navegador pide la tarea a tu propio sitio: firmada, válida durante poco tiempo, aceptada una sola vez y más difícil cuando una misma red pide muchas tareas. La página es igual para todos los visitantes, así que las cachés de página completa como WP Rocket, LiteSpeed o una CDN siguen funcionando.
La comprobación está pensada para que ningún visitante real pierda un mensaje:
- Cada rechazo se muestra al remitente en el formulario.
- Si el sitio no puede emitir una tarea, o la propia comprobación falla, el envío pasa.
- Una actualización del plugin abre un nuevo periodo de gracia y vacía la caché de páginas, para que las páginas en caché de la versión anterior sigan funcionando.
- Un visitante que pulsa Enviar antes de que llegue la tarea se retiene un momento y después se envía.
- La tarea no está ligada a la dirección del visitante, así que un móvil que cambia de red no se rechaza.
- El script queda fuera de Cloudflare Rocket Loader y de la combinación de scripts de WP Rocket.
La comprobación de cálculo requiere el plan Professional o superior. Los sitios sin HTTPS conservan la tarea firmada y de un solo uso, sin el cálculo.
¿Qué errores corrigieron las cuatro versiones?
- Un envío de Elementor rechazado seguía enviando el correo del formulario. Desde la 2.1.65, el rechazo detiene el envío antes de que se ejecute cualquier acción de Elementor, correo incluido.
- Los registros de Ultimate Member fallaban la comprobación de cálculo. El script de prueba no detectaba la forma en que Ultimate Member envía sus formularios, así que un visitante rápido se rechazaba. Corregido en la 2.1.65.
- Un formulario cargado más tarde nunca podía pasar. Los formularios en ventanas emergentes o los que se volvían a mostrar tras una validación fallida no encontraban ninguna respuesta preparada. Desde la 2.1.63, el script vuelve a preparar cada formulario nuevo.
- Faltaba la tarjeta Extended Protection con PHP-FPM. La sugerencia Switch on Extended Protection del panel nunca aparecía en nginx ni en la mayoría de los hostings gestionados. Desde la 2.1.65 usa la misma detección que la pestaña Server.
- Un formulario de contacto rechazado hablaba de un restablecimiento de contraseña. Desde la 2.1.63, cada formulario tiene su propio texto.
- Tres textos en alemán mostraban diéresis ilegibles en la página Protection. Corregido en la 2.1.63.
¿Cómo bloquea Hive el spam en comentarios desde la 2.1.63?
El filtro de comentarios detectaba y archivaba el spam desde la 2.1.52, pero el bloqueo dependía de un contador de frecuencia que la mayoría de los spammers nunca alcanzaba. Medido durante 13 días en una revista en línea, 104 de 109 direcciones de spam nunca podían alcanzarlo, porque comentaban una sola vez o repartían sus comentarios a lo largo de horas. Desde la 2.1.63, un veredicto claro ya no espera a un segundo comentario: un campo señuelo relleno, o una puntuación de spam basada en señales que un lector humano no produce, bloquea y notifica la dirección al instante.
Los comentarios que solo parecen sospechosos por señales débiles siguen pasando por el contador, así que un lector habitual que enlaza su propio sitio acaba como mucho en moderación. El valor por defecto del contador recibió una ventana más larga en la misma versión. Las instalaciones que seguían con el valor por defecto antiguo se actualizaron, y un valor que hubieras fijado tú se quedó como estaba.
¿Qué hueco del firewall cerró la 2.1.63?
La regla básica contra el recorrido de directorios no reconocía las formas con doble codificación y UTF-8 sobrelargo de ../. La forma con doble codificación es la que aprovecha CVE-2026-87902, corregida en WordPress 7.1.2: PHP decodifica la petición una vez, y WordPress decodificaba el nombre de la página una segunda vez. Desde la 2.1.63, la regla reconoce cada codificación en las dos capas del firewall y no salta con puntos inofensivos como file..txt. Los sitios en modo Community Network recibieron la regla con la siguiente sincronización del conjunto de reglas. La guía del firewall explica las dos capas.
¿Qué cambia para una flota gestionada?
El esquema de ajustes remotos ganó dos interruptores, uno para WPForms y otro para Forminator, ambos recomendados desde Business en el asistente de inicio. No se eliminó ni cambió de naturaleza nada, así que un panel de flota que no ha recargado el esquema sigue funcionando. Se eliminó un filtro para desarrolladores de la antigua tarea de cálculo por horas; solo afectaba a los sitios que lo usaban.
Preguntas sobre Hive 2.1.66
¿Qué plan protege WPForms y Forminator en Hive?
La protección de WPForms y Forminator forma parte del plan Business, junto con Gravity Forms, Formidable Forms, Elementor Forms y Ultimate Member. Contact Form 7, el formulario de comentarios, el registro y el restablecimiento de contraseña están protegidos en todos los planes, Free incluido. La comprobación de cálculo además de la prueba requiere el plan Professional o superior.
¿Pierde su mensaje un visitante rechazado?
Un visitante rechazado siempre ve en el formulario por qué no se envió, y puede corregirlo y volver a enviarlo. Hive nunca mueve un envío a una carpeta de spam ni lo descarta sin mensaje. Si tu sitio no puede emitir una tarea o la comprobación falla, el envío pasa, así que un fallo por tu parte nunca le cuesta el mensaje a un visitante real.
¿Qué debo revisar tras actualizar a la 2.1.66?
Abre la tarjeta Form Protection y activa cada plugin de formularios instalado que cubra tu plan; en el plan Business, el asistente de inicio recomienda WPForms y Forminator. Después lanza la autoprueba en Tools > Diagnostics, visible en Expert mode, y revisa en el Event Log los envíos rechazados durante los primeros días tras la actualización.
Sigue leyendo
La documentación de Hive describe la detección de bots y el spam en formularios y la caché y compatibilidad. Las entradas de versiones anteriores tratan Hive 2.1.62 con el registro de auditoría y Hive 2.1.57 con la administración reconstruida.