OVH молча перезагрузил миллион чужих виртуалок, чтобы закрыть дыру Januscape в KVM

Французский облачный провайдер OVH тайно и в экстренном режиме перезагрузил десятки тысяч физических хостов, на которых работало около миллиона клиентских виртуальных машин, чтобы закрыть критическую уязвимость Januscape (CVE-2026-53359) в гипервизоре KVM. Клиентов предупредили заранее, но права отказаться не дали никому. И вот что здесь важно лично для вас, если вы арендуете VPS: это не частная выходка одного хостера, а показательный сценарий того, как любой провайдер может распорядиться вашим сервером ради безопасности всего облака. Ниже: чек-лист из четырёх пунктов, который снижает риск простоя при такой массовой перезагрузке.

Уязвимость Januscape: почему «побег» из одной виртуалки, кошмар для всего облака

CVE-2026-53359 относится к самому неприятному классу облачных багов, guest-host escape, «побег» из гостевой машины на хост. Атакующий с root-правами внутри одной арендованной виртуалки мог выполнить код как root уже на самом физическом сервере: обрушить его целиком или захватить все остальные гостевые ВМ, которые крутятся на том же железе.

Это прямое нарушение главного обещания, за которое вы вообще платите деньги при аренде, изоляции соседей по серверу. KVM встроен в ядро Linux, и на нём построена виртуализация огромного числа облаков и VPS-хостеров. Так что уязвимость такого класса в гипервизоре, история отраслевого масштаба, а не только «проблема OVH». О ситуации в понедельник, 20 июля 2026 года, развёрнутым постом рассказал CISO OVH Жюльен Леврар (Julien Levrard), редкий случай, когда провайдер публично раскрывает внутреннюю кухню инцидента.

Патч без спроса: почему OVH выбрал массовую перезагрузку

Самое интересное в этой истории: то, как OVH отверг все «щадящие» варианты. На бумаге у провайдера было несколько способов закрыть дыру в KVM аккуратно, без простоя. На практике каждый уперся в стену.

• Отключить вложенную виртуализацию (nested virtualization) двумя строчками конфига на каждом хосте. Не подошло: OVH не видит, кому из клиентов она реально нужна, да и сам использует её для переноса ВМ между серверами.
• Live-патч: наложить исправление на живое ядро без ребута. Отклонили из-за риска нестабильности.
• Живая миграция (live migration) на уже пропатченные хосты. Слишком медленно: перенос всего парка занял бы месяцы, а всё это время облако оставалось бы дырявым.

В итоге инженеры бэкпортировали исправление в собственную production-сборку Debian и решили просто перезагрузить весь парк хостов. Исполком одобрил эту массовую перезагрузку по трём соображениям: успеть закрыться до первых атак; не растягивать уязвимое состояние облака на индивидуальные согласования; защитить максимум клиентов, смирившись с ущербом для меньшинства. Для тех, у кого критичный сервис жил на одном инстансе одного хоста, «меньшинство» это они и есть.

Тишина по расчёту и Австралия в роли подопытного кролика

OVH держал план в секрете сознательно. Формулировка Леврара звучит почти цинично, но логика в ней железная:

«Более детальное информирование в ходе выполнения плана, пока инфраструктура оставалась непропатченной, значительно повысило бы риск для клиентов, часть могла бы решить „протестировать“ публично доступный эксплойт».

То есть подробный рассказ о незакрытой критической дыре в реальном времени сам по себе стал бы наводкой для атакующих. Поэтому процедуру сначала обкатали на регионе в Сиднее, одном из меньших у OVH. Причина географическая: восточное побережье Австралии на 8 часов впереди Франции, так что европейские инженерные команды работали в свои обычные рабочие часы, но в «тихое» для сиднейских клиентов ночное время. Регион в буквальном смысле стал crash-test dummy, на нём отрабатывали процедуру массовой перезагрузки, прежде чем катить её на остальной мир.

Волны, пороги и граф со-размещения

Перезагружать миллион виртуалок разом: верный способ уронить всё и сразу. Поэтому OVH катил ребуты волнами с несколькими предохранителями.

Первый: «порог остановки» (shutdown threshold): если одновременно падает 15 хостов в регионах высокой плотности или 5 в остальных, процесс притормаживается. Второй, более тонкий,: граф со-размещения (co-location graph). Оркестраторы строят для каждого клиентского проекта карту того, на каких хостах лежат его инстансы, и следят, чтобы два сервера с ВМ одного проекта никогда не перезагружались в одном окне. Хост обязан вернуться в строй раньше, чем стартует следующий из того же класса anti-affinity. Как формулирует сам OVH:

«Главный риск не сама перезагрузка, а одновременное прерывание нескольких инстансов одного проекта».

Здесь и кроется практический вывод: механизм защищает только тех клиентов, кто заранее разнёс свои инстансы по разным хостам через политику anti-affinity. Один инстанс на одном хосте граф со-размещения не спасёт, падать ему нечем страховаться.

Не всё прошло гладко

Операция не была стерильной. Часть ВМ не поднялась после перезагрузки гипервизора. Была зафиксирована порча данных при принудительном выключении инстансов. Сбоил и API OpenStack. Это ровно те риски, которые ложатся на арендатора VPS, если он рассчитывал на «сервер просто всегда работает».

Стоит держать в голове и общий фон: The Register в смежных материалах прогнозирует рост цен на облачные услуги на 5-10% к середине 2026 года. То есть платить за инфраструктуру придётся больше, а гарантий «никаких внеплановых ребутов» это не добавляет.

Что уязвимость Januscape значит для арендатора VPS: чек-лист из четырёх пунктов

Вот обещанный в начале список. Он не про OVH конкретно: про любой сценарий, когда провайдер вынужден дёрнуть ваш сервер ради безопасности платформы.

1. Держите снапшоты и бэкапы вне того же хоста. Порча данных при форс-выключении в кейсе OVH не гипотеза, а то, что реально случилось. Резервная копия на том же физическом сервере от такого не защищает.
2. Проверяйте, поднимается ли VPS после ребута. Раз в какое-то время перезагрузите сервер сами и убедитесь, что все сервисы стартуют автоматически. Часть ВМ у OVH не встала именно из-за кривого автозапуска.
3. Не вешайте критичный сервис на один инстанс. Разносите нагрузку по разным хостам, регионам, а лучше, провайдерам. Механизмы вроде anti-affinity работают только тогда, когда у проекта есть что разносить.
4. Читайте SLA и политику по внеплановым перезагрузкам. Прозрачный патч-менеджмент и понятные окна обслуживания, такой же аргумент при выборе хостера, как цена и скорость дисков.

Если вам важен стабильный доступ к сервисам и приватность, Sigma сдаёт VPS с прозрачными условиями и поддержкой, у которой можно уточнить политику обслуживания заранее.

Частые вопросы

Могут ли мой VPS перезагрузить без моего согласия?

Да. Как показал кейс OVH, при критической уязвимости уровня guest-host escape провайдер вправе принудительно перезагрузить хост ради безопасности всей платформы. Обычно клиентов уведомляют заранее, но право отказаться дают редко.

Что такое guest-host escape и чем он опасен именно для арендатора?

Это когда атакующий из своей виртуалки вырывается на физический хост и получает доступ к соседним ВМ на том же железе. Рушится изоляция между клиентами: то самое, за что вы платите при аренде VPS.

Как понять, что мой провайдер серьёзно относится к таким рискам?

Смотрите на прозрачность: публикует ли он разборы инцидентов, есть ли внятная политика внеплановых перезагрузок, поддерживает ли anti-affinity и живую миграцию. OVH здесь как раз показал редкий уровень открытости, опубликовав пост CISO.

Источники

The Register как OVH тайно закрывал уязвимость Januscape массовыми перезагрузками