VMmanager: así fue el 0-day de HTTP Request Smuggling

En pocas palabras: ISPsystem contuvo el 0-day en VMmanager 6 lanzando ocho rondas de hotfixes entre el 14 y el 23 de octubre de 2026, cerrando la cadena de ISO maliciosa + HTTP Request Smuggling sobre WebSockets con un release estable que también parchó tres CVE de nginx. Microsoft no participó del incidente.

Entre el 12 y el 23 de octubre de 2026, ISPsystem sufrió un ataque de día cero contra VMmanager 6 que combinó una ISO de usuario maliciosa con HTTP Request Smuggling sobre WebSockets para lograr ejecución remota de código en microservicios internos. La empresa lanzó ocho rondas de hotfixes en nueve días y cerró el agujero con un release estable el 23 de octubre.

HTTP Request Smuggling es una técnica que explota diferencias en cómo un proxy (como Nginx) y un servidor backend interpretan los límites de una solicitud HTTP, lo que permite esconder una segunda solicitud dentro del cuerpo de la primera. En el caso de VMmanager 6, el vector específico abusó del upgrade a WebSocket con un body adjunto, algo que el RFC no recomienda pero que Nginx deja pasar sin bloquear.

¿Qué es el HTTP Request Smuggling que afectó a VMmanager?

El HTTP Request Smuggling que golpeó a VMmanager 6 no fue el clásico desajuste CL.TE o TE.CL entre Content-Length y Transfer-Encoding que ves en la mayoría de los writeups. Acá el vector fue distinto: un request de upgrade a WebSocket con un body metido adentro (spoiler: ahí es donde se cuela todo el lío).

Nginx reenvía ese body al backend tal cual, sin chistar. El backend ve el request mal formado para un upgrade y lo rechaza, pero no vacía el buffer. Como la conexión usa keep-alive, el backend termina leyendo esos bytes sobrantes como si fueran un request completamente nuevo. Nginx, que pensaba que solo estaba tunelizando una conexión WebSocket, nunca inspeccionó ese segundo pedido escondido adentro del primero. Tema relacionado: cómo configurar el nodo HTTP Request.

¿Cómo fue la cadena de ataque paso a paso?

El ataque encadenó dos vulnerabilidades distintas: primero acceso inicial vía ISO maliciosa, después escalada con HTTP Request Smuggling para forjar headers internos de Docker y lograr ejecución remota de código con privilegios de administrador.

Según el relato original publicado en dev.to y confirmado por ISPsystem en su propio informe, el punto de entrada fue ridículamente simple: cualquiera que compre una VM barata en un hosting con VMmanager tiene cuenta de usuario estándar, y desde ahí puede subir una ISO personalizada para instalar un sistema operativo propio. ISPsystem ya había detectado esa falla por su programa de Bug Bounty el 9 de octubre y tenía planeado un parche mayor para el 15, pero los atacantes golpearon antes de esa ventana.

Subís una ISO como cualquier cliente del hosting, la plataforma la monta sin chistar, conseguís standing dentro del nodo, mandás el request con el upgrade trucho, el backend se come el segundo request como si viniera de un servicio interno confiable y de repente tenés comandos administrativos corriendo adentro del cluster.

Bloqueado el vector de la ISO con un hotfix de emergencia el 14 de octubre a las 19:00 MSK, los atacantes no se quedaron de brazos cruzados. Cambiaron de arma: el HTTP Request Smuggling sobre WebSocket, forjando el header interno que los servicios de Docker usan para identificar tráfico confiable entre peers. El backend vio ese header, asumió que venía de la red interna, y ejecutó. RCE completo.

¿Cómo respondió ISPsystem ante el ataque?

ISPsystem armó una guerra de parches de nueve días: ocho rondas de hotfixes entre el 14 y el 23 de octubre, con bloqueos temporales de funciones no esenciales para frenar al atacante mientras el equipo buscaba la causa raíz. Esto se conecta con lo que analizamos en diferencias entre los códigos de redirección HTTP.

El 17 de octubre, con una nueva ola de ataques y unos 20 tickets de soporte acumulados en un solo día, la empresa tomó una decisión drástica: deshabilitó la posibilidad de dar acceso SSH desde la plataforma y bloqueó la ejecución de scripts para nodos y VMs. Esa “pausa” de funcionalidad rompió algunas cosas de uso diario, pero paralizó las herramientas automatizadas del atacante mientras los devs cazaban el bug real.

El 19 de octubre a las 16:00 MSK identificaron el HTTP Request Smuggling como el mecanismo exacto de explotación. Cinco horas más tarde, a las 21:00 MSK, salió el hotfix que lo cerraba. Kaspersky se sumó al rastreo de indicadores de compromiso y, desde el 21 de octubre, ofreció gratis su herramienta Kaspersky Virus Removal Tool (KVRT) para escanear infraestructuras afectadas. Para probar que los parches realmente funcionaban, el equipo desplegó un honeypot en contorno abierto: los atacantes tiraron más de 10.000 requests automatizados contra los nodos parcheados y ninguno pasó.

Fecha (MSK)	Versión VMmanager 6	Qué resolvió
14/10 19:00	2026.05.2-5 / 2026.09.1-1	Hotfix de emergencia para el vector de ISO maliciosa
18/10 04:00	2026.05.2-6 / 2026.09.1-2	Bloqueo de scripts y acceso SSH para contener al atacante
19/10 21:00	2026.05.2-8 / 2026.09.1-4	Fix del HTTP Request Smuggling sobre WebSocket
20/10 04:00	2026.05.2-9 / 2026.09.1-5	Restitución de WebSockets y fix más preciso
23/10	2026.05.2-12 (stable) / 2026.09.1-8 (regular)	Release estable, rediseño del framework de microservicios, parches CVE de Nginx

¿Qué alcance tuvo el ataque y qué datos todavía no están confirmados oficialmente?

ISPsystem confirmó riesgo de exposición de llaves SSH, contraseñas de acceso, tokens de servicios cloud, archivos de configuración, historial de comandos, billeteras cripto y documentos de usuario en los nodos comprometidos. Lo que no está confirmado del lado del vendor: si esos datos efectivamente salieron de la infraestructura.

La empresa fue clara en ese punto: no puede confirmar ni negar el volumen ni la transferencia real de datos, por lo que varios proveedores de hosting afectados optaron por tratarlos como comprometidos de hecho, un criterio que la propia ISPsystem considera razonable. En otro caso reciente de repos comprometidos con malware profundizamos sobre esto.

¿Y los atacantes usaron inteligencia artificial para automatizar el ataque? Según la cobertura de ServerNews.ru, sí: los algoritmos habrían adaptado la táctica de forma dinámica según la infraestructura de cada proveedor. El propio informe técnico de ISPsystem en Habr confirma este punto en su sección de FAQ, donde describe el uso de herramientas especializadas basadas en IA con cambios dinámicos de comportamiento según la infraestructura de cada proveedor.

¿Cómo protegerse de HTTP Request Smuggling en Nginx y microservicios?

La defensa pasa por dos frentes: actualizar Nginx a la rama que soporta la directiva nueva, y dejar de depender solo del proxy de borde para filtrar headers internos sensibles.

• Actualizá a Nginx 1.31.5 Mainline o superior. Desde esa versión, lanzada el 2 de septiembre de 2026, existe la directiva client_body_early_read, que permite bloquear o manejar bodies de lectura temprana antes de hacer el proxy_pass. Esto mata este vector específico de raíz.
• Si estás en la rama Stable (1.30.x), todavía no tenés esa directiva. Tu backend tiene que estar codeado para drenar manualmente el buffer de la request cuando la rechaza, así no queda nada sobrante para que se lea como un request nuevo.
• No confíes solo en que Nginx filtre headers. Que el proxy de borde strippee un header interno está bien como defensa en profundidad, pero no puede ser tu única barrera. Sumá validación zero-trust entre microservicios, con mTLS o JWT interno, en vez de confiar a ciegas en headers HTTP crudos.

Si administrás tu propio VPS y corrés Nginx como frontend de microservicios, vale la pena auditar esto antes de que te agarre un fin de semana largo.

Errores comunes al pensar en HTTP Request Smuggling

• Asumir que el proxy de borde es la única barrera de seguridad. Nginx strippeando un header no reemplaza autenticación real entre servicios internos.
• Permitir subida de ISOs de usuario sin validación de montaje. Si tu plataforma de virtualización monta imágenes automáticamente, cualquier cliente con cuenta estándar es un vector de entrada potencial.
• No drenar el buffer del request al rechazarlo. Si tu backend corre sobre keep-alive y no vacía lo que quedó en el buffer, cualquier byte sobrante se interpreta como un request nuevo.
• Pensar que un hotfix rápido cierra todo el problema. ISPsystem necesitó ocho rondas de parches en nueve días porque cada fix cerraba un vector específico, no la causa raíz completa.

Preguntas Frecuentes

¿Qué es HTTP Request Smuggling y cómo funciona?

HTTP Request Smuggling es un ataque que aprovecha diferencias en cómo un proxy y un backend delimitan dónde empieza y termina una solicitud HTTP. En VMmanager 6, el backend leyó bytes sobrantes de un request rechazado como una solicitud nueva, y el proxy nunca la inspeccionó porque pensaba que solo tunelizaba un WebSocket.

¿Qué pasó con el ataque zero-day a VMmanager de ISPsystem?

Entre el 12 y el 23 de octubre de 2026, atacantes explotaron una ISO maliciosa para acceso inicial y luego HTTP Request Smuggling para lograr ejecución remota de código en VMmanager 6. ISPsystem lanzó ocho hotfixes y cerró el incidente con un release estable el 23 de octubre. Para más detalles técnicos, mirá cómo asegurar el acceso SSH a tu VM.

¿Cómo protejo mi Nginx de un ataque de contrabando de solicitudes HTTP?

Actualizá a Nginx 1.31.5 Mainline o superior para usar la directiva client_body_early_read, que bloquea bodies de lectura temprana antes de proxy_pasar. Si estás en Stable 1.30.x, programá tu backend para drenar manualmente el buffer al rechazar un request.

¿Qué es la directiva client_body_early_read en Nginx?

Es una directiva introducida en Nginx 1.31.5 Mainline (2 de septiembre de 2026) que permite configurar cómo se maneja el body de un request cuando llega antes de lo esperado, tanto en HTTP/1.1 como en HTTP/2. Cierra el vector específico de smuggling que usó este ataque sobre WebSockets.

¿Microsoft tuvo algo que ver con este ataque?

No, Microsoft no participó ni se vio afectado por este incidente. El ataque golpeó a ISPsystem (parte del Grupo Astra) y a su producto VMmanager 6, y el componente de software involucrado en el vector técnico fue Nginx, un servidor web open source sin relación con Microsoft.

Conclusión

Lo que queda de este incidente no es solo el bug puntual, que ya está cerrado. Es el patrón: un vector de acceso inicial relativamente obvio (una ISO de usuario) combinado con un comportamiento de borde que casi nadie revisa a fondo, el manejo de WebSockets con body en Nginx. Si administrás microservicios detrás de un proxy, la lección concreta es doble: actualizá a la rama de Nginx que soporta client_body_early_read y dejá de confiar en headers HTTP crudos como mecanismo de autenticación interna. ISPsystem tardó nueve días y ocho hotfixes en cerrar el círculo completo. La pregunta que te deja el caso es si tu propia infraestructura aguantaría ese mismo tiempo de exposición sin que nadie se dé cuenta.

Fuentes

• Informe técnico oficial de ISPsystem en Habr – cronología completa del incidente
• Relato técnico original en dev.to – análisis de la cadena de explotación
• ServerNews.ru – cobertura sobre el uso de IA en el ataque