OVH reinició masivamente hosts para parchear el fallo Januscape

OVH dice que utilizó su centro de datos en Sídney, Australia, como primer banco de pruebas para una corrección de emergencia a Januscape, la crítica vulnerabilidad de fuga de invitado a anfitrión de KVM registrada como CVE-2026-53359.

El fallo permitía a un atacante con acceso root dentro de una VM invitada ejecutar código como root en el anfitrión, colapsar el anfitrión o comprometer otras VMs invitadas que se ejecutaran allí. Para un proveedor de nube construido sobre KVM (la tecnología de máquinas virtuales basada en el kernel de Linux), eso es prácticamente lo peor que puede pasar.

En una entrada detallada publicada el lunes, el CISO de OVH, Julien Levrard, dijo que la empresa parcheó decenas de miles de anfitriones que alojan alrededor de un millón de máquinas virtuales. En lugar de deshabilitar la virtualización anidada, confiar en parches en caliente o migrar lentamente las cargas de trabajo a máquinas ya parcheadas, OVH optó por retroportar una corrección a la distribución Debian que usa en producción y luego reiniciar todos los anfitriones.

Se advirtió a los clientes con antelación, pero no se les pidió consentimiento. OVH dijo que su comité ejecutivo aprobó ese enfoque por tres razones:

Recomendado

El auge de los centros de datos en el Reino Unido choca con la realidad del agua

• la necesidad de aplicar el parche antes de que comenzaran los ataques
• tratar los casos uno por uno habría dejado la nube expuesta por más tiempo
• proteger al mayor número de clientes, incluso si una minoría sufrió interrupciones

Levrard también dijo que OVH deliberadamente mantuvo en reserva los detalles del despliegue mientras se aplicaba el parche.

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

Cómo OVH probó el despliegue en Sídney

Sídney fue elegida porque es una de las regiones más pequeñas de OVH, y la costa este de Australia está ocho horas por delante de Francia, lo que permitió a los equipos europeos trabajar durante su jornada laboral mientras se coincidía con un período local más tranquilo.

El despliegue se realizó por oleadas, con un umbral de apagado de 15 hosts que fallasen simultáneamente en regiones de alta densidad o cinco hosts en otros lugares. OVH dijo que fue más allá de las reglas estándar de anti-afinidad al construir un grafo de colocación para cada proyecto de cliente, asegurándose de que dos hosts que ejecutaban instancias del mismo proyecto no fuesen reiniciados en la misma ventana.

Cortes, reinicios fallidos y hardware defectuoso

El proceso aún se encontró con problemas. Algunas VMs no lograron reiniciarse después de los reinicios del hipervisor. Otras sufrieron corrupción de datos durante los apagados forzados. Las API de OpenStack se comportaron mal, provocando horas de errores HTTP 503 y obligando a retrasar una oleada. En un sitio canadiense, OVH dijo que el tráfico de API alcanzó 10 veces el pico habitual, sobrecargando a los equipos de gestión y soporte.

También hubo fallos de hardware. Según Levrard, en la primera noche alrededor de 20 a 30 hosts de 6.000 no volvieron a encender por sí mismos debido a módulos de memoria defectuosos, problemas de configuración del BIOS, interfaces de red inactivas e incluso baterías CMOS agotadas.

Levrard calificó la operación de «hazaña notable», pero dijo que OVH espera más trabajo de emergencia en el kernel por delante y necesitará mejorar tanto las comunicaciones con los clientes como el impacto de futuros reinicios.