Experiencia sobre una operación de corrección llevada a cabo en una semana en todo nuestro parque de KVM, siguiendo una estrategia de parcheo cuyo objetivo central fue minimizar el impacto en los servicios de nuestros clientes.

Vulnerabilidad en el subsistema de virtualización

El martes 7 de julio, a primera hora de la tarde, se recibió una alerta de seguridad relativa a la CVE-2026-53359, una vulnerabilidad de tipo use-after-free que afecta al subsistema de shadow-paging de KVM x86 en el kernel de Linux. La vulnerabilidad, que llevaba varios años presente, se hizo pública el 6 de julio; ya el día 7 empezaron a aparecer publicaciones de blog de otros proveedores cloud.

KVM es el motor de virtualización en el que se basa la inmensa mayoría de las instancias alojadas en OVHcloud. El mecanismo es el siguiente: cuando ocurre una modificación externa de una entrada de directorio de páginas (PDE), la entrada RMAP puede mantener una referencia a una página de memoria ya liberada. El kernel desreferencia entonces esa página obsoleta, lo que puede provocar un fallo del hipervisor o, en los escenarios más desfavorables, una escalada de privilegios en el lado del host. El «exploit» es reproducible: una prueba interna en un host no parcheado provoca un «crash» en aproximadamente dos minutos.

Se ven afectados todos los kernels de Linux x86 anteriores al commit de corrección, sin distinción de distribución. Se realiza el «backport» del parche oficial a nuestros kernels de producción de Debian.

Existen 3 riesgos principales:

• Un cliente VPS utiliza el «exploit» para provocar el fallo del host que ejecuta su máquina virtual: esto causa una caída y reinicio no controlado de varios cientos de máquinas virtuales de clientes.
• Encontramos el mismo escenario en las instancias de Public Cloud, el impacto es similar, pero el número de máquinas virtuales por host es más reducido, y las máquinas virtuales son más potentes y se utilizan para sistemas más sensibles (bases de datos, gestores de colas, load balancer, etc.). Estos sistemas se utilizan a menudo en arquitecturas de aplicaciones compuestas con dependencias complejas.
• La probabilidad de que se publique próximamente un «exploit» de toma de control del host, lo que elevaría de inmediato el nivel de riesgo a un grado inaceptable, dado el impacto sobre la confidencialidad de los datos de los clientes y la integridad de la infraestructura.

Para OVHcloud, el alcance representa decenas de miles de servidores host hipervisores, que albergan aproximadamente un millón de máquinas virtuales. La pregunta, por tanto, no es si hay que parchear, sino cómo llevar a cabo esta operación a semejante escala, sabiendo que un impacto nulo para el cliente no es alcanzable.

Las opciones sobre la mesa para mitigar el riesgo

1. Esperar a los kernels oficiales parcheados

Esta opción nos hacía depender de una agenda externa que nos dejaba en estado de riesgo durante un período no controlado. La descartamos rápidamente dado el nivel de riesgo.

2. Live patch

Aplicar un live patch requiere habilitar este tipo de operación en la configuración del kernel, lo que permite, por diseño, modificar su comportamiento en caliente; esto conlleva una reducción de su nivel de endurecimiento (hardening) y limita las capacidades de detección en caso de compromiso del sistema. Asimismo, el live patch constituye, por naturaleza, un procedimiento sensible que puede provocar un estado de inestabilidad a nivel de todo el parque de servidores. Esta es una opción que permite ganar tiempo a la espera de una solución duradera. Decidimos no asumir este compromiso, ya que habría aumentado considerablemente el riesgo en caso de que se publicara un exploit de toma de control del host.

3. Mitigación mediante la desactivación de la virtualización anidada

Desactivar la virtualización anidada en los hosts permite neutralizar el exploit. No tenemos visibilidad sobre el uso de esta función por parte de nuestros clientes, por lo que no es posible determinar el impacto en los servicios de los clientes, y esta función es necesaria para mantener la capacidad de migración en vivo de una instancia de un host físico a otro. Por consiguiente, descartamos esta posibilidad rápidamente.

4. Live migration

Organizar una migración en vivo de las máquinas virtuales desde hosts vulnerables hacia hosts vacíos que, mientras tanto, habían sido parcheados. Esta opción resulta muy satisfactoria en términos de continuidad del servicio, ya que la migración se realiza sin impacto sobre las máquinas virtuales, salvo por un rendimiento reducido durante el proceso de migración. Esta opción requiere mucho tiempo, debido a la copia de las máquinas virtuales de host a host; no resulta viable en la práctica a la escala de nuestro parque de servidores, ni acorde con el objetivo de proteger a nuestros clientes en cuestión de días en lugar de varios meses. Decidimos conservar esta opción únicamente para determinadas máquinas virtuales críticas, ya que cada migración en vivo provoca un retraso considerable en el desarrollo de los batches.

5. Backport del parche en nuestros kernels y reinicio de todos los hosts

Esta es, finalmente, la opción que se adoptó, y que se desarrollará en detalle en este artículo.

Martes por la tarde: activación y organización del comité de crisis

Desde el momento en que se confirma la vulnerabilidad, la prioridad es construir una respuesta estructurada y coordinada; los analistas encargados de este primer análisis comprenden muy rápidamente lo que estará en juego en los días siguientes. La información se difunde internamente a primera hora de la tarde. Se abren varios espacios de coordinación: uno para la coordinación técnica, uno para la coordinación de crisis, uno para las operaciones en EE. UU., y uno para la comunicación con clientes y el soporte. Al mismo tiempo, los equipos de Kernel preparan y aplican el backport de la corrección; el primer kernel parcheado se entrega esa misma noche.

Las pruebas de validación se llevan a cabo en un entorno de pruebas esa misma noche. El parche queda confirmado: el «exploit» ya no provoca la caída de los hipervisores parcheados, y las pruebas de QA se superan correctamente con el kernel parcheado.

El comité de crisis evoluciona hacia un seguimiento del despliegue y pasa a ser gestionado por el NOC (Network Operations Center), que asume el rol de coordinador operativo: seguimiento del avance global, arbitraje de prioridades entre regiones y servicios, y mantenimiento de la visión de conjunto. La ejecución corre a cargo de los expertos de Public Cloud y VPS, quienes se encargan de los reinicios, las migraciones en vivo y las restricciones de antiafinidad. La separación entre coordinación y ejecución es intencional: el NOC coordina, mientras que los equipos operativos actúan y reportan las métricas y eventos técnicos necesarios para dicha coordinación.

Se garantiza una sincronización continua con el equipo de Soporte al cliente (estado de avance en tiempo real para atender a los clientes afectados) y con los equipos de Seguridad (seguimiento de la vulnerabilidad, validación del alcance y de los criterios de cierre de la operación).

Dado que la operación se desarrolla bajo el modelo «follow the sun», el comité funciona en modalidad 24/7, con una rotación por zona geográfica. Se realizan tres puntos de sincronización cada día, cubriendo las transiciones de zonas. Estos reúnen al NOC, a los expertos operativos, al equipo de Soporte y al de Seguridad para: compartir el estado de avance por región, transmitir el relevo entre zonas (qué ha funcionado, los ajustes de procedimiento basados en los comentarios del terreno) y decidir las prioridades de la siguiente secuencia.

El comité completo se reúne, mediante rotación 24/7: los equipos de Kernel & Virtualization (análisis de la corrección, backport, validación), VPS y Public Cloud (despliegue), NOC (dirección), Run & SRE (orquestación, antiafinidad, migración en vivo), Datacenter Operations (intervenciones de hardware), Soporte al cliente (atención a solicitudes de clientes), Seguridad (vigilancia, alcance, cierre de la operación) y Comunicación (transparencia, notificaciones específicas).

El objetivo establecido es claro: parchear y reiniciar los hosts afectados lo antes posible para reducir la ventana de vulnerabilidad, minimizando el impacto en los servicios. La principal limitación radica en la escala: decenas de miles de máquinas para procesar, en todos los continentes, sabiendo que una atención caso por caso es materialmente imposible con este volumen.

El principal riesgo en esta etapa es la explotación de la vulnerabilidad, lo que provoca un fallo del host sin parche. El comité de crisis decide aplicar el parche de forma global antes de la fase de reinicio. En caso de explotación de la vulnerabilidad, el fallo de un host provocará su reinicio, así como la aplicación automática del parche. Además, existe el riesgo de que la CVE se utilice para obtener un control malicioso del host. No hay ningún código de explotación disponible públicamente, pero sabemos que es solo cuestión de tiempo antes de que un investigador logre utilizar la vulnerabilidad para tomar el control del host. Dado que este escenario sería catastrófico, sabemos que cada minuto cuenta.

Asumimos una decisión: un parcheo unilateral con impacto controlado

El Comité Ejecutivo valida el Go/No-Go esa misma noche: la primera región se procesará al día siguiente por la mañana. Para un volumen de máquinas de este tamaño, no existe ningún escenario sin impacto. Negociar una ventana de mantenimiento con cada cliente, verificar cada dependencia, orquestar cada reinicio de forma personalizada: son pasos que resultan inviables en la práctica, dado el plazo que exige el riesgo de seguridad.

El comité de crisis adopta así una decisión: un parcheo unilateral de impacto controlado, aplicado sin esperar la conformidad individual de cada cliente, conscientes de que algunos servicios se verán interrumpidos. El razonamiento se basa en tres puntos:

• no parchear expone a todo el parque a una vulnerabilidad de alta gravedad;
• un tratamiento caso por caso alargaría los plazos y dejaría a la mayoría de los hosts vulnerables durante semanas;
• una acción rápida y global protege al mayor número de personas, aunque ello implique que esto afecte temporalmente a una minoría.

La prioridad ya no es evitar el impacto, sino minimizarlo, diluirlo y hacerlo previsible. Esta línea de pensamiento estructura todo el proceso: «follow the sun», priorización de regiones y planificación antiafinidad.

Miércoles 8 de julio: inicio desde Sídney

La elección de Sídney para poner a prueba el despliegue era evidente: el número de hosts es reducido, y la franja de despliegue en horario no laboral local (de madrugada) coincide con el horario de oficina de los equipos en Europa. Empezar por la región más oriental permite:

• operar en la zona menos congestionada;
• validar el procedimiento en condiciones reales, a escala reducida, antes de la industrialización;
• recopilar los primeros comentarios antes de lanzar las regiones europeas y norteamericanas.

Las primeras oleadas de parcheo + reinicio se aplican a los VPS en Australia. La región SYD2 finaliza a primera hora de la tarde (hora de París), sin incidencias. Los procedimientos se adaptan sobre la base de la información recibida sobre el terreno.

Una vez estabilizado el procedimiento, se activa el modelo follow the sun: cada región asume el relevo a su turno, en su horario matutino local, traspasando el contexto a la región siguiente. La primera oleada europea (RBX, GRA6, WAW, DE, SBG, MIL, UK) se lanza esa misma noche, a las 18:30 hora de París.

Dos ámbitos, dos niveles de exposición: VPS y Public Cloud

El despliegue no es uniforme, ya que VPS y Public Cloud difieren tanto en arquitectura como en exposición frente al cliente. En los hosts VPS, el número de máquinas virtuales es mayor, y muchas empresas y particulares los utilizan para infraestructuras de prueba. Esto hace que la probabilidad de que un cliente pruebe el código del «exploit» en su máquina virtual sea muy alta, y que el impacto también lo sea, dado el elevado número de máquinas virtuales por host.

En el caso de VPS, el alcance por host está acotado, y el impacto en el cliente por reinicio se mantiene bajo control. Los lotes pueden ejecutarse en cadena de forma rápida, lo que permite asegurar gran parte de la infraestructura desde las primeras 24 horas.

Public Cloud presenta un tipo de exposición completamente distinto. Una región concentra miles de clientes y un host puede albergar instancias críticas. Las regiones más grandes cuentan con cientos o incluso miles de hosts con complejas infraestructuras de clientes virtuales. Decidimos dar prioridad a ciertas cuestiones.

• Por tamaño de región: las regiones con menor densidad se procesan primero, con el fin de validar la robustez del procedimiento a escala.
• Por número de clientes expuesto: las regiones de alto volumen se orquestan con una granularidad más fina, lote por lote, para diluir el riesgo.

Umbrales de parada y control del tempo

Cada oleada de reinicios está sujeta a un umbral de parada: si el número de hosts fallidos simultáneos supera un umbral definido, la oleada se suspende. Este umbral se establece en 15 hosts para las regiones de alta densidad (GRA, RBX, BHS) y en 5 hosts para las demás. También se activa una interrupción a las 06:00 h o a solicitud del datacenter local. Este dispositivo permite no empeorar una situación de fallo material al continuar reiniciando los hosts que los técnicos de DC aún no han podido procesar. Introduce un punto de regulación entre la automatización de software y la realidad física del terreno.

Antiafinidad: la salvaguarda contra reinicios simultáneos en un mismo proyecto

El principal riesgo para nuestros clientes en una operación de este tipo no es el reinicio en sí, sino la interrupción simultánea de varias instancias de un mismo proyecto, que garantiza una resiliencia de la aplicación capaz de hacer frente a un fallo del proveedor. Un cliente que haya distribuido sus cargas de trabajo en varios hosts para garantizar su alta disponibilidad no debe ver cómo todas sus instancias se mueven al mismo tiempo. Se decidió ir más allá del mero cumplimiento de las reglas de antiafinidad definidas en los despliegues de los clientes. De este modo, para cada proyecto de cliente cuyas instancias estén repartidas en varios hosts, nuestros orquestadores calculan un grafo de colocalización. En ningún caso se reinician dentro de la misma ventana dos hosts que alojen instancias de un mismo proyecto: se definen oleadas mutuamente excluyentes, de modo que un host debe estar de nuevo en servicio antes de iniciar el reinicio del siguiente dentro de la misma clase de antiafinidad. Esta antiafinidad se aplica en best effort: se respeta en la mayoría de los casos, pero no puede garantizarse al 100 % en todo el parque. El objetivo sigue siendo el mismo: escalonar el impacto para que la capa de aplicación pueda absorberlo. Los clientes cuyas instancias residen todas en un solo host experimentan una interrupción puntual, cuya ventana temporal se comunica de antemano.

Migración prioritaria en vivo de servicios y cargas de trabajo sensibles

Detrás de cada instancia de cliente hay controladores, API, planos de datos y bases de datos internas. Un reinicio no controlado de los hosts que alojan estos servicios crearía deadlocks: un servicio interno no disponible bloquea la continuación de los reinicios, lo que bloquea el parcheo. Además, algunos servicios de OVHcloud se basan en máquinas virtuales alojadas en las instancias de Public Cloud. Es indispensable tener en cuenta estos casos para limitar los impactos en los clientes. Para evitar esta cascada, se invierte la prioridad: se realiza un análisis en profundidad de las dependencias de los servicios internos antes de cada reinicio de región.

Algunos servicios internos se migran en vivo. Sus máquinas virtuales se desplazan en caliente hacia hosts ya parcheados, la cadena de dependencias se mantiene disponible, y a continuación el host queda liberado para su reinicio. Este procedimiento es largo y consume intensamente recursos materiales y humanos. Debe limitarse a un número reducido de máquinas virtuales para respetar el objetivo de contener la migración en el tiempo.

Algunas cargas de trabajo requieren especial atención: en particular, los servicios de Cloud Databases (DBaaS), el Datalake interno y las funciones de Observability se migran una VM a la vez, sin apagar más de una máquina simultáneamente, difiriendo la actualización de sus hosts el mayor tiempo posible. Esta migración sin sobresaltos permite evitar interrupciones en cascada de los servicios y garantizar que las herramientas de apoyo a las operaciones estén disponibles.

Incidentes técnicos y ajustes durante el proceso operativo

Una operación de esta magnitud no se desarrolla sin incidentes. Durante la campaña se han encontrado y resuelto varios problemas técnicos.

Las máquinas virtuales no se reinician después del reinicio del host

El primer incidente importante se produjo en la primera oleada europea: las máquinas virtuales no se reiniciaban después del reinicio de su hipervisor. Nova compute reportaba el mensaje «Instance shutdown by itself» sin ninguna sincronización. La causa raíz se identifica el segundo día: el servicio libvirt-guests entraba en conflicto con nova compute y detenía las instancias en el reinicio sin sincronización en la API. El parche aplicado es desactivar y ocultar libvirt-guests.service en los hosts antes de reiniciar. Tras aplicar esta corrección, los reinicios automáticos de las VM pasaron a funcionar correctamente.

Corrupción de datos en los servicios síncronos

En la tarde del segundo día, el sistema de monitorización interna señala datos corruptos en varias VM distribuidas en 3 clústeres. La explicación más probable: el reinicio forzado se producía a mitad de una escritura en disco. Se amplía entonces el graceful shutdown a 60 segundos antes de forzar la terminación, dando así tiempo a que las escrituras en curso puedan completarse. Además, se ha implementado un script de reinicio automático de las VM que se han apagado.

Deadlock API en París

En la madrugada del segundo al tercer día, las API de Nova y Neutron en París entran en deadlock mutuo: la API de Neutron (con un límite de 10 procesos) se vio desbordada por una ráfaga de peticiones de Nova y estuvo devolviendo errores HTTP 503 durante unas dos horas. La solución consistía en aumentar los workers Neutron de 10 a 30 y los procesos Apache de 10 a 32. Las zonas B de París y Milán se posponen mientras se estabiliza la situación.

Saturación del soporte en BHS

En el sitio de BHS (Canadá), el tráfico de API alcanza 10 veces el tráfico máximo habitual, saturando el Manager y el soporte. Algunos clientes descubrieron el impacto antes de recibir la comunicación. Este caso ilustra de forma concreta las reacciones en cadena dentro de la infraestructura. Todos estos bugs y problemas encontrados se han gestionado en el marco de las operaciones, pero se tendrán en cuenta para implementar las mejoras adecuadas de manera permanente.

Reinicios e intervenciones materiales

Un reinicio de decenas de miles de máquinas también implica una dimensión material. Existe una tasa de error inherente a cualquier reinicio del servidor. En la primera noche, unos 20-30 hosts de un total de 6000 no lograron recuperarse por sí solos, por causas como módulos de memoria defectuosos, configuración incorrecta de BIOS o interfaces de red inactivas. En Estados Unidos, varios hosts requirieron una retirada de la batería CMOS y un drenaje de alimentación antes de volver a encenderla, un patrón de hardware que se repitió en varios casos.

Cada centro dispone de técnicos de datacenter que actúan como refuerzo de esta estrategia. Su función:

• intervenir de forma urgente en los hosts fallidos de reinicio que reporten los orquestadores;
• sustituir las piezas defectuosas (discos, módulos de memoria, fuentes de alimentación);
• realizar las intervenciones de proximidad que ninguna herramienta puede automatizar: hard reboot físico, verificación de los pilotos luminosos, intervención en el rack.

Los técnicos del datacenter operan en modo de intervención prioritaria sobre los hosts fallidos, en coordinación con los equipos Run/SRE que priorizan según la exposición del cliente al host. Un host que aloja instancias críticas y no se recupera tiene prioridad sobre un host vacío. Esta priorización cruzada, tanto a nivel de software como físico, es lo que permite mantener el ritmo de la operación.

Comunicación y apoyo: informar a los clientes afectados

Un proceso de parcheo unilateral con impacto controlado no tiene sentido sin un esfuerzo de comunicación acorde.

Comunicación progresiva y orientada

Ante la dinámica del «follow the sun», una comunicación global e indiferenciada no habría tenido sentido. Por ello, se optó por una comunicación específica y progresiva: dirigida exclusivamente a los clientes cuyas instancias se alojan en los hosts programados para reinicio, y desencadenada de forma progresiva conforme avanzaba la operación, región por región y oleada por oleada.Inicialmente, se toma la decisión de no activar una página de estado pública, para no exponer la secuencia de despliegue. Las comunicaciones se realizan a través de targeted communications a través de nuestro portal de Soporte, con envío de correos electrónicos a los clientes con nivel de Soporte Business y Enterprise.

Hallazgo: algunos mensajes no llegan a entregarse

Las herramientas de comunicación presentaban limitaciones técnicas, por lo que, para las regiones con gran volumen como GRA6 (cerca de 90 000 clientes no contactados), se descarta el envío masivo de correos electrónicos para evitar la multiplicación de tickets de soporte.

Ante esta situación, se decide un cambio de enfoque el segundo día: implementar un banner condicional en el Manager mediante feature flipping, de modo que, si el usuario conectado figuraba en la lista de cuentas de cliente (NIC) afectadas, se le mostrara un mensaje informativo El desarrollo se completa en el transcurso de ese mismo día y el banner se despliega el tercer día. En ese momento se crea también una página de estado de Public Cloud.

A pesar de estos mecanismos, algunos mensajes no llegaron a sus destinatarios: direcciones de contacto obsoletas, notificaciones filtradas, desfase entre la hora prevista del reinicio y la hora de envío. Algunos clientes descubrieron el impacto sin haber sido avisados de antemano. Estos puntos de fallo se identificaron como líneas de mejora prioritarias al cierre del plan de mitigación inicial.

El soporte como canal de último recurso

Para los clientes no informados, o que requieran más detalles, el soporte al cliente ha sido reforzado y preparado: información previa sobre el contexto de la operación, acceso en tiempo real al estado de avance por región y por host, procesamiento acelerado de los tickets relacionados con la campaña a través de un circuito dedicado. El soporte cubre así lo que las notificaciones automatizadas no lograron abarcar. No sustituye a la comunicación, sino que compensa algunas de sus carencias.

Cronología de la operación

Lecciones aprendidas

La vulnerabilidad CVE-2026-53359 ponía en riesgo a nuestros clientes e infraestructuras. El plan de mitigación implicó un impacto para los clientes: contenido, escalonado y comunicado con antelación, pero impacto real al fin y al cabo. Comunicar con mayor nivel de detalle durante la ejecución del plan, mientras la infraestructura seguía sin estar parcheada, habría incrementado de forma significativa el riesgo para nuestros clientes, ya que podría haber llevado a algunos de ellos a «probar» el exploit disponible públicamente.

Reiniciar un parque de envergadura mundial con un impacto cero no era un objetivo alcanzable. Por ello, el objetivo pasó a ser reducir el impacto al mínimo posible, siempre que resultara compatible con la seguridad del conjunto del parque.

Parchear y reiniciar todos los hosts de Public Cloud y VPS nunca se había realizado bajo esta limitación de tiempo. Este procedimiento de emergencia se estableció teniendo en cuenta el riesgo que suponía la vulnerabilidad. Los casos anteriores siempre se habían gestionado mediante un reinicio progresivo, apoyándose en la tasa de rotación natural de las máquinas virtuales dentro de la infraestructura, combinada con live-migrate puntuales, planificadas a lo largo de un periodo más extenso.

Los equipos implicados en esta operación lograron un resultado destacable, con un número de incidencias y un impacto en los clientes muy razonables en relación con la envergadura del proyecto. Sin embargo, siendo conscientes de que los próximos meses podrían traer nuevas publicaciones de vulnerabilidades del kernel, todo apunta a que este procedimiento de emergencia tendrá que repetirse. Deberemos mejorar en la próxima ocasión, tanto en el control del impacto directo de los reinicios como en la comunicación previa a los clientes y en el acompañamiento de los clientes afectados durante las operaciones. Por ello, en los próximos días y semanas identificaremos los principales impactos en los clientes que se hayan visto afectados por incidencias más complejas, y analizaremos internamente, mediante un post mortem, los problemas surgidos durante las operaciones, con el objetivo de mejorar nuestros procedimientos de cara al futuro.