Rejetto HFS CVE-2026-61500, explotada un día después de publicarse su análisis

Los atacantes empezaron a explotar CVE-2026-61500, un fallo crítico del servidor de archivos Rejetto HFS, el 3 de octubre de 2026. Fue un día después de que Horizon3.ai publicara cómo funciona, informa The Register. El error permite a cualquiera falsificar un inicio de sesión de administrador y luego ejecutar código en el servidor. Se descubrió con Mythos, el modelo de IA de Anthropic para buscar vulnerabilidades, y HFS 3.2.1 lo corrige.

Qué es Rejetto HFS y qué versiones están afectadas

HFS, abreviatura de HTTP File Server, es un programa gratuito y de código abierto que comparte archivos de un ordenador a través de un navegador web. Las versiones 3.0.0 a 3.2.0 son vulnerables, según el aviso de VulnCheck. La versión 3.2.1 es la primera corregida.

Las dos puntuaciones principales difieren ligeramente. VulnCheck califica el fallo con 9,3 sobre 10, mientras que la base de datos de CVE de Strix indica 9,8. Ambas lo sitúan en la franja crítica.

Detalle	Valor
Versiones afectadas	HFS 3.0.0 a 3.2.0
Versión corregida	HFS 3.2.1
Puntuación de gravedad	9,3 (VulnCheck) o 9,8 (Strix)
CVE publicado	13 de julio de 2026
Detalles del exploit publicados	2 de octubre de 2026
Primeros ataques detectados	3 de octubre de 2026

Cómo funciona el ataque

La causa de fondo es un generador de números aleatorios que no está pensado para secretos. HFS crea la clave que firma sus cookies de inicio de sesión con Math.random() de JavaScript. Según VulnCheck, HFS también «revela salidas del mismo generador a clientes no autenticados durante el inicio de sesión».

Esa combinación es el problema. En el motor V8 de Google, que ejecuta Node.js, Math.random() usa un algoritmo llamado xorshift128+. Es rápido, pero totalmente predecible. Cualquiera que vea suficientes salidas suyas puede deducir su estado interno y, a partir de ahí, cada número que producirá.

Por eso, un atacante inicia intentos de inicio de sesión y recoge los números filtrados. Según The Register, Horizon3 usó después Z3, una herramienta que resuelve ecuaciones automáticamente, para reconstruir el estado del generador. A partir de ahí, el atacante recupera la clave de firma y falsifica una cookie de administrador.

«Si un atacante puede deducir cuál es la clave de firma de sesiones, puede falsificar cookies de sesión válidas», dijo a The Register el investigador de Horizon3 Zach Hanley. El acceso de administrador lleva después a la ejecución de código mediante el propio ajuste server_code de HFS, según VulnCheck.

Lo que Mythos encontró y un escáner podría pasar por alto

Hanley atribuye a Mythos haber detectado la cadena, no solo el generador débil. Mythos se fijó en el generador inseguro y en la ruta de código separada que filtraba sus salidas. «Reconoció esos dos hechos como una cadena», dijo Hanley a The Register. Una herramienta que solo marque Math.random() informaría de una debilidad sin demostrar que pudiera explotarse.

Mythos es el modelo solo por invitación que Anthropic actualizó a Mythos 5.1 en septiembre. Se le atribuyen 286 CVE a 3 de octubre, informa The Register. The Register también cuenta este como el segundo fallo vinculado a Anthropic explotado en entornos reales desde que Horizon3 se unió a Project Glasswing, el programa de seguridad de Anthropic, en julio de 2026. VulnCheck atribuye el descubrimiento a Hanley en colaboración con Anthropic Research.

Quién está atacando

VulnCheck vio los primeros ataques el 3 de octubre contra servidores en Estados Unidos y Japón, procedentes de direcciones alojadas en China, informa The Register. Los intentos posteriores llegaron a través de servidores proxy en Estados Unidos.

El momento muestra lo poco que logra un parche por sí solo. El registro del CVE, que ya apuntaba a la corrección de la 3.2.1, data del 13 de julio. Sin embargo, en el momento de la publicación, el modelo EPSS, que estima la probabilidad de que un fallo se explote en un plazo de 30 días, situaba esa probabilidad en el 0,75 %, según VulnCheck y Strix. Los primeros ataques que vio VulnCheck llegaron solo cuando ya existían un análisis paso a paso y un vídeo.

Qué significa esto para los desarrolladores

Si usas HFS, actualiza ya a la 3.2.1. Cualquier servidor con 3.0.0 a 3.2.0 accesible desde internet debe tratarse como posiblemente comprometido. Revisa sus ajustes de administración, sobre todo server_code, en busca de cualquier cosa que no hayas añadido tú.

La lección más amplia es para cualquiera que escriba JavaScript. Nunca uses Math.random() para claves, tokens, ID de sesión ni restablecimientos de contraseña. En Node.js, usa crypto.randomBytes() o crypto.randomUUID(). En los navegadores, usa crypto.getRandomValues(). Después, busca en tu propio código Math.random( cerca de palabras como key, token, secret o session.

Comprueba también qué filtra tu aplicación. HFS era explotable porque enviaba salidas en bruto del generador a visitantes que no habían iniciado sesión. Los ID de aspecto aleatorio en páginas de error, respuestas de inicio de sesión o cabeceras pueden alimentar el mismo tipo de ataque.

Por último, no esperes al exploit para aplicar el parche. Una puntuación EPSS baja mide el interés de los atacantes antes de un análisis público, no después. Herramientas de IA como Mythos ya encuentran y explican fallos más rápido, así que es probable que el intervalo entre un análisis y el primer ataque siga siendo corto.