La vulnerabilidad HFS de Anthropic Mythos fue corregida, y luego llegaron los atacantes
Mythos de Anthropic ayudó a descubrir una vulnerabilidad crítica en HFS, pero la explotación reportada comenzó poco después de que los investigadores publicaran la cadena de ataque completa. La vulnerabilidad HFS de Anthropic Mythos permite que un atacante no autenticado reconstruya un secreto del servidor, falsifique una sesión de administrador y alcance la ejecución remota de código.
La falla, identificada como CVE-2026-61500, afecta a Rejetto HTTP File Server en las versiones 3.0.0 a 3.2.0. Rejetto la corrigió en la versión 3.2.1 en julio de 2026. Horizon3 publicó su análisis técnico detallado el 30 de septiembre, y VulnCheck detectó intentos de explotación al día siguiente.
Esta secuencia hace que sea algo más que otra historia sobre el descubrimiento de vulnerabilidades asistido por IA. Mythos no se limitó a señalar una función sospechosa. Según Horizon3, conectó debilidades separadas, modeló un generador de números aleatorios reversible, construyó las restricciones necesarias y produjo un exploit funcional.
La parte inquietante llegó después de la divulgación. Los defensores habían recibido un parche más de dos meses antes, pero los sistemas vulnerables aparentemente seguían accesibles cuando los mecanismos del exploit se hicieron públicos. Por lo tanto, la competencia central no enfrenta a Mythos con otro modelo de IA. Enfrenta la investigación acelerada de vulnerabilidades con el proceso más lento de identificar, actualizar y verificar software expuesto.
La vulnerabilidad HFS de Anthropic Mythos convierte la aleatoriedad en acceso de administrador
CVE-2026-61500 transforma una fuente débil de aleatoriedad en una vía no autenticada hacia el control administrativo completo.
Rejetto HFS es un servidor de código abierto para compartir archivos en la web. Su rama actual 3.x funciona sobre Node.js y utiliza Koa, un framework web de JavaScript, para gestionar solicitudes y sesiones web.
Una cookie de sesión indica a una aplicación web qué usuario autenticado está realizando una solicitud. El servidor firma esa cookie con una clave secreta para que un atacante no pueda modificar el nombre de usuario ni los privilegios sin invalidar la firma.
HFS creó su clave de firma predeterminada con la función Math.random() de JavaScript. Esta función es adecuada para comportamientos aleatorios ordinarios, pero no está diseñada para generar secretos criptográficos.
El problema iba más allá de la elección inicial del generador. HFS también exponía otros valores del mismo generador de números pseudoaleatorios durante parte de su proceso de inicio de sesión. Un generador de números pseudoaleatorios, o PRNG, produce una secuencia determinista a partir de un estado interno.
La divulgación técnica de Horizon3 indica que Mythos identificó ambos lados de esta relación. Detectó la generación débil de la clave de firma y una vía independiente no autenticada que revelaba salidas observables de la misma secuencia.
El modelo razonó entonces que suficientes salidas permitirían reconstruir el estado del generador. A partir de ahí, un atacante podría retroceder en la secuencia y reproducir los valores utilizados cuando HFS creó su clave de firma.
Esto no equivale a adivinar una contraseña mediante intentos repetidos de inicio de sesión. En su lugar, el atacante resuelve el estado interno de un sistema determinista. Una vez conocido ese estado, la clave supuestamente secreta se vuelve reproducible.
La cadena demostrada por Horizon3 comienza comprobando si existe el nombre de usuario integrado del administrador. A continuación, el atacante solicita repetidamente una operación de inicio de sesión para recopilar salidas expuestas de Math.random().
Los investigadores tomaron muestras del endpoint vulnerable 12 veces en el exploit descrito. Esas observaciones se convirtieron en restricciones para Z3, un solucionador de satisfacibilidad módulo teorías desarrollado por Microsoft.
Un solucionador SMT determina qué valores satisfacen un conjunto de condiciones lógicas y matemáticas. En este caso, ayudó a recuperar un estado coherente con las salidas aleatorias observadas y el comportamiento conocido de HFS.
El atacante puede entonces retroceder desde el estado recuperado hasta la secuencia de inicio del servidor. Esto revela los valores utilizados para construir la clave de firma de cookies.
Con esa clave, el atacante crea una cookie firmada correctamente que afirma representar al administrador. HFS acepta la sesión falsificada porque su firma es válida, aunque el administrador real nunca haya autenticado al atacante.
El acceso administrativo proporciona el último eslabón. HFS admite código personalizado del lado del servidor, por lo que un administrador puede configurar JavaScript que se ejecute en el host. Horizon3 utilizó esa capacidad legítima para demostrar la ejecución arbitraria de comandos.
La distinción importa. El comportamiento peligroso no depende de inyectar código malformado mediante un error accidental del analizador. Combina una identidad falsificada con una función que está disponible intencionalmente para los administradores.
La corrección de Rejetto aborda ambas fuentes de previsibilidad. La versión corregida utiliza bytes aleatorios criptográficamente seguros para la clave de firma y un UUID aleatorio para el identificador de inicio de sesión expuesto.
Los operadores deberían instalar la versión HFS 3.2.1 o una versión estable posterior. Establecer una clave de firma explícita y sólida puede reducir una parte del riesgo, pero actualizar elimina la cadena documentada y sigue siendo la respuesta adecuada.
Mythos encontró una cadena que los revisores humanos podrían haber abandonado
El resultado importante de Mythos no fue identificar `Math.random()`, sino demostrar que varios errores aparentemente ordinarios formaban un exploit práctico.
Las herramientas de análisis estático llevan años advirtiendo a los desarrolladores sobre generadores débiles de números aleatorios. Un escáner puede buscar Math.random() cerca de código de autenticación y marcar la línea para su revisión.
Esa observación por sí sola no demuestra un compromiso remoto. Un investigador todavía debe determinar si un atacante puede observar salidas relacionadas, reconstruir el generador, recuperar la clave exacta, falsificar el formato correcto de la cookie y convertir la autenticación en un impacto significativo.
Cada paso añade trabajo e incertidumbre. Esto a menudo cambia si un hallazgo recibe una investigación adicional, especialmente cuando los investigadores deben elegir entre muchas pistas posibles.
Horizon3 afirma que Mythos gestionó esa ruta de razonamiento más extensa. Su agente especializado en análisis criptográfico detectó que HFS consumía tres salidas aleatorias al crear la clave de firma durante el inicio.
El modelo también identificó una vía de inicio de sesión que devolvía valores de precisión completa producidos por el mismo generador. Reconoció que la cookie estaba firmada, pero no cifrada, lo que permitía al cliente leer sus propios datos de sesión.
Mythos conectó entonces esos hechos con la implementación xorshift128+ de V8. V8 es el motor de JavaScript utilizado por Node.js, y xorshift128+ mantiene un estado interno reversible.
La reversibilidad no hace automáticamente explotable a toda aplicación que utilice el generador. El atacante aún necesita suficientes observaciones útiles y una forma de correlacionarlas con la secuencia que genera el secreto.
HFS proporcionaba ambas condiciones. Exponía valores consecutivos mediante el flujo de inicio de sesión, mientras que la clave de firma procedía del mismo generador cuando se iniciaba el proceso.
El modelo propuso usar Z3 para recuperar el estado en lugar de intentar una búsqueda ingenua entre todas las claves posibles. También identificó una cookie y una firma existentes como mecanismo de verificación sin conexión.
Ese paso de verificación es significativo. Un candidato recuperado puede probarse localmente frente al código de autenticación de mensajes de una cookie legítima. El atacante no necesita enviar cada candidato al objetivo y generar solicitudes fallidas evidentes.
Según Horizon3, Mythos creó la prueba de concepto funcional y demostró la ejecución arbitraria de comandos. Los investigadores humanos revisaron el resultado antes de la divulgación, lo cual es esencial cuando el análisis de un modelo puede contener errores sutiles.
El informe más amplio sobre las capacidades de Mythos de Anthropic describe un énfasis similar en la explotación completa. La empresa sostiene que producir un exploit funcional ayuda a distinguir vulnerabilidades relevantes de fallos o código sospechoso que carece de impacto práctico.
Este enfoque puede mejorar la clasificación defensiva. Una vía confirmada hacia el acceso de administrador merece un tratamiento distinto de una advertencia aislada sin un desencadenante accesible.
También reduce la barrera económica para investigar clases de vulnerabilidades inusuales. Los investigadores de Horizon3 dijeron que los hallazgos criptográficos pueden quedar relegados porque demostrarlos requiere conocimientos matemáticos especializados y mucho tiempo.
Un sistema de IA que complete esos pasos puede hacer viable una investigación antes poco rentable. El conjunto de errores que merece investigarse crece cuando cae el costo marginal de crear y probar un exploit.
El exploit de Mythos contra HFS ilustra claramente ese cambio. Ningún ingrediente individual era inédito. La aleatoriedad débil, las salidas expuestas del generador, las cookies firmadas y las funciones administrativas privilegiadas son conceptos de seguridad establecidos.
El cambio reside en la síntesis. Según los informes, Mythos siguió la relación entre archivos, frameworks, comportamiento matemático y funciones de la aplicación sin requerir que los investigadores prescribieran cada paso intermedio.
Por eso también las afirmaciones simplistas sobre que la IA “encuentra un error” no captan la verdadera presión. El descubrimiento tiene valor, pero la construcción del exploit determina si un hallazgo se convierte en un problema operativo urgente.
La divulgación pública chocó con un ciclo de parcheo lento
El parche existía antes del análisis completo del exploit, pero los sistemas HFS expuestos públicamente supuestamente seguían siendo vulnerables cuando el método se volvió más fácil de reproducir.
Rejetto lanzó la versión 3.2.1 el 13 de julio de 2026. Los registros CVE identifican como afectadas las versiones 3.0.0 a 3.2.0.
Horizon3 esperó hasta el 30 de septiembre para publicar su desglose detallado. Ese retraso dio tiempo a los administradores para actualizar sin entregar a los atacantes una explicación completa de la vulnerabilidad.
La divulgación incluyó los mecanismos importantes. Describió la filtración de números aleatorios, la reconstrucción de estado, la recuperación de claves, la sesión de administrador falsificada y la transición a la ejecución de código.
VulnCheck comenzó a detectar intentos de explotación el 1 de octubre, según el tráfico de ataque observado. La actividad inicial supuestamente implicaba infraestructura alojada en China que apuntaba a sistemas vulnerables en Estados Unidos.
Las solicitudes posteriores procedían de dos direcciones estadounidenses de la misma subred, que parecían operar como proxies. Los investigadores también reportaron ataques dirigidos contra sistemas en Japón.
Estas observaciones respaldan la existencia de intentos de explotación activos, pero no establecen la identidad del atacante ni una afiliación gubernamental. La ubicación del alojamiento y la del proxy son señales débiles de atribución.
Tampoco revelan cuántos sistemas fueron comprometidos. Una detección puede mostrar que alguien envió tráfico relacionado con un exploit sin demostrar que el objetivo aceptó una sesión falsificada o ejecutó un comando.
Incluso con esas limitaciones, el momento importa. La primera actividad observada siguió a la explicación técnica pública aproximadamente un día después.
Esto no demuestra que los atacantes reprodujeran de forma independiente todos los pasos matemáticos durante ese período. Pueden haber desarrollado la técnica antes, adaptado material divulgado u obtenido suficiente información de los registros de vulnerabilidades existentes.
La lección operativa sigue siendo la misma. Una vez que la información detallada sobre un exploit se hace pública, los defensores deben asumir que actores capaces pueden convertirla rápidamente en tráfico de escaneo y ataques.
La política de divulgación de Anthropic busca equilibrar esas necesidades contrapuestas. Por lo general, establece la notificación a los mantenedores, un período de divulgación de 90 días y revisión humana de los informes originados por IA.
La política indica que Anthropic normalmente espera 45 días después de un parche antes de publicar los detalles técnicos completos. Ese margen busca dar tiempo a los usuarios posteriores para desplegar las correcciones.
CVE-2026-61500 tuvo un intervalo más largo entre su parche de julio y el análisis de Horizon3 en septiembre. La aparición de sistemas vulnerables tras ese intervalo demuestra por qué el momento de la divulgación no puede compensar una visibilidad incompleta de los activos.
Un servidor puede pasarse por alto porque se desplegó para una transferencia a corto plazo y nunca se incorporó a un inventario. Un contenedor puede permanecer anclado a una imagen antigua. Un servicio autoalojado también puede quedar tras una regla olvidada de reenvío de puertos.
HFS atrae precisamente estos casos de uso ligeros. Su accesibilidad facilita el intercambio de archivos, pero también puede fomentar despliegues fuera de la infraestructura gestionada de forma centralizada.
La historia del software concreta esa preocupación. Una vulnerabilidad anterior de HFS que afectaba a la antigua rama 2.x entró en el catálogo de Vulnerabilidades Explotadas Conocidas de CISA en 2024.
Ese problema anterior era una vulnerabilidad distinta en una base de código diferente. HFS 3.x se reescribió en TypeScript, mientras que la rama 2.x utilizaba Delphi.
El precedente no significa que todas las instalaciones de HFS estén comprometidas. Sí demuestra que los servidores de archivos expuestos a internet son objetivos atractivos, especialmente cuando la explotación conduce directamente a la ejecución de código.
Por lo tanto, la aplicación de parches necesita un paso de verificación. Los equipos de seguridad no deberían cerrar el ticket cuando se asigna una actualización. Deberían confirmar que cada instancia accesible informa de una versión corregida y que los contenedores o binarios antiguos ya no responden a solicitudes.
La verdadera competencia es el descubrimiento mediante IA frente a la velocidad de remediación
Mythos acelera el ritmo de la investigación de seguridad, pero la exposición de una organización sigue dependiendo de la rapidez con la que pueda localizar y actualizar sus sistemas.
Los programas de seguridad suelen medir la gestión de vulnerabilidades mediante recuentos. Los equipos informan de cuántos hallazgos abrieron, cuántos parches desplegaron o qué porcentaje cumplió un objetivo de nivel de servicio.
CVE-2026-61500 destaca un intervalo más trascendente. El reloj importante comienza cuando una corrección está disponible y termina cuando cada instancia vulnerable expuesta se actualiza, aísla o elimina.
La investigación asistida por IA reduce el tiempo necesario para convertir código fuente en una ruta de ataque validada. La divulgación pública hace entonces que esa ruta sea más barata de reproducir para otros investigadores y atacantes.
El proceso de aplicación de parches no se acelera automáticamente al mismo ritmo. Sigue dependiendo de registros de propiedad, ventanas de mantenimiento, pruebas, aprobación, despliegue y confirmación.
Esto crea una competencia asimétrica. Los investigadores pueden paralelizar el análisis entre repositorios, mientras que los defensores deben gestionar cada sistema de producción afectado dentro de su contexto empresarial.
La vulnerabilidad de Anthropic Mythos en HFS también demuestra por qué las puntuaciones de gravedad por sí solas son insuficientes. Una calificación crítica identifica el impacto potencial, pero no indica a una organización si la aplicación vulnerable es accesible desde internet.
Por el contrario, un pequeño servidor de intercambio de archivos puede recibir poca atención porque solo da servicio a unos pocos usuarios. Si permite ejecución remota de código sin autenticación, su modesto perfil empresarial no reduce su utilidad como punto de entrada.
La respuesta adecuada comienza con el descubrimiento. Los equipos deberían buscar Rejetto HFS en inventarios de software, registros de contenedores, cargas de trabajo en la nube, despliegues de endpoints y servicios accesibles externamente.
Deberían diferenciar la rama 3.x de las versiones antiguas de HFS porque las correcciones y los mecanismos de vulnerabilidad difieren. Cualquier instalación compatible de 3.x debería ejecutar la versión 3.2.1 o posterior, aunque es preferible la versión estable más reciente.
Los controles de red aportan otra capa. Una instancia de HFS destinada a un grupo limitado no debería permanecer abierta a todo internet cuando el acceso puede restringirse mediante una VPN, una lista de permitidos o una puerta de enlace autenticada.
Esos controles no sustituyen la actualización. Un endpoint de confianza comprometido, un error de configuración o un cambio futuro de red pueden exponer un servicio que los administradores creían aislado.
Los equipos también deberían revisar los registros del servidor en torno a la fecha de divulgación pública. Las llamadas repetidas a endpoints de autenticación, las sesiones inesperadas de administrador, los cambios de configuración y el código del lado del servidor desconocido merecen investigación.
Un atacante exitoso podría modificar más que la configuración visible de HFS. La ejecución remota de código puede permitir persistencia mediante cuentas del sistema operativo, tareas programadas, scripts de inicio o servicios adicionales.
Por esa razón, aplicar parches a un host confirmado como comprometido no es suficiente. Los equipos de respuesta deberían aislarlo, preservar pruebas, rotar las credenciales pertinentes, evaluar los recursos conectados y reconstruirlo cuando no pueda establecerse la integridad del sistema.
Las implicaciones defensivas van más allá de HFS. Los desarrolladores deberían considerar inaceptables los generadores seudoaleatorios de propósito general como fuentes de secretos de autenticación, tokens de restablecimiento, nonces criptográficos e identificadores de sesión.
La revisión de código debería examinar las relaciones de estado compartido, no solo las llamadas individuales. Un secreto seguro puede seguir siendo predecible si el mismo generador filtra salidas correlacionadas en otra parte.
Los valores predeterminados de los frameworks requieren un escrutinio similar. Los desarrolladores a veces suponen que una biblioteca hará seguro un dato de entrada inseguro. Un framework de firma puede proteger la integridad de una cookie solo cuando la clave de firma proporcionada permanece secreta e impredecible.
El análisis asistido por IA es idóneo para seguir estas relaciones entre archivos. Los modelos pueden buscar sitios de llamada, rastrear el flujo de datos, comparar el comportamiento de los frameworks y probar si una debilidad teórica alcanza una operación privilegiada.
Esa ventaja no elimina la necesidad de validación humana. Un exploit generado puede interpretar mal una versión, omitir una suposición ambiental o demostrar un comportamiento que no se generaliza más allá de un entorno de pruebas.
El flujo de trabajo más sólido combina la escala de las máquinas con una revisión responsable. La IA propone y prueba cadenas de ataque, mientras que investigadores experimentados reproducen el resultado, evalúan la gravedad, coordinan la remediación y controlan la divulgación.
Lo que el exploit de Mythos en HFS no demuestra
Una cadena de explotación exitosa demuestra una capacidad significativa, pero no establece que Mythos encuentre de forma fiable todas las vulnerabilidades críticas.
El informe de Horizon3 es un estudio de caso elaborado por una organización que participa en Project Glasswing de Anthropic. Los investigadores utilizaron un entorno personalizado que ejecutaba agentes especializados en paralelo en toda la base de código de HFS.
Ese contexto importa. El resultado no representa a un chatbot de consumo sin asistencia que recibe un repositorio y lo compromete instantáneamente.
El entorno dio forma a la investigación al asignar agentes a clases de vulnerabilidades concretas. Los investigadores humanos también seleccionaron el objetivo, revisaron los hallazgos y gestionaron la divulgación responsable.
Sin embargo, Mythos parece haber contribuido con más que autocompletado o una lista de verificación de seguridad genérica. Según los investigadores, vinculó de forma independiente el PRNG débil, la filtración de salida, el formato de sesión, la reconstrucción retrospectiva del estado y la función administrativa de ejecución de código.
La evidencia publicada respalda el hallazgo en HFS porque un exploit funcional demostró la cadena. Aporta menos información sobre falsos positivos, capacidad de cómputo total, ejecuciones fallidas y hallazgos descartados durante el análisis más amplio.
Esos denominadores ausentes limitan las comparaciones amplias de productividad. Un modelo que encuentra una vulnerabilidad excepcional tras muchos intentos costosos plantea una propuesta operativa distinta de otro que tiene éxito de forma consistente.
El caso tampoco demuestra que la IA por sí sola causara la rápida explotación. Los atacantes llevan mucho tiempo moviéndose con rapidez después de que se hicieran públicos el código de prueba de concepto y los análisis técnicos.
Los escáneres convencionales, las herramientas de comparación de diferencias, los frameworks de explotación y la ingeniería inversa humana ya respaldan ese flujo de trabajo. La IA añade velocidad y accesibilidad, pero se incorpora a una cadena de herramientas ofensivas ya existente.
Tampoco una ubicación de origen establece atribución. Los ataques reportados utilizaron infraestructura en China y Estados Unidos, pero los proxies y los hosts comprometidos ocultan rutinariamente dónde se encuentra un operador.
Las afirmaciones sobre una campaña de un Estado-nación requerirían evidencia adicional, incluido solapamiento de herramientas, historial de infraestructura, selección de víctimas y comportamiento tras el acceso.
También existe incertidumbre sobre la escala de la explotación exitosa. Los informes publicados describieron un pequeño número de solicitudes detectadas contra sistemas vulnerables reales.
Eso es suficiente para justificar la aplicación urgente de parches. No es suficiente para estimar un recuento global de infecciones ni para afirmar que existe una campaña generalizada.
Los defensores deberían resistir ambos extremos. Descartar Mythos como marketing ignora un exploit validado y técnicamente interesante. Tratar un caso como prueba de hacking autónomo universal exagera lo que respalda la evidencia pública.
La conclusión equilibrada es más acotada y sigue siendo importante. Un sistema de investigación asistido por IA ayudó a especialistas a convertir un sutil error de diseño criptográfico en un exploit integral que alcanzó la ejecución remota de código.
Esa capacidad amplía qué hallazgos pueden investigar los investigadores de forma económicamente viable. También incrementa el valor de reducir el retraso entre la disponibilidad de un parche y su despliegue verificado.
Tres señales mostrarán si los defensores pueden mantenerse al día
La próxima prueba es si la explotación se expande, mejora la adopción de parches y las divulgaciones originadas por IA siguen siendo manejables para los mantenedores de software.
La primera señal es el alcance de los ataques observados. Más direcciones de origen, variaciones del exploit, cargas útiles posteriores al compromiso u organizaciones afectadas reforzarían la conclusión de que CVE-2026-61500 ha superado las pruebas oportunistas.
Un goteo continuo de sondeos simples respaldaría una interpretación más limitada. Sugeriría que los atacantes están experimentando con la técnica pública sin haber construido todavía una campaña sostenida.
La segunda señal es si los operadores de Rejetto HFS realmente eliminan las versiones vulnerables. Las mediciones de internet y los informes de incidentes pueden revelar si las instalaciones que ejecutan de 3.0.0 a 3.2.0 persisten después de que circulen las advertencias.
Un descenso rápido demostraría que los mantenedores, proveedores de seguridad y administradores convirtieron la divulgación en acción. Una exposición prolongada confirmaría que el inventario y el despliegue siguen siendo los factores limitantes.
La tercera señal es la calidad y el volumen de divulgaciones posteriores de Project Glasswing. Anthropic afirma que los informes de vulnerabilidades originados por IA reciben revisión humana y gestión coordinada antes de su publicación.
Un flujo constante de hallazgos reproducibles y de alto impacto respaldaría el argumento de que Mythos cambia la economía de la investigación. En cambio, una avalancha de informes de poco valor supondría una carga para los mantenedores de código abierto y debilitaría la confianza en el proceso.
Esta es la consecuencia más amplia de la vulnerabilidad de Anthropic Mythos en HFS. Un mejor descubrimiento crea valor defensivo solo cuando los mantenedores pueden absorber los informes y los usuarios despliegan las correcciones resultantes.
Los equipos de seguridad deberían actualizar ahora los servidores HFS afectados, verificar la versión desplegada, restringir la exposición innecesaria e investigar actividad sospechosa posterior al 30 de septiembre. Después deberían plantearse una pregunta más difícil: si el próximo exploit asistido por IA llega con el mismo cronograma comprimido, ¿puede su inventario de activos producir una respuesta antes que los atacantes?
