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

Una 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 núcleo Linux. La vulnerabilidad, de hace varios años, se hace pública el 6 de julio; los blogs de otros proveedores cloud aparecen desde el día 7.

KVM constituye el motor de virtualización sobre el que se basa la inmensa mayoría de las instancias alojadas en OVHcloud. El mecanismo es el siguiente: cuando se produce una modificación externa de una Page Directory Entry (PDE), la entrada RMAP puede conservar una referencia hacia una página de memoria ya liberada. El núcleo desreferencia entonces esta página obsoleta, lo que puede provocar un bloqueo del hipervisor o, en los escenarios más desfavorables, una elevación de privilegios en el lado del host. El exploit es reproducible: una prueba interna en un host no parcheado provoca un bloqueo en unos dos minutos.

El conjunto de los núcleos Linux x86 anteriores al commit de corrección está afectado, sin distinción de distribución. El parche oficial se backportea a nuestros núcleos de producción Debian.

Hay que considerar 3 riesgos principales:

• Un cliente VPS utiliza el exploit para bloquear el host que hace funcionar su máquina virtual: bloqueo y reinicio no controlado de varios cientos de máquinas virtuales de cliente.
• Escenario idéntico en las instancias de Public Cloud, el impacto es similar pero el número de máquinas virtuales por host es más restringido y las máquinas virtuales son más potentes y se utilizan para sistemas más sensibles (bases de datos, gestor de colas, Load Balancer, etc.). Estos sistemas se utilizan a menudo en arquitecturas de aplicaciones compuestas con dependencias complejas.
• Probabilidad de la publicación próxima de un exploit de toma de control del host, lo que aumentaría inmediatamente el nivel de riesgo a un nivel inaceptable debido al impacto en la confidencialidad de los datos de los clientes y en la integridad de la infraestructura.

Para OVHcloud, el perímetro representa decenas de miles de servidores host hipervisores, que alojan alrededor de un millón de máquinas virtuales. La cuestión no es, por tanto, determinar si hay que parchear, sino cómo llevar a cabo esta operación a tal escala, sabiendo que un impacto cero para el cliente no es alcanzable.

Las opciones sobre la mesa para mitigar el riesgo

-1 %

Esperar a los kernels parcheados oficiales

Esta opción nos hacía depender de una agenda de terceros que nos dejaba en estado de riesgo durante un periodo no controlado. La descartamos rápidamente teniendo en cuenta el riesgo.

2.

Live patch

Aplicar un live patch requiere autorizar este tipo de operación en la configuración del kernel, lo que permite, por construcción, poder modificar su comportamiento sobre la marcha, provocando al mismo tiempo una reducción de su nivel de endurecimiento, limitando las capacidades de detección en caso de compromiso del mismo. Por otra parte, el live patch es un procedimiento sensible por naturaleza, que puede desembocar en un estado inestable a escala del parque. Es una opción que permite ganar tiempo mientras esperas una solución duradera. Hemos decidido no hacer este compromiso que habría aumentado muy fuertemente el riesgo en caso de publicación de 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 hacer que el exploit sea inoperante. No tenemos visibilidad sobre el uso de esta funcionalidad por parte de nuestros clientes, por lo que es imposible determinar el impacto en los servicios de los clientes, y esta funcionalidad es necesaria para conservar la capacidad de Live migration de una instancia de un host físico a otro. Descartamos esta vía rápidamente.

4.

Live migration

Organizar una Live migration de las máquinas virtuales, desde hosts vulnerables hacia hosts vacíos que han sido parcheados mientras tanto. Esta opción es muy satisfactoria en términos de continuidad de servicio, ya que la migración se realiza sin impacto en las máquinas virtuales, a excepción de un rendimiento reducido durante la migración. Esta opción requiere mucho tiempo, debido a la copia de las máquinas virtuales de host a host; no es utilizable de forma realista a escala del parque y con el deseo de proteger a nuestros clientes en unos días en lugar de varios meses. Decidimos conservar esta opción solo para ciertas máquinas virtuales críticas, ya que cada migración en vivo provoca un retraso importante en la ejecución de los procesos por lotes.

5.

Backport del parche en nuestros núcleos y reinicio de todos los hostsEs finalmente esta opción la que se retendrá y la que se detallará en el resto del artículo.Martes por la tarde: activación y organización de la célula de crisisDesde la confirmación de la vulnerabilidad, la prioridad es construir una respuesta estructurada y coordinada; los analistas a cargo de este primer análisis comprenden muy rápidamente los retos de los días venideros. La información se difunde internamente a principios 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., uno para la comunicación con el cliente y el soporte. Al mismo tiempo, los equipos Kernel preparan y aplican el backport del parche; el primer núcleo parcheado se entrega por la noche.Las pruebas de validación se llevan a cabo en el entorno de pruebas durante la noche. El parche está confirmado, el exploit ya no bloquea los hipervisores parcheados y las pruebas de QA pasan con el núcleo parcheado.

La célula de crisis evoluciona hacia un seguimiento del despliegue y es después dirigida por el NOC (Network Operations Center), que asume el papel de coordinador operativo: seguimiento del avance global, arbitraje de las prioridades entre regiones y servicios, mantenimiento de la visión de conjunto. La ejecución corre a cargo de los expertos en Public Cloud y VPS, que operan los reinicios, las migraciones en vivo y las restricciones de anti-afinidad. La separación entre coordinación y ejecución es voluntaria: el NOC coordina, los equipos operativos actúan y comunican las métricas y eventos técnicos necesarios para la coordinación.

La sincronización con el Soporte al cliente (estado de avance en tiempo real para responder a los clientes afectados) y los equipos de Seguridad (vigilancia sobre la vulnerabilidad, validación del perímetro y de los criterios de fin de operación) se asegura de forma continua.

Al inscribirse la operación en un modelo follow the sun, la célula funciona en 24/7 con una rotación por zona geográfica. Se mantienen tres puntos de sincronización cada día, cubriendo las transiciones de zonas. Estos reúnen al NOC, a los expertos operativos, al Soporte y a la Seguridad para: compartir el estado de avance por región, transmitir el relevo entre zonas (lo que ha funcionado, los ajustes de procedimiento sobre la base de los retornos del terreno) y arbitrar las prioridades de la próxima secuencia.La célula completa reúne, por rotación 24/7: a los equipos de Kernel & Virtualization (análisis del parche, backport, validación), VPS y Public Cloud (despliegue), NOC (pilotaje), Run & SRE (orquestación, anti-afinidad, migración en vivo), Datacenter Operations (intervenciones materiales), Soporte al cliente

(solicitudes de clientes), Seguridad (vigilancia, perímetro, fin de operación) y

Comunicación

(transparencia, notificaciones dirigidas).

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

El riesgo principal en esta etapa es la explotación de la vulnerabilidad, lo que provoca un bloqueo del host no parcheado. La célula de crisis decide aplicar el parche globalmente antes de la fase de reinicio. En caso de explotación de la vulnerabilidad, el bloqueo de un host provocará su reinicio y la aplicación automática del parche. Además, existe el riesgo de que la CVE sea explotada para una toma de control malintencionada 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 consiga utilizar la vulnerabilidad para tomar el control del host. Siendo este escenario catastrófico, sabemos que cada minuto cuenta.Una decisión asumida: un parcheo unilateral con impacto controladoEl Comité Ejecutivo valida el

• Go/No-Go
• por la tarde: la primera región será tratada a la mañana siguiente. Para este número de máquinas, no existe ningún escenario sin impacto. Negociar una ventana de mantenimiento con cada cliente, verificar cada dependencia, orquestar cada reinicio a medida: son pasos materialmente incompatibles con un plazo aceptable respecto al riesgo de seguridad.
• La célula de crisis toma, por tanto, una decisión asumida:

un parcheo unilateral con impacto controlado, aplicado sin esperar al acuerdo individual de cada cliente, sabiendo que algunos servicios sufrirán una interrupción. El razonamiento se resume en tres puntos:no parchear expone a todo el parque a un fallo de severidad elevada;

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, aunque suponga impactar a una minoría de manera temporal.

• La prioridad ya no es evitar el impacto, sino
• minimizarlo, diluirlo y hacerlo previsible
• . Esta es la línea que estructura toda la operación: follow the sun, priorización de las regiones y planificación anti-afinidad.

Miércoles 8 de julio: inicio desde SídneyLa elección de Sídney para probar el despliegue es trivial: el número de hosts es limitado, y la franja de despliegue en horario no operativo local (durante la noche) corresponde al horario de oficina de los equipos en Europa. Empezar por la región más al este permite:de operar en la zona menos cargada;de validar el procedimiento en condiciones reales, a escala reducida, antes de la industrialización;de recopilar las primeras impresiones antes de lanzar las regiones europeas y norteamericanas.

Las primeras oleadas de patch + reboot se aplican en los hosts

VPS

en Australia. La región SYD2 finaliza a primera hora de la tarde (hora de París), sin incidentes. Los procedimientos se adaptan basándose en las impresiones del terreno.

En cuanto el procedimiento se estabiliza, se inicia el follow the sun: cada región toma el relevo a su vez, durante su mañana local, transmitiendo el contexto a la siguiente. La primera oleada europea (RBX, GRA6, WAW, DE, SBG, MIL, UK) se lanza esa misma tarde, a las 18:30 hora de París.

Dos perímetros, dos exposiciones: Primero VPS, después Public CloudEl despliegue no es uniforme. VPS y Public Cloud difieren tanto en su arquitectura como en su exposición al cliente. El número de máquinas virtuales en los hosts VPS es mayor y muchas empresas y particulares utilizan VPS para infraestructuras de prueba; la probabilidad de que un cliente pruebe el código de explotación en su máquina virtual es muy elevada y el impacto también lo es debido al número de máquinas virtuales en cada host.En el

• VPS, el perímetro por host está contenido y el impacto en el cliente por reinicio permanece controlado. Los lotes pueden encadenarse rápidamente, lo que permite asegurar una gran parte del parque desde las primeras 24 horas.
• El Public Cloud

presenta una exposición de otro orden. Una región concentra miles de clientes, y un host puede alojar instancias críticas. Las regiones más importantes cuentan con cientos o incluso miles de hosts con infraestructuras de cliente virtuales complejas. Decidimos priorizar:

por tamaño de región: las regiones con menor densidad se tratan primero, para validar la robustez del procedimiento a escala;por número de clientes expuestos : las regiones con gran volumen se orquestan con una granularidad más fina, lote a lote, para diluir el riesgo.Umbrales de parada y control del tempoCada oleada de reinicios está sujeta a un umbral de parada

: si el número de hosts averiados simultáneamente supera un umbral definido, la oleada se suspende. Este umbral se fija 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 parada a las 06:00 o a petición del centro de datos local.

Este dispositivo permite no agravar una situación de avería de hardware continuando con el reinicio de hosts que los técnicos del DC aún no han podido tratar. Introduce un punto de regulación entre la automatización del software y la realidad física del terreno.No reiniciar simultáneamente dos instancias de un mismo proyecto: la anti-afinidad como salvaguardaEl principal riesgo para nuestros clientes durante 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 garantizan una resiliencia de la aplicación capaz de hacer frente a un fallo del proveedor. Un cliente que ha repartido sus cargas de trabajo en varios hosts para asegurar su alta disponibilidad no debe ver cómo todas sus instancias se reinician al mismo tiempo. Se tomó la decisión de ir más allá del cumplimiento de las reglas de anti-afinidad que se hayan podido definir en los despliegues de los clientes.

Así, para cada proyecto de cliente que disponga de instancias repartidas en varios hosts, nuestros orquestadores calculan un grafo de co-localización. En ningún momento se reinician en la misma ventana dos hosts que contengan instancias del mismo proyecto: se definen

oleadas mutuamente excluyentes

, y un host debe volver a estar en servicio antes del inicio del siguiente en la misma clase de anti-afinidad.Esta anti-afinidad 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 secuenciar el impacto para que sea absorbible por parte de la aplicación. Los clientes cuyas instancias dependan todas de un único host sufren una interrupción puntual, cuya ventana se anuncia.Live-migration prioritaria de servicios y cargas de trabajo sensiblesDetrás de cada instancia de cliente se encuentran controladores, API, planos de datos y bases internas. Un reinicio no controlado de los hosts que albergan estos servicios crearía

deadlocks

: un servicio interno no disponible bloquea el resto de los reinicios, lo que bloquea el parcheo. Por otra parte, algunos servicios de OVHcloud se basan en máquinas virtuales alojadas en las instancias de Public Cloud. Tener en cuenta estos casos es indispensable 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, después, el host se libera para reiniciar.Este procedimiento es largo y consume intensivamente 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 una atención especial: 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 tanto como sea posible. Esta migración suave permite evitar las caídas en cascada en los servicios y asegurar que las herramientas de soporte a las operaciones sigan disponibles.Incidentes técnicos y ajustes durante la operaciónUna operación de esta magnitud no se desarrolla sin incidentes. Varios problemas técnicos se encontraron y resolvieron durante la campaña.VMs que no se reinician tras el reinicio del host

El primer incidente importante apareció desde la primera oleada europea: algunas máquinas virtuales no se reiniciaban tras el reinicio de su hipervisor. Nova compute señalaba «Instance shutdown by itself» sin 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 al reiniciar sin sincronización por parte de la API. El parche aplicado es desactivar y enmascarar libvirt-guests.service en los hosts antes de reiniciar. A partir de este arreglo, los reinicios automáticos de las VMs funcionan.Corrupción de datos en los servicios síncronosLa noche del segundo día, el sistema de monitorización interno señala datos corruptos en varias VMs repartidas en 3 clústeres

. La causa probable: el reinicio forzado intervenía en pleno proceso de escritura en disco. El

graceful shutdown se amplía entonces a 60 segundos antes del kill forzado, para dar tiempo a que las escrituras finalicen. Se ha puesto en marcha un script de reinicio automático de las máquinas virtuales que permanecieron apagadas.Deadlock de API en ParísEn la noche del segundo al tercer día, las API Nova y Neutron en París entran en deadlock mutuo

: la API Neutron (limitada a 10 procesos) se satura bajo una ráfaga de peticiones de Nova, devolviendo errores HTTP 503 durante unas dos horas. La solución consiste en aumentar los

workers de Neutron de 10 a 30 y los procesos de Apache de 10 a 32. Las zonas B de París y Milán se posponen

mientras se estabilizan.

Saturación del soporte en BHS

En el sitio de BHS (Canadá), el tráfico de la API alcanza 10 veces el tráfico máximo habitual, saturando el Manager y el soporte. Algunos clientes descubrieron el impacto antes de haber recibido la comunicación. Este caso ilustra de forma concreta las reacciones en cadena dentro de la infraestructura.Todos estos errores y problemas encontrados se han gestionado en el marco de las operaciones, pero se tendrán en cuenta para implementar las mejoras adaptadas de manera duradera.Los reinicios y las intervenciones de hardwareUn reinicio de decenas de miles de máquinas implica también una dimensión de hardware

. Existe una tasa de fallos inherente a cualquier reinicio de servidor. Durante la primera noche, alrededor de 20 a 30 hosts de 6000 no volvieron solos: módulos de memoria defectuosos, configuración de la BIOS, interfaz de red inactiva. En Estados Unidos, varios hosts requirieron una

• extracción de la batería CMOS y un drenaje de alimentación antes de volver a encenderse; un perfil de hardware recurrente.
• Cada centro dispone de técnicos de centro de datos
• movilizados como refuerzo durante la campaña. Su función:intervenir de urgencia en los hosts que fallan al reiniciar y que son señalados por los orquestadores;reemplazar las piezas defectuosas

(discos, módulos de memoria, fuentes de alimentación);realizar las tareas de proximidad que ninguna herramienta puede automatizar:

hard reboot

físico, comprobación de los indicadores luminosos, intervención en el rack.

Los técnicos del centro de datos operan en

modo de intervención prioritaria en los hosts con fallos, en coordinación con los equipos de Run/SRE que priorizan según la exposición del cliente del host. Un host que alberga instancias críticas y no vuelve a funcionar tiene prioridad sobre un host vacío. Esta priorización cruzada —software y física— es lo que mantiene el ritmo de la operación.Comunicación y soporte: informar a los clientes afectados

Un patching unilateral con impacto controlado no puede concebirse sin un esfuerzo de comunicación proporcionado.Una comunicación dirigida y progresivaAnte la dinámica del follow the sun, una comunicación global e indiferenciada no habría tenido ningún sentido. La estrategia elegida fue una comunicación dirigida y progresiva: dirigida únicamente a los clientes cuyas instancias están alojadas en los hosts programados para el reboot, y activada a medida que avanzaba la operación, región por región, oleada por oleada.

Inicialmente, se toma la decisión de

no activar una status-page pública

, para no exponer la secuencia de despliegue. Las comunicaciones se realizan mediante targeted communications a través de nuestro portal de soporte, con envío de correos electrónicos a los clientes que tienen un nivel de soporte Business y Enterprise.Observación: algunos mensajes no se entreganLas herramientas de comunicación tienen límites técnicos. 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 observación, se decide un giro

el segundo día: implementar un

banner condicional en el Manager

mediante un feature flipping: si el usuario conectado figura en la lista de cuentas de cliente (NICs) afectadas, se muestra un mensaje informativo. El desarrollo se lleva a cabo durante el día y el banner se despliega el tercer día. También se crea una status-page de Public Cloud en ese momento.A pesar de estos dispositivos, algunos mensajes no llegaron a sus destinatarios: direcciones de contacto obsoletas, notificaciones filtradas, desfase entre la hora prevista del reboot y la hora de envío. Algunos clientes descubrieron el impacto sin haber sido advertidos previamente. Estos puntos de ruptura se identifican como ejes de mejora prioritarios al finalizar el plan de mitigación inicial.El soporte como canal de último recurso

Para los clientes no informados, o que solicitan precisiones, el

soporte al cliente

Perspectivas

La CVE-2026-53359 ponía a nuestros clientes y a nuestras infraestructuras en riesgo. El plan de acción de mitigación conllevó un impacto para el cliente: contenido, secuenciado, anunciado, pero real. Comunicar de manera más detallada durante la ejecución del plan de acción, mientras la infraestructura no estuviera parcheada, habría aumentado significativamente el riesgo para nuestros clientes, al empujar a algunos de ellos a «probar» el exploit disponible públicamente.

Reiniciar un parque de envergadura mundial con un impacto nulo no era un objetivo alcanzable. El objetivo era, por tanto, la menor magnitud de impacto compatible con la seguridad de todo el parque.

Parchear y reiniciar todos los hosts de Public Cloud y VPS nunca se había hecho con esta restricción de tiempo. Este procedimiento de emergencia se puso en marcha teniendo en cuenta el riesgo relacionado con la vulnerabilidad. Los casos anteriores siempre se habían tratado mediante un reinicio progresivo utilizando la tasa de rotación natural de las máquinas virtuales en la infraestructura, combinado con live-migrations ad-hoc planificadas a largo plazo.

Los equipos implicados en esta operación realizaron una hazaña con un número de averías e impacto para el cliente muy razonable en proporción al tamaño del proyecto. Sin embargo, conscientes de que los próximos meses podrían dar lugar a otras publicaciones de vulnerabilidades del kernel, parece claro que este procedimiento de emergencia tendrá que repetirse. Tendremos que hacerlo mejor la próxima vez, tanto en el control del impacto bruto de los reinicios como en la información previa a los clientes y en el procedimiento de acompañamiento de los clientes afectados durante las operaciones. Así pues, en los días y semanas venideros, identificaremos los impactos principales en nuestros clientes que hayan sufrido averías complejas, y trabajaremos los problemas encontrados durante las operaciones internamente, en el post mortem, con el objetivo de mejorar nuestros procedimientos en el futuro.