OVH parcheó Januscape con reinicios masivos y una prueba en Sídney

OVH dice que respondió al crítico fallo Januscape en KVM retroportando una solución en su compilación de Debian en producción y reiniciando decenas de miles de hosts que ejecutaban alrededor de un millón de máquinas virtuales —después de usar primero su región de Sídney, Australia, como caso de prueba.

El fallo, también conocido como CVE-2026-53359, permitía a un atacante con acceso root dentro de una máquina virtual invitada ejecutar código como root en el host, provocar la caída de esa máquina o comprometer otras máquinas virtuales invitadas. Para los proveedores cloud basados en KVM, ese es uno de los modos de fallo más graves: una ruptura en el aislamiento entre clientes.

En una entrada detallada publicada el lunes, el CISO de OVH, Julien Levrard, dijo que la empresa descartó varias alternativas. Desactivar la virtualización anidada con un simple cambio de configuración no era práctico porque OVH no puede saber qué clientes dependen de ella, y la función también se usa para mover VMs entre hosts físicos. El parcheo en caliente se rechazó por preocupaciones de estabilidad, mientras que la migración en vivo a hosts ya parcheados se consideró demasiado lenta y podría haber llevado meses.

Recomendado

Solo el 34% confía en los agentes de IA a pesar de que el 86% los despliega

OVH en su lugar eligió un enfoque de reinicios forzados, notificando a los clientes con antelación pero sin pedir su consentimiento. La empresa dijo que su comité ejecutivo aprobó ese plan por tres motivos:

• la necesidad de parchear antes de que comenzaran los ataques
• el riesgo de dejar la nube expuesta más tiempo si los casos se trataban uno por uno
• el objetivo de proteger al mayor número de clientes, incluso si una minoría sufría tiempo de inactividad

Levrard también dijo que OVH deliberadamente mantuvo en secreto los detalles del despliegue mientras los sistemas permanecían expuestos.

«Comunicar con más detalle durante la ejecución del plan de mitigación, mientras la infraestructura seguía sin parchear, habría aumentado significativamente el riesgo para nuestros clientes, lo que potencialmente habría llevado a algunos a “probar” el exploit públicamente disponible.»

Cómo OVH organizó el despliegue de reinicios

OVH empezó en Sídney, describiéndola como una de sus regiones más pequeñas y una donde la diferencia horaria permitía a los equipos europeos trabajar durante horario laboral mientras se atravesaba un periodo más tranquilo a nivel local. Los reinicios se programaron en oleadas, con un umbral de parada si 15 hosts fallaban a la vez en regiones de alta densidad o cinco hosts en otras regiones.

La empresa dijo que fue más allá de las reglas estándar de anti-afinidad. Su sistema de orquestación construyó un grafo de colocalización para que dos hosts que ejecutaran instancias del mismo proyecto de cliente no se reiniciaran en la misma ventana. Un host tenía que volver a estar en línea antes de que otro de la misma clase de anti-afinidad pudiera reiniciarse.

El proceso aún encontró problemas. Algunas VMs no se reiniciaron después de los reinicios del hipervisor. Otras sufrieron corrupción de datos durante los apagados forzados. Las APIs de OpenStack devolvieron errores HTTP 503 durante horas, obligando a OVH a retrasar una ola, y en un sitio canadiense el tráfico de API se disparó hasta 10 veces el pico habitual, saturando a los gestores y a los equipos de soporte.

Las fallas de hardware sumaron a los problemas. La primera noche, entre 20 y 30 hosts de unas 6.000 no se recuperaron automáticamente debido a módulos de memoria defectuosos, problemas de configuración del BIOS, interfaces de red inactivas e incluso pilas CMOS agotadas.

Levrard calificó la operación de «una hazaña notable» dada la escala, pero dijo que OVH tendrá que mejorar. Con más fallos de kernel probables, escribió, la compañía espera que este tipo de procedimiento de emergencia pueda necesitar repetirse.