ReportedIP Hive 2.1.49: auditoría de seguridad, estándar de ajustes y gestión de flota
Hive 2.1.49 cerró una serie de ocho versiones publicadas entre el 14 y el 26 de agosto de 2026: una auditoría de seguridad con nueve hallazgos corregidos, un estándar de ajustes único para cada vía de escritura y una gestión de flota que aplica una misma política de seguridad a todos tus sitios. La versión actual es la 2.1.67, y las notas de abajo indican dónde ha cambiado desde entonces un menú o la asignación a un plan. La interfaz de Hive está en inglés, por eso las etiquetas se citan en inglés.
¿Qué cambió entre Hive 2.1.41 y 2.1.49?
- 2.1.42 dejó de contar dos veces los inicios de sesión XML-RPC fallidos con contraseña de aplicación.
- 2.1.44 corrigió nueve hallazgos de una auditoría de seguridad de todo el código, cuatro de ellos en el camino que sigue una petición para pasar el control de bloqueo y el firewall.
- 2.1.45 hace que cada petición a la API identifique su instalación como lo hacen las comprobaciones de actualizaciones de wordpress.org, y añadió una tarjeta «Licensed domains».
- 2.1.46 restableció las actualizaciones del plugin en los paneles de gestión remota, que no veían las actualizaciones de Hive desde la 2.1.32.
- 2.1.47 introdujo el registro de ajustes y un protocolo versionado de ajustes remotos.
- 2.1.48 añadió la gestión de flota en la nube para el plan Business, un transporte firmado con Ed25519 con el que reportedip.com aplica políticas a tus sitios.
- 2.1.49 reforzó ese endpoint para que quien llame sin autenticarse no pueda saber si un sitio lo ha activado.
Todo esto está en el plugin gratuito, salvo que una línea nombre un plan. El motor de protección sigue siendo gratuito. La versión anterior a esta serie trajo el bloqueo de nodos de salida Tor.
¿Qué fallos de seguridad corrigió Hive 2.1.44?
La 2.1.44 salió de una auditoría de seguridad y corrección de todo el código. Cada hallazgo se verificó sobre el código en ejecución antes de cambiarlo, y cada corrección incluye una prueba de regresión.
admin-ajax.php quedaba fuera del control de bloqueo
El control de IP se apartaba ante cada petición AJAX, y el firewall omitía todo lo que WordPress trata como una petición de administración. Eso incluye admin-ajax.php y admin-post.php, que atienden cada acción AJAX pública que registra un sitio. Una dirección bloqueada conservaba acceso completo, y el cuerpo de sus peticiones no se inspeccionaba. Ahora solo WP-Cron queda exento, las peticiones anónimas a ambos endpoints se inspeccionan y quien llama por AJAX recibe un error JSON en lugar de la página de bloqueo.
Una excepción del firewall podía ocultar todas las reglas siguientes
El motor se detenía en la primera regla coincidente y solo después la comparaba con las excepciones. Una petición que añadía un fragmento coincidente con una regla exenta hacía pasar su carga real por todo el análisis. La comprobación de excepciones se hace ahora dentro del bucle, y el análisis continúa tras una coincidencia exenta.
Peticiones con codificación porcentual esquivaban tres sensores
La función de WordPress sanitize_text_field() elimina cada secuencia con codificación porcentual. Una petición a /wp-login%2Ephp llegaba por eso como /wp-loginphp al control del inicio de sesión oculto, y el formulario de acceso se servía igualmente. El inicio de sesión oculto, el detector de escaneos y las rutas señuelo leen ahora la dirección original de la petición y la decodifican una vez. El firewall usa el mismo resolvedor de rutas.
Seis hallazgos más en la misma versión
- Un prefijo CIDR mal formado hacía que la protección previa a WordPress coincidiera con cualquier dirección, así que una sola fila rota de la lista blanca habría dejado pasar todas las peticiones.
- Un método 2FA enviado nunca se comprobaba contra la política del sitio. Un método que la política ya no permitía seguía iniciando la sesión del usuario si su secreto seguía guardado.
- Los códigos TOTP no eran de un solo uso. Un código interceptado en tránsito seguía siendo válido durante el resto de su intervalo. Hive registra ahora el intervalo aceptado, como recomienda el RFC 6238.
- Las dos rutas REST públicas de 2FA terminan en
wp_set_auth_cookie()y aceptaban llamadas desde otros orígenes. Ahora las rechazan. - Los bloqueos y desbloqueos tardaban hasta cinco minutos en aplicarse porque el veredicto de acceso seguía en caché. Cada cambio de bloqueo la vacía ahora.
- Una cabecera de IP del cliente de confianza sin fuentes de proxy se acepta de cualquier par. El comportamiento se mantiene por compatibilidad, pero guardar esa combinación muestra ahora un aviso.
Si tu sitio está detrás de un proxy inverso o una CDN, rellena el campo «Trusted Proxy Sources». Desde la 2.1.56 está en la tarjeta de conexión en ReportedIP Hive → Community.
¿Por qué MainWP dejó de mostrar las actualizaciones de Hive?
A partir de la 2.1.32, el comprobador de actualizaciones solo se creaba en peticiones de wp-admin, cron y WP-CLI. MainWP, ManageWP y paneles similares se sincronizan mediante peticiones del frontend, así que no podían listar ni instalar una nueva versión de Hive. Los sitios que dependían de un panel de gestión para actualizar se quedaban en versiones antiguas sin ningún aviso.
La 2.1.46 vuelve a crear el comprobador en cada petición y activa las actualizaciones automáticas de WordPress para el plugin. Un plugin de seguridad que va por detrás de sus propias correcciones no protege a nadie. Los sitios que deban fijar una versión recuperan el control manual con el filtro reportedip_hive_auto_update.
¿Cómo identifica Hive su instalación?
Desde la 2.1.45, cada petición a reportedip.com lleva la dirección del sitio, la versión del plugin y la versión de WordPress, en el formato User-Agent de las comprobaciones de actualizaciones de wordpress.org. En multisitio se envía la dirección de la red, así que una red cuenta como un solo dominio con licencia. Los datos de visitantes se limitan a la dirección IP y al tipo de evento de las amenazas detectadas. La comprobación de contraseñas en Have I Been Pwned solo recibe el nombre del producto y su versión.
La misma versión añadió la tarjeta «Licensed domains», que muestra cuántos dominios cubre tu plan y cuántos están en uso. Desde la 2.1.54 la tarjeta está en la página Community. Los sitios retirados se liberan en tu cuenta de reportedip.com en Dominios, y un dominio que deja de informar se libera automáticamente a los 60 días.
¿Qué es el registro de ajustes de Hive?
Antes de la 2.1.47, tres lugares validaban los ajustes de Hive por separado: la página de ajustes, el asistente de configuración y la importación. Una vía de escritura fuera de wp-admin, como un panel remoto o WP-CLI, no tenía ninguna validación.
La 2.1.47 los sustituyó por un único registro declarativo. Cada opción gestionada declara una sola vez su tipo, rango, valores permitidos, plan necesario y efectos secundarios, y cada vía de escritura valida a través de él. La regeneración de las reglas de reescritura para Hide Login y la 2FA del frontend se ejecuta ahora sea cual sea la vía que cambió el valor. El registro sobrevivió al asistente: desde la 2.1.54, la guía del Quickstart describe cómo se aplica a través de él una recomendación según el plan, y desde la 2.1.56 la página única Protection guarda cada tarjeta por el mismo proceso.
Encima funciona un protocolo versionado de ajustes remotos. Un panel lee el esquema de ajustes, lee los valores actuales y aplica un lote. Cada clave devuelve su propio resultado, así que una opción ligada a un plan se marca como omitida en lugar de hacer fallar todo el envío.
¿Cómo funciona la gestión de flota de Hive?
La 2.1.48 convirtió ese protocolo en una función. Defines una política de seguridad una vez, sustituyes campos sueltos donde un sitio necesita otra cosa y la envías. En el lanzamiento, la política cubría 63 ajustes en siete grupos. El registro ha crecido con cada versión, y un sitio con la 2.1.67 expone 190 ajustes a la gestión de flota.
Cada sitio conectado envía en cada llamada a la API una huella de sus ajustes gestionados. Si cambias un valor directamente en un sitio, aparece como desviado hasta que vuelvas a enviar. Una vista de comparación pone el valor objetivo junto al valor que el sitio tiene de verdad, consultado en directo.
| Pregunta | MainWP | Flota de reportedip.com |
|---|---|---|
| Dónde gestionas las políticas | Tu propio panel de MainWP | Tu cuenta de reportedip.com en Dominios |
| Plan | Sin requisito de plan | Business o Enterprise |
| Interruptor en el sitio | Ninguno | Interruptor de gestión de flota en la nube |
| Autenticación | Conexión de MainWP Child | Petición firmada con Ed25519 |
El puente de MainWP viene incluido en Hive, así que un sitio conectado mediante MainWP Child no necesita ningún plugin adicional. La documentación de la integración con MainWP enumera lo que informa el puente. El panel de flota de reportedip.com funciona sin MainWP y forma parte del plan Business.
Para dar acceso al panel de flota, abre ReportedIP Hive → Community y activa «Cloud fleet management via reportedip.com» en la tarjeta de conexión. Hasta la 2.1.56, el interruptor estaba en la pestaña General de los ajustes. El sitio aparece en el panel con su siguiente petición a la API. La documentación de la flota en la nube recoge los requisitos, y la guía de seguridad multisitio explica cómo se aplican los ajustes en una red.
Cómo se protege el transporte en la nube
Dejar que un servicio escriba ajustes en tu sitio solo es aceptable si el sitio puede comprobar quién lo pide. El transporte está desactivado por defecto, y cada petición tiene que superar siete comprobaciones antes de que se escriba nada.
- El propietario del sitio lo activa. Sin el interruptor, el modo Community Network y una Community Access Key, se rechaza cada petición.
- Limitación de frecuencia por IP en el sitio.
- Una firma Ed25519 (RFC 8032) sobre la carga exacta, verificada con una clave pública incluida en el plugin. La clave privada nunca sale del servicio.
- Una ventana de validez de cinco minutos para la marca de tiempo de la petición.
- Identificadores de petición de un solo uso, para que una petición interceptada no pueda repetirse.
- Una vinculación al destinatario, para que cualquier otro sitio rechace un sobre dirigido a un sitio concreto.
- Una prueba derivada de la clave de acceso del propio sitio, que vincula la petición a la cuenta propietaria del sitio.
La 2.1.49 añadió una propiedad más. Una petición con firma incorrecta y una petición a un sitio que nunca activó la función reciben ahora el mismo error genérico, así que un escaneo de Internet ya no revela qué sitios tienen activa la gestión de flota. El sitio anota el motivo real en su registro de seguridad.
¿Qué correcciones menores incluyó la serie?
- Activar el plugin ya no falla con un error fatal cuando Extended Protection está activo, lo que también afectaba a la activación en red.
- Los inicios de sesión XML-RPC fallidos con contraseña de aplicación contaban dos veces para el umbral de fuerza bruta. Ahora un intento cuenta una vez.
- El filtro de tipo de evento de los registros conoce App Password Failed.
- Los puntos destacados de la versión en el aviso de actualización ya no se cortan a mitad de frase.
- El botón «Reset API statistics» no hacía nada en el Security Dashboard, porque su controlador solo estaba vinculado en la página System Status.
- Las páginas de administración ya no se desplazan hacia los lados en el móvil. Las tablas se desplazan dentro de su propio contenedor, y las cabeceras de las tarjetas saltan de línea.
¿Cómo obtengo estos cambios hoy?
Todas las versiones desde la 2.1.49 los incluyen, y desde la 2.1.46 Hive instala sus propias actualizaciones mediante las actualizaciones automáticas de WordPress. Para obtener ya la versión actual, abre Plugins y haz clic en «Comprobar si hay actualizaciones» en la fila de Hive, o actualiza desde tu panel de gestión. Para una instalación nueva, descarga el ZIP actual desde la página del producto Hive.
No hace falta cambiar la configuración. La gestión de flota en la nube sigue desactivada hasta que la actives en cada sitio. Si un sitio usó alguna versión entre la 2.1.32 y la 2.1.45, comprueba una vez a mano la versión instalada, porque un panel de gestión puede haber mostrado un número desfasado.
Preguntas frecuentes
¿Qué plan necesito para la gestión de flota en la nube?
La gestión de flota desde reportedip.com necesita el plan Business o Enterprise, Hive 2.1.48 o posterior, el modo Community Network y una Community Access Key. Además, el propietario del sitio tiene que activar el interruptor en la página Community. Los ajustes que el plan del sitio no cubre se omiten en un envío, nunca se imponen.
¿Por qué mi sitio no aparece en el panel de flota?
Casi siempre el interruptor de gestión de flota en la nube sigue desactivado, que es el valor por defecto. Actívalo en ReportedIP Hive → Community, en la tarjeta de conexión. El efecto no es inmediato: el sitio se anuncia con su siguiente petición a la API de reportedip.com, y tiene que funcionar en modo Community Network.
¿Puede un escáner saber si mi sitio usa la gestión de flota?
Desde Hive 2.1.49 ya no puede. Una petición a un sitio sin la función y una petición con firma no válida reciben el mismo error de autenticación genérico, con el estado HTTP 401. El sitio escribe el motivo real en su propio registro de seguridad, así que sigues viendo los intentos fallidos mientras los demás no averiguan nada.