Skip to main contentSkip to footer
Comunicados

ReportedIP Hive 2.1.49: auditoría de seguridad, estándar de ajustes y gestión de flota

Actualizado Patrick Schlesinger
ReportedIP Hive 2.1.49 release card: nine security findings closed, 63 settings in one fleet policy, eight releases since 2.1.41

Entre el 14 y el 26 de agosto de 2026 se publicaron ocho versiones. La serie empieza con una versión de seguridad que cerró tres elusiones demostradas en el cortafuegos y en la capa 2FA, y termina con la gestión de flota: una política de seguridad, aplicada a todos los sitios que gestiona, desde MainWP o desde su cuenta de reportedip.com.

Qué cambió entre Hive 2.1.41 y 2.1.49

  • 2.1.44 cerró nueve hallazgos de seguridad, tres de ellos elusiones demostradas del control de bloqueo, del cortafuegos y del inicio de sesión con 2FA.
  • 2.1.45 hace que cada petición a la API identifique su instalación igual que lo hacen las comprobaciones de actualización de wordpress.org, y añadió al panel una tarjeta de dominios con licencia.
  • 2.1.46 restableció las actualizaciones del plugin para los paneles de gestión remota, que no veían actualizaciones de Hive desde la 2.1.32.
  • 2.1.47 introdujo el registro de ajustes y un protocolo versionado de ajustes remotos, para que un panel pueda leer y aplicar los ajustes de Hive con validación por clave.
  • 2.1.48 añadió la gestión de flota en la nube para Business, un transporte firmado con Ed25519 que permite a reportedip.com aplicar políticas a sus sitios.
  • 2.1.49 reforzó ese punto de acceso para que quien llame sin autenticarse no pueda saber si un sitio ha activado la función.

Todo lo aquí descrito está en el plugin gratuito, salvo que una línea indique lo contrario. El motor de protección sigue siendo gratuito, como siempre.

La 2.1.44 cerró tres elusiones demostradas contra un sitio en producción

Esta versión surgió de una auditoría completa de la ruta de las peticiones. Tres hallazgos no eran teóricos. Cada uno se reprodujo en una instalación en funcionamiento antes de aplicar la corrección.

admin-ajax.php quedaba fuera del control de bloqueo

El control de direcciones IP y el cortafuegos se ejecutaban en init, pero admin-ajax.php se trataba como petición de administración y se omitía. Una dirección bloqueada podía seguir llamando a cualquier acción AJAX pública, y los plugins que exponen lógica por AJAX quedaban accesibles mientras esa misma dirección estaba excluida del sitio público. Ahora ambas capas inspeccionan el tráfico de admin-ajax.

Una excepción del cortafuegos podía ocultar todas las reglas posteriores

Las excepciones sirven para eximir una sola regla en una sola ruta. Un ámbito mal formado impedía que el motor evaluara las reglas siguientes, de modo que una única entrada errónea desactivaba en silencio parte del conjunto de reglas. La coincidencia de excepciones queda ahora acotada a cada regla y no puede interrumpir la evaluación.

Las sondas codificadas en porcentaje pasaban ante tres sensores

El detector de escaneo, la protección contra la enumeración de usuarios y la sonda de inicio de sesión oculto comparaban las rutas después de sanitize_text_field(), que deja intactos los escapes en porcentaje. Una petición a %2E%2E%2Fwp-config.php no coincidía con la lista del señuelo. La comparación de rutas se hace ahora sobre el valor descodificado.

Otros seis hallazgos en la misma versión

  • El método 2FA enviado nunca se comprobaba contra los factores realmente registrados por el usuario. Un inicio de sesión podía indicar un método que la cuenta nunca había configurado.
  • Los códigos TOTP no eran de un solo uso. Un código interceptado seguía siendo válido durante el resto de su ventana de 30 segundos.
  • Las dos rutas REST públicas de 2FA terminan en wp_set_auth_cookie() y aceptaban llamadas de origen cruzado. Ahora rechazan el envío de un formulario desde otro origen.
  • Los bloqueos y desbloqueos tardaban hasta cinco minutos en aplicarse porque la decisión de acceso estaba en caché. La caché se invalida con cada cambio de bloqueo.
  • Una cabecera de IP de cliente configurada se aceptaba desde cualquier interlocutor. Ahora los rangos de origen de proxy de confianza deciden si esa cabecera se lee siquiera.
  • Un prefijo CIDR mal formado hacía que la protección previa al arranque de WordPress coincidiera con todas las direcciones.

Si utiliza Hive en un sitio con puntos de acceso AJAX públicos o detrás de un proxy inverso, la 2.1.44 es la versión que no conviene saltarse.

Los paneles remotos no veían actualizaciones de Hive desde la 2.1.32

Un cambio de rendimiento en la 2.1.32 omitía el comprobador de actualizaciones en las peticiones del sitio público. MainWP, ManageWP y herramientas equivalentes se sincronizan justo por esas peticiones, así que nunca vieron una versión nueva de Hive y no podían ni informar de ella ni instalarla. Los sitios que dependían de un panel de gestión para actualizarse se quedaron en versiones antiguas sin ningún aviso.

La 2.1.46 vuelve a ejecutar el comprobador en todos los contextos de petición y activa las actualizaciones automáticas de WordPress para el plugin. Un plugin de seguridad que no puede actualizarse a sí mismo es un riesgo, así que esto ya no es opcional. Si su parque parecía actualizado entre la 2.1.32 y la 2.1.45, compruebe ahora la versión instalada.

Cada petición indica ahora de qué instalación procede

Desde la 2.1.45, cada llamada a la API lleva la dirección del sitio y las versiones del plugin y de WordPress, en el mismo formato que llevan años usando las comprobaciones de actualización de wordpress.org. En multisitio, la dirección de red se envía una sola vez, de modo que una red cuenta como un dominio y no como uno por cada subsitio.

El panel de seguridad incorporó una tarjeta de dominios con licencia que muestra cuántos dominios cubre su plan y cuántos están en uso. Los sitios retirados pueden liberarse desde el área de cuenta, y los dominios que dejan de comunicarse se liberan automáticamente a los 60 días. Los servicios de terceros nunca reciben esta identidad. La comprobación de contraseñas de HIBP, en particular, recibe únicamente el token de producto y nada más.

Un único estándar de ajustes para todo el que escribe

Los ajustes de Hive se validaban antes en cuatro sitios distintos. La página de ajustes tenía sus propias funciones de saneamiento, el asistente de configuración un segundo juego, la importación un tercero, y ninguno existía fuera de wp-admin. Una escritura remota podía llegar a la base de datos sin las comprobaciones que habría ejecutado el envío de un formulario.

La 2.1.47 sustituyó todo eso por un único registro declarativo. Cada opción gestionada declara una sola vez su tipo, su rango, sus valores permitidos, el plan que requiere y sus efectos secundarios. La página de ajustes, el asistente, la importación y todos los transportes remotos validan por la misma cadena, y el registro se carga en cualquier contexto de petición. El refresco de las reglas de reescritura y los reinicios de caché se disparan ahora para cualquiera que cambie el valor, incluido WP-CLI.

Por encima está un protocolo versionado de ajustes remotos. Un panel pide a un sitio su esquema de ajustes, lee los valores actuales y aplica un lote. Cada clave vuelve con su propio resultado, así que una opción sujeta a plan se informa como omitida en lugar de hacer fracasar todo el envío. El contrato está documentado en el repositorio del plugin y ambos paneles lo implementan.

Gestión de flota: una política para todos sus sitios

La 2.1.48 convirtió ese protocolo en una función. Defina una política de seguridad una vez, sobrescriba campos concretos donde un sitio necesite algo distinto y aplíquela. El panel gestiona 63 ajustes en siete grupos: umbrales de detección, bloqueo y escalado, nivel del cortafuegos, inicio de sesión oculto, política de 2FA, registro y retención, y notificaciones.

Cada sitio comunica en cada llamada a la API una huella de sus ajustes gestionados. Si cambia algo directamente en un sitio, aparece como desviado hasta que vuelva a aplicar la política. Una vista de comparación pone el valor objetivo junto al valor que el sitio tiene realmente, consultado en directo.

Hay dos maneras de manejarlo. El puente de MainWP viene dentro de Hive, así que un sitio conectado a su panel de MainWP se gestiona sin plugin hijo adicional y sin extensión de pago. El panel de flota de reportedip.com hace lo mismo desde su cuenta, en Dominios, y no necesita MainWP en absoluto. Ese forma parte del plan Business.

Cómo se asegura el transporte en la nube

Permitir que un servicio escriba ajustes en su sitio solo es aceptable si el sitio puede demostrar quién está preguntando. El transporte está desactivado de forma predeterminada y cada petición debe superar siete comprobaciones antes de que se escriba nada.

  • El propietario del sitio lo activa. Sin ese interruptor, el modo Community y una clave de acceso, toda petición se rechaza.
  • Limitación de frecuencia por IP en el sitio.
  • Una firma Ed25519 sobre la carga exacta, verificada con una clave pública incluida en el plugin. La clave privada nunca sale del servicio.
  • Una ventana de vigencia 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 reproducirse.
  • Una vinculación al destinatario, de modo que un sobre dirigido a un sitio sea rechazado por cualquier otro.
  • Una prueba derivada de la clave de acceso del propio sitio, que liga la petición a la cuenta propietaria del sitio.

La 2.1.49 añadió una propiedad más. Una petición que falla la comprobación de firma y una petición a un sitio que nunca activó la función reciben ahora el mismo error genérico, de forma que escanear Internet ya no revela qué sitios tienen activada la gestión de flota. El motivo real queda anotado en el registro de seguridad del sitio.

Correcciones menores que conviene conocer

  • La activación en red ya no provoca un error fatal en multisitio cuando la protección ampliada está activa.
  • Los inicios de sesión XML-RPC fallidos con contraseña de aplicación contaban doble en el umbral de fuerza bruta. Un intento en la red es ahora un intento.
  • El filtro de registros conoce el tipo de evento «App Password Failed».
  • Los aspectos destacados de la versión en el aviso de actualización se cortaban a mitad de frase cuando las notas eran largas.
  • El botón para reiniciar las estadísticas de la API en el panel de seguridad no hacía nada. Su controlador solo estaba asociado a la página «System Status».
  • Las páginas de administración ya no se desplazan lateralmente en el móvil. Las tablas se desplazan dentro de su propio contenedor y las cabeceras de las tarjetas se ajustan.

Cómo actualizar a Hive 2.1.49

Las actualizaciones llegan por la pantalla de actualizaciones habitual de WordPress. Desde la 2.1.46 las actualizaciones automáticas están activadas para el plugin, así que la mayoría de las instalaciones ya están en la 2.1.49 o llegarán a ella en un día. Para obtenerla de inmediato, abra la página de plugins y use el enlace de comprobación de actualizaciones, o actualice desde su panel de gestión.

No hacen falta cambios de configuración. La gestión de flota en la nube permanece desactivada hasta que la active sitio por sitio, y el ajuste de proxys de confianza mantiene su comportamiento anterior hasta que rellene los rangos de origen. Si tenía cualquier versión entre la 2.1.32 y la 2.1.45, compruebe una vez a mano la versión instalada, ya que su panel pudo haber informado de un número obsoleto.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Rellena este campo
Rellena este campo
Por favor, introduce una dirección de correo electrónico válida.
Tienes que aprobar los términos para continuar