Un bypass de autenticación del Rejetto HFS hallado por IA atrae intentos de explotación

Los atacantes empezaron a sondear una vulnerabilidad crítica de omisión de autenticación en Rejetto HTTP File Server (HFS) el 1 de octubre de 2026, un día después de que Horizon3.ai publicara los detalles técnicos que la explican. La vulnerabilidad, registrada como CVE-2026-61500, tiene una puntuación CVSS de 9,3 y permite a un atacante remoto falsificar una sesión de administrador en un servidor sin parchear y alcanzar después la ejecución remota de código. Rejetto lanzó una corrección en julio, en la versión 3.2.1. Existía un parche funcional desde hacía más de dos meses antes del primer sondeo registrado, y esa brecha es la parte de la historia que merece atención.

Lectura relacionada: Una falla de lectura de archivos con CVSS 9,3 de Atlassian atrae explotación en horas · Google corrige CVE-2026-58704, una vulnerabilidad de día cero del módem de Pixel explotada activamente.

El modelo Mythos de Anthropic ayudó a encontrar el fallo. Eso convierte a CVE-2026-61500 en un ejemplo claro de dos tendencias que avanzan a la vez: el descubrimiento de vulnerabilidades asistido por IA, por un lado, y el trabajo lento y desigual de parchear software expuesto a internet, por el otro.

HFS es un servidor de archivos ligero y de código abierto que un administrador ejecuta para mover archivos por HTTP, a veces en una máquina accesible desde internet. Esa ubicación es lo que hace grave un fallo de falsificación de sesión. Un atacante que consigue el rol de administrador obtiene el control de la configuración del servidor y de las operaciones con archivos. Un simple listado de directorios sería un problema mucho menor. La función server_code convierte ese control en ejecución de código.

Qué permite hacer la vulnerabilidad a un atacante

El fallo es un problema de falsificación de sesión con un generador de números aleatorios débil en su raíz. Las versiones 3.0.0 a 3.2.0 de HFS derivan la clave de firma de sus cookies de sesión de la función Math.random() de JavaScript, que nunca se diseñó para guardar un secreto. Esas mismas versiones también entregan salidas de ese generador a clientes no autenticados durante el proceso de inicio de sesión. (Aviso de GitHub)

Esas dos decisiones juntas abren la puerta. Un atacante remoto puede recopilar un pequeño número de respuestas de inicio de sesión, reconstruir el estado interno del generador a partir de los valores filtrados, recuperar la clave de firma de las cookies y firmar una cookie de sesión de administrador válida. No se necesita robar credenciales. Math.random() es un generador pseudaleatorio, y los generadores pseudaleatorios son deterministas: sus salidas son función de un algoritmo conocido y una semilla desconocida, así que suficientes salidas observadas pueden revelar el estado y predecir el resto.

Una omisión de autenticación así es más difícil de defender que una contraseña débil. Un problema de contraseñas se puede responder con un secreto más largo o un segundo factor; aquí el propio secreto se deriva de una fuente predecible, así que la política de contraseñas no ayuda. El atacante nunca tiene que adivinar nada que un defensor pueda reforzar.

Desde una sesión de administrador, la documentada función server_code aporta el paso siguiente. Esa función permite a un administrador definir puntos de conexión personalizados que ejecutan JavaScript en el servidor, una forma legítima de extender HFS y, en este caso, una vía hacia la ejecución remota de código para cualquiera que haya falsificado una sesión de administrador. La vulnerabilidad está valorada con 9,3 en el sistema común de puntuación de vulnerabilidades, una banda reservada a fallos alcanzables de forma remota que conducen a un compromiso total.

La causa raíz es un error anterior a este incidente que lo sobrevivirá. Node.js incluye crypto.randomBytes() para la aleatoriedad sensible a la seguridad, y el consejo estándar para quien toque el código de HFS es derivar las claves con un generador criptográficamente seguro en lugar de con Math.random().

La corrección de la versión 3.2.1 cierra el agujero en HFS. Merece la pena buscar el mismo error en otros sitios: el código que recurre a Math.random() para construir un token, una clave o un identificador de sesión arrastra la misma clase de fallo.

El modelo que la encontró

El investigador de Horizon3.ai Zach Hanley dijo en una divulgación publicada el 30 de septiembre de 2026 que el modelo Mythos de Anthropic encontró la vulnerabilidad como parte del Proyecto Glasswing, el esfuerzo de Anthropic por usar IA de frontera para encontrar y corregir fallos en software crítico. Security Affairs informó de que la vulnerabilidad se publicó a través de la CNA de VulnCheck el 13 de julio de 2026. TechTimes informó de que la clave de firma se recuperó con el solucionador Z3. (Divulgación de Horizon3.ai, Security Affairs)

Z3 es un solucionador de propósito general usado en el análisis de programas. Aplicarlo a la salida del generador convierte la reconstrucción del estado en un problema abordable. El Proyecto Glasswing, el programa de Anthropic para dirigir modelos de frontera hacia software crítico, es el marco de este hallazgo. La propuesta que subyace a estos programas es sencilla: un modelo puede leer más código que un equipo de auditoría y no se cansa. Si eso produce un flujo constante de fallos graves corregidos es una pregunta aparte, y los recuentos de VulnCheck son una de las pocas formas públicas de comprobarlo.

El ángulo de la IA invita a una afirmación mayor de lo que sostienen las pruebas. VulnCheck ha contabilizado 75 CVE que mencionan a «Anthropic», 40 de ellos atribuidos a investigadores de Anthropic y solo uno atribuido explícitamente a Glasswing. Son los recuentos de VulnCheck, y cambiarán a medida que se presenten más divulgaciones. Un único hallazgo acreditado es un resultado real. Todavía no es una trayectoria consolidada, y por sí solo no demuestra que la IA haya cambiado la rapidez con que se encuentran los fallos críticos.

Por qué un parche de julio no detuvo el sondeo de octubre

La ventana entre el parche y los primeros intentos de explotación es donde el incidente se vuelve incómodo. Rejetto lanzó la corrección en la versión 3.2.1 en julio de 2026, y Security Affairs informó de que la vulnerabilidad se publicó a través de la CNA de VulnCheck el 13 de julio. La ayuda pública para explotarla llegó a finales de septiembre, cuando el investigador de seguridad Alejandro Ramos, conocido como aramosf, publicó una prueba de concepto en Python. (Prueba de concepto de aramosf)

Esa secuencia es habitual en el software expuesto a internet. Existe una corrección, pero un operador tiene que aplicarla. La divulgación y una prueba de concepto funcional reducen la habilidad necesaria para atacar, y un servidor parcheado sigue a salvo mientras que uno que no lo está se vuelve más fácil de golpear con cada semana que pasa. Como la prueba de concepto apareció antes del primer sondeo registrado, las herramientas para explotar la vulnerabilidad ya eran públicas cuando empezaron los intentos.

Las fechas no describen un error en la divulgación coordinada. La vulnerabilidad se publicó a través de una autoridad de numeración de CVE en julio, el mismo mes en que salió la corrección, y el análisis técnico de Horizon3 llegó a finales de septiembre. Lo que cambió a principios de octubre fue el alcance: un análisis público y una prueba de concepto funcional permitieron a un grupo mucho mayor de personas probar la vulnerabilidad.

Qué ha visto realmente VulnCheck

La telemetría de explotación es de VulnCheck, y su escala merece mantenerse en proporción. La firma detectó intentos de explotación el 1 de octubre de 2026, un día después de que Horizon3 publicara más detalles, y añadió CVE-2026-61500 a su propia lista de fallos explotados. Caitlin Condon, de VulnCheck, dijo que la actividad hasta ahora parecía un reconocimiento a pequeña escala. Una única dirección IP de China Telecom sondeó despliegues Canary en Japón y Estados Unidos. El servicio Target Intelligence de VulnCheck identificó alrededor de 100 instancias de HFS expuestas a internet. (The Hacker News)

Los despliegues Canary de VulnCheck son señuelos que la firma opera para observar ataques, así que los sistemas de su informe son señuelos, no servidores de clientes. La cifra de alrededor de 100 procede de su escaneo Target Intelligence y cuenta instancias expuestas a internet, no instancias confirmadas como vulnerables.

Esas cifras describen pruebas, no una oleada de servidores comprometidos. El reconocimiento puede ser la primera fase de un ataque, y una vulnerabilidad que concede acceso administrativo total no es para dejarla expuesta. Pero la etiqueta precisa para lo que VulnCheck observó a principios de octubre es sondeo. Alrededor de 100 instancias alcanzables es una población pequeña, y los despliegues Canary son señuelos en lugar de sistemas de producción, así que una única dirección de origen golpeándolos se parece más a un escaneo que a una campaña.

Esta es también la segunda vez que HFS atrae a atacantes. CVE-2024-23692, una vulnerabilidad valorada con 9,8, se utilizó como arma en julio de 2024 para distribuir mineros de criptomonedas, troyanos y un programa malicioso que los investigadores llamaron HATVIBE. La repetición sugiere que el conjunto de servidores HFS expuestos que atrajo a los atacantes hace dos años sigue siendo alcanzable.

El hallazgo por IA añade un matiz más reciente, y corta en ambos sentidos. Un modelo que lee código y detecta un fallo de derivación de claves puede encontrar un error más rápido de lo que los defensores esperarían. La misma cadena de publicación alimenta después avisos públicos y pruebas de concepto, que acortan el tiempo que los atacantes necesitan para explotar lo que siga sin parchear. La velocidad de descubrimiento y la de parcheo son problemas distintos. Solo uno de ellos ha mejorado aquí.

Salvedades

Las cifras de explotación proceden de la telemetría de VulnCheck, no de Rejetto ni de Anthropic, y describen lo que vio una red de monitorización. Los recuentos de 75 CVE y de un único Glasswing son los de VulnCheck y cambiarán. El relato de Horizon3 sobre el hallazgo de Mythos procede de la propia divulgación de la firma, y la verificación independiente de la contribución de un modelo a un descubrimiento concreto es difícil; Anthropic no ha publicado una lista completa de resultados de Glasswing.

Tampoco está claro cuántas de las alrededor de 100 instancias expuestas a internet ejecutan una versión vulnerable, cuántas se han parcheado desde julio o si alguno de los sondeos condujo a una intrusión con éxito. La descripción de VulnCheck apunta a reconocimiento, y ninguna fuente de este artículo informa de un compromiso confirmado de una víctima identificada.

La telemetría de VulnCheck muestra un reconocimiento a pequeña escala, una única IP de origen sondeando señuelos Canary y unas 100 instancias expuestas a internet, una base baja para una campaña masiva.

Qué hay que vigilar

Tres cosas mostrarán si esto se queda en una historia de sondeo. Primero, si VulnCheck u otras redes de monitorización informan de direcciones de origen adicionales o intrusiones con éxito, lo que llevaría la actividad del reconocimiento a la explotación. Segundo, si los operadores de HFS actualizan, ya que una instancia expuesta y sin parchear mantiene la vulnerabilidad útil sin importar cómo se encontró el fallo. Tercero, si el Proyecto Glasswing produce más hallazgos acreditados, lo que convertiría un único ejemplo en evidencia sobre cuánto cambia la IA la investigación de vulnerabilidades.

La vulnerabilidad en sí no tiene nada de extraordinario: una clave de seguridad construida a partir de un generador que nunca debía guardar un secreto. Lo que hace que CVE-2026-61500 merezca seguimiento es el momento. Un modelo de IA la encontró, los desarrolladores la corrigieron en julio y los atacantes solo empezaron a probarla en octubre, después de que salieran los detalles y una prueba de concepto.

Crédito de imagen: rejetto, Wikimedia Commons, CC BY-SA 3.0.