ReportedIP Hive 2.1.41 — Bloqueo de salidas de Tor, proxies de confianza y un widget de seguridad para el Dashboard
ReportedIP Hive 2.1.41 incorpora el bloqueo opcional de nodos de salida de Tor, rangos de origen de proxies de confianza y un widget de seguridad directamente en el Dashboard de WordPress. Esta versión pone el broche final a una serie de cinco lanzamientos que también han subsanado dos brechas reales en el cortafuegos: versiones que se distribuían sin sus conjuntos de reglas incluidos y exenciones para rastreadores que aceptaban sin más un agente de usuario no verificable.
Descarga la actualización a través de «Plugins» → «Buscar actualizaciones» o desde la página de GitHub Releases; el hito relacionado con las llaves de hardware que precedieron a esta versión se trata en el informe de la versión 2.1.36.
¿Qué ha cambiado entre las versiones 2.1.37 y 2.1.41 de Hive?
Se han publicado cinco versiones en nueve días, entre el 6 de agosto de 2026 y el 14 de agosto de 2026. Tres de ellas son pequeñas y puntuales; las versiones 2.1.40 y 2.1.41 son las más importantes.
| Versión | Cambio en el titular |
|---|---|
| 2.1.37 | Traslado del dominio a ReportedIP.com: todos los enlaces, el endpoint predeterminado de la API y las direcciones de contacto; la migración v14 reescribe un endpoint predeterminado almacenado, mientras que el dominio anterior mantiene una redirección permanente. |
| 2.1.38 | wp reportedip 2fa enable --method=totp Ahora genera y muestra un Secret en lugar de marcar un método que nunca podría verificarse; el proceso de verificación por correo electrónico o SMS envía un código en el primer intento, en lugar de rechazarlo. |
| 2.1.39 | Las versiones de lanzamiento vuelven a incluir los conjuntos de reglas WAF integrados —que antes no aparecían en absoluto— y, además, cuatro Firewall Rules contra la cadena XSS de la pantalla de Login relacionada con CVE-2026-64638. |
| 2.1.40 | Un agente de usuario de tipo «crawler» cuya identidad no pueda verificarse ya no podrá adquirir una exención de «block-ladder», y las solicitudes claramente maliciosas supondrán la revocación inmediata de dicha exención. |
| 2.1.41 | Bloqueo de nodos de salida de Tor, rangos de origen de proxies de confianza, un widget de seguridad para wp-admin, una opción de veto «nunca bloquear» para la infraestructura verificada, una búsqueda de direcciones IP más completa y contadores de intentos a prueba de conflictos. |
Ahora es posible bloquear los nodos de salida de Tor al realizar Login
Las instalaciones profesionales cuentan con un nuevo botón de activación/desactivación en la pestaña «Protección» que rechaza los intentos de Login procedentes de nodos de salida de Tor conocidos. La lista de nodos de salida se proporciona como un nuevo tor_exits conjunto de reglas a través de la Rule Sync habitual y se actualiza dos veces al día en el servidor, de modo que se mantiene al día a medida que van rotando los nodos de salida; en el caso de las direcciones que la lista aún no ha detectado, la comunidad isTor interviene.
Se han incorporado dos límites deliberados. Los bloqueos son temporales —24 horas por defecto, ajustables mediante el reportedip_hive_tor_block_hours filtro—, y un bloqueo de Tor nunca se comunica a la comunidad, ya que el hecho de operar un nodo de salida no constituye prueba de abuso. La opción sanciona un comportamiento en tu sitio web, no la participación en la red Tor.
Los rangos de origen de proxy de confianza cierran una vulnerabilidad relacionada con el Spoofing de encabezados
Si tu sitio web está protegido por Cloudflare o un proxy inverso, Hive lee la dirección del visitante a partir de un encabezado reenviado. Hasta ahora, cualquier persona que se conectara directamente al origen podía enviar ese encabezado por sí misma y, de este modo, suplantar una dirección incluida en la lista Whitelist u ocultar una bloqueada.
La versión 2.1.41 solo tiene en cuenta el encabezado de IP de confianza cuando el par que se conecta es una de las direcciones proxy que hayas declarado (una lista de IP/CIDR en Configuración → General). Una lista vacía mantiene el comportamiento anterior, por lo que no se produce ningún fallo tras la actualización. La misma comprobación de rango está integrada en el filtro previo a WordPress, que ahora también aplica el requisito de dirección pública a las direcciones candidatas del encabezado, lo que elimina una discrepancia con el resolutor integrado en WordPress.
El cortafuegos dejó de creer a pies juntillas a los rastreadores
La versión 2.1.40 corrige el problema más grave detectado en esta ejecución. La Allowlist del rastreador contiene 71 tokens de agente de usuario, pero el bot_signatures conjunto de reglas solo incluye reglas de verificación para unos pocos de ellos. Para cada token restante, el verificador devolvía unmatched — y is_exempt_crawler() consideraba que cualquier cosa que no fuera una confirmación fake como un resultado satisfactorio. Por lo tanto, bastaba con identificarse como GPTBot, PerplexityBot o UptimeRobot para eludir la escala de bloqueos y mantenerse al margen de las denuncias de la comunidad. En un sitio de producción, se omitieron 47 bloqueos en tres días —todos y cada uno de ellos por una solicitud que sondeaba /.env, /config.php.bak o /ssl/server.key procedente de un rango de la nube que no pertenecía a ninguno de los user-agents que se alegaban.
Una exención requiere ahora una regla que envíe una señal de verificación real —un sufijo de Reverse DNS o un rango de IP oficial— y un veredicto que no sea fake. Para que el conjunto verificable siga teniendo sentido en las instalaciones gratuitas, la línea de base incluida ha incorporado Baiduspider, LinkedInBot y Amazonbot, todos ellos verificables únicamente mediante Reverse DNS.
La segunda parte de la solución: las solicitudes claramente maliciosas anulan la exención de forma definitiva. Un impacto en un Honeypot, un impacto en una ruta señuelo o una coincidencia del WAF en los grupos de reglas de carga útil (recorrido de rutas, sondeo de archivos, inyección de comandos y PHP, webshell, Log4Shell, XXE, SSTI, NoSQL, CRLF, SSRF) ahora deniega la exención al rastreador y se registra como bot_exemption_denied. Las reglas de SQL Injection y XSS mantienen deliberadamente el funcionamiento habitual: los términos de búsqueda y el contenido del editor sí activan esos patrones, y no se debe bloquear el acceso a un cliente que busque un código de producto por ese motivo.
Esos mismos grupos de Payload ahora también bloquean tras el primer impacto, en lugar de esperar al umbral predeterminado de tres. El umbral existe para que un False Positive solo cueste una solicitud y nada más; sin embargo, la carga de un webshell no presenta una superficie de False Positives que merezca la pena proteger, por lo que esperar solo le daba ventaja al escáner. Se puede filtrar mediante reportedip_hive_waf_immediate_block_groups.
2.1.39: volver a incluir los conjuntos de reglas empaquetados en la versión final
Esto merece una confesión sincera. El proceso de lanzamiento se llevó a cabo includes, admin, assets, templates y languages — pero no data, que es donde residen los cuatro conjuntos de reglas de referencia. En una copia de la versión instalada, Rule_Sync::load_baseline() no encontró ningún archivo y devolvió un conjunto vacío, por lo que el cortafuegos se retiró antes de inspeccionar nada; las firmas de bots y la lista de dominios desechables estaban vacías por la misma razón.
Las instalaciones que sincronizan conjuntos de reglas desde la API no se vieron afectadas, ya que un conjunto de reglas almacenado sustituye a la línea de base en lugar de fusionarse con ella —y esa es precisamente la razón por la que esto pasó desapercibido: las instalaciones conectadas que se supervisan funcionaban correctamente, mientras que las instalaciones en modo local y las no conectadas ejecutaban un cortafuegos inactivo. Tanto el flujo de trabajo de lanzamiento como la compilación local ahora pasan por una fase de preparación data y se interrumpen si falta alguna de las cuatro líneas de base en el árbol preparado. Si utilizas Hive en modo «Local Shield», actualízalo cuanto antes.
En esa misma versión se añadieron cuatro reglas de «Paranoia-Level-1» contra el CVE-2026-64638 (XSS2Shell), la cadena de ataque de la pantalla de Login de WordPress publicada el 6 de agosto de 2026. La cadena no requiere ni una etiqueta <script> ni un manejador de eventos — introduce HTML plano a través de un diferencial de análisis de los sanitizadores y deja que un atributo id sobrescriba una variable global de JavaScript. waf_xss_login_markup rechaza un valor de login que contenga un ángulo (nunca legítimo — sanitize_user() los elimina), waf_xss_tag_differential detecta la propia primitiva de clobbering y cubre así toda la clase de fallo en lugar de un único aviso, y dos reglas complementarias cierran la escalada Same-Origin-Method-Execution. Medido contra 12 variantes de ataque y 34 peticiones legítimas: 12 bloqueadas, 0 falsos positivos. Esto es defensa en profundidad, no un sustituto del parche — sigue siendo necesario WordPress 7.0.3 o la versión corregida de la rama en uso.
El Dashboard de wp-admin por fin muestra lo que está haciendo Hive
Un nuevo widget de seguridad (admin/class-dashboard-widget.php) muestra en la página principal de wp-admin los ataques bloqueados en los últimos 30 días, los bloqueos de hoy, los bloqueos de IP activos, las capas de protección activadas y la puntuación de detección, con enlaces directos al plugin. En Multisite, el widget aparece en el Dashboard de la red y, para los superadministradores, en los paneles de control de los subsitios con cifras correspondientes a toda la red.
Junto a ello se introducen tres pequeños cambios en la visualización. Una barra de estado de la API en el Dashboard resume de un solo vistazo el estado de la conexión, la cuota (con cuenta atrás para el restablecimiento) y el Rate Limit, utilizando únicamente datos almacenados en caché. La visualización de la cuota diaria se mantiene actualizada entre ejecuciones de cron mediante la lectura de los encabezados X-RateLimit que la API ya envía en cada respuesta. Además, tras una actualización, las páginas de los complementos muestran un banner de «Novedades» que se puede cerrar una sola vez y que destaca lo más relevante del lanzamiento (includes/class-whats-new.php); el cierre es específico para cada usuario, y el banner nunca bloquea la página cuando no se puede acceder al feed.
Las direcciones IP pasaron a ser elementos de primer orden en el panel de administración
Cada dirección IP de las tablas de registros, bloqueadas, Whitelist y principales atacantes incluye ahora una copia, una búsqueda interna y un enlace externo a su página de perfil pública en ReportedIP.com; los principales atacantes cuentan ahora con acciones integradas de «Bloquear» y «Desbloquear». La propia pestaña de búsqueda se ha ampliado: ahora muestra el ISP, el ASN, el tipo de uso, el dominio, los informantes distintos y la hora de la última notificación; señala los nodos de salida de Tor y la infraestructura verificada por la comunidad; y ofrece acciones rápidas de «Bloquear» y «Añadir a la Whitelist» en la ficha de resultados.
wp reportedip lookup(includes/class-lookup-cli.php) incorpora la misma función de búsqueda a WP-CLI con salida en formato de tabla, JSON, CSV y YAML.- Una herramienta de «añadir mi IP» en el formulario de Whitelist añade tu dirección actual a la lista Whitelist con un solo clic; en el caso de IPv6, rellena automáticamente la red /64, de modo que los prefijos residenciales rotativos dejen de bloquear el acceso a sus propietarios. Ahora, al bloquear tu propia IP actual, se te pedirá primero una confirmación.
- El registro de eventos ahora cuenta con un filtro de intervalo de fechas, y la acción de fila «bloquear del registro» ofrece la posibilidad de seleccionar una duración en lugar de las 24 horas fijas.
La infraestructura verificada nunca se bloquea, y los integradores cuentan con un punto de conexión estable
Cuando el servicio de reputación marca una dirección como «infraestructura supervisada» —rastreadores de motores de búsqueda, principales CDN, flotas de monitorización—, Hive ya no aplica un bloqueo local a dicha dirección, ni desde la ruta de reputación ni desde la escala de bloqueo automático, y registra infrastructure_spared en su lugar. Los informes siguen enviándose: los bloqueos son consecuencias, los informes son pruebas.
Para las integraciones con Webhooks, SIEM y Slack, ahora hay un único punto de conexión estable: reportedip_hive_threshold_exceeded se activa con cada detección confirmada por un sensor, independientemente de la configuración de bloqueo automático y de notificaciones. La acción documentada reportedip_hive_report_queued ahora existe realmente (se activa una vez por cada informe que entra en la cola de la API), y la página de bloqueo ha ganado reportedip_hive_access_denied además un reportedip_hive_blocked_page_strings filtro para las sustituciones de texto de White-label.
Correcciones que conviene conocer: títulos de correos invisibles, contadores de carreras, cachés obsoletos
La corrección más evidente se refiere a los correos electrónicos de notificación y de 2FA. La celda del encabezado solo tenía color mediante un degradado CSS; GMX Webmail y Outlook para Android linear-gradient(), lo que dejaba el texto de la cabecera en blanco sobre una celda blanca y permitía que los filtros antispam calificaran el mensaje con HTML_FONT_LOW_CONTRAST. Ahora, el encabezado y el botón de llamada a la acción tienen un fondo índigo liso (bgcolor atributo más background-color) y conservan el degradado como mejora progresiva; el logotipo SVG en línea, que ambos clientes mostraban como artefactos extraños, ha desaparecido. Informado por Benjamin Grösch — gracias.
- Contadores de intentos a prueba de conflictos.
track_attempt()Ahora se trata de una única operación «upsert» atómica en una clave única(ip_address, attempt_type)(esquema v15, con limpieza de filas duplicadas), por lo que las ráfagas paralelas de intentos fallidos de Login ya no pueden perder recuentos debido a conflictos de «lectura y actualización». - El retroceso en el límite de rate se aplica por Endpoint. Un error 429 en la ruta de informe ya no detiene las consultas de reputación, y la ruta de informe ahora respeta el encabezado «Retry-After», que antes ignoraba.
- La caché de reputación tiene en cuenta el nivel de detalle y tus propios informes. Una entrada de caché sin detalles ya no satisface una consulta detallada, y un informe propio que se haya realizado con éxito invalida la reputación almacenada en caché, en lugar de mostrar datos con una antigüedad de hasta 24 horas.
- Los rangos CIDR se aceptan en el formulario de bloqueo manual: las capas de aplicación los admiten desde la versión 2.1.32 y, ahora, la validación del formulario también los admite.
- Las opciones exclusivas de WooCommerce aparecen atenuadas si no se tiene instalado WooCommerce, con una nota explicativa en lugar de un botón de activación/desactivación que no sirve para nada, y la URL de contacto de la página bloqueada en Multisite vuelve a funcionar en toda la red.
- Accesibilidad. Los anillos de enfoque se mantienen en el modo de alto contraste de Windows; los bloques de colores forzados y de movimiento reducido abarcan todo el sistema de diseño de la área de administración; los botones con iconos cumplen con los objetivos táctiles de 40 píxeles para punteros de gran tamaño; las notificaciones AJAX se anuncian a través de una zona activa discreta; y unas 90 cadenas de JavaScript de la área de administración que antes estaban codificadas de forma rígida ahora son traducibles.
Cómo actualizar a Hive 2.1.41
El verificador de actualizaciones integrado consulta GitHub cada 12 horas; para descargar la versión inmediatamente, abre «Plugins» → «Buscar actualizaciones». Los requisitos no han cambiado: WordPress 5.9+ y PHP 8.1+. No es necesaria ninguna migración manual: la rutina de actualización ejecuta automáticamente la migración v14 (que reescribe un punto final de API predeterminado almacenado a reportedip.com) y el esquema v15.