If you run cloud workloads, this is the part of the incident response playbook you do not get to ignore: OVH tested a fix for a critical KVM escape bug by using its Sydney datacenter as the “crash test dummy,” then rebooted all those hosts. The bug is Januscape, also tracked as CVE-2026-53359. It let an attacker with root access inside a guest VM execute code as root on the host, crash that machine, or take over other guest VMs.

Januscape is the kind of guest-host escape that turns “isolated customer” promises into a liability nightmare. OVH explains why in practical terms: many major clouds use KVM to slice physical servers into virtual machines and rent those guests to clients. If one tenant’s VM can be used to crash other guests or even the whole host, it is not just one customer getting hurt. It is isolation itself that collapses. OVH says it treated fixing this as a priority, then moved fast enough that customers got advance notice, but not choice.

In a detailed post, OVH’s CISO Julien Levrard lays out the decision process and the trade-offs that led to the reboot plan. One mitigation was to disable nested virtualization by creating a two-line config file on each host. OVH rejected that option because it has “no way to see if its tenants need nested virtualization,” and it relies on nested virtualization to shift VMs to different physical hosts.

Another option was live patching. OVH decided that was not palatable because live patches could introduce instability. Live migration to patched hosts was also on the menu, but OVH rejected it as well, saying the process is slow and it could take months to move the entire fleet of tenant VMs to a Januscape-free environment. Months is a long time in the middle of a potentially weaponizable guest-host escape.

So OVH backported a Januscape fix into the Debian distribution it uses in production and rebooted all hosts. The company says its executive committee signed off on this approach for three explicit reasons: patch before attacks; treating cases individually would leave the OVH cloud vulnerable longer; and protecting the greatest number of customers while tolerating impact on a minority. There is also a second, quieter rationale: OVH chose not to communicate in more detail during execution. Levrard wrote that communicating more during the mitigation plan, while the infrastructure remained unpatched, would have increased the risk for customers, potentially leading some to “test” the publicly available exploit.

To test its approach, OVH started with Sydney. The region is smaller, and it gave the company a logistical advantage: Australia’s east coast is eight hours ahead of France, so teams in Europe can do the work during business hours. But the bigger point is that OVH wanted the operational learning first, before widening blast radius. The plan called for reboots to occur in waves, with a “shutdown threshold” that would halt wave progression if 15 hosts failed simultaneously in high-density regions, or five boxes in other regions.

The wave design was not just rack-by-rack choreography. OVH’s blog highlights the real risk during mass maintenance: it is not the reboot itself. It is the simultaneous interruption of multiple instances of the same project, which can break application resilience and cause failover stampedes. OVH says it decided to go beyond simply adhering to client-defined anti-affinity rules. For each client project with instances distributed across multiple hosts, the orchestrators calculate a co-location graph. At no time are two hosts running instances of the same project rebooted in the same window; mutually exclusive waves are defined, and a host must be back online before the next one is launched in the same anti-affinity class.

Even with that, OVH hit the kind of messy reality that makes incident response reports valuable. Some VMs did not restart after hypervisor reboot. Some saw data corruption during forced shutdowns. OpenStack APIs misbehaved, leading to hours of HTTP 503 errors and forcing postponement of one patching wave. At a Canadian site, API traffic spiked to 10 times the usual peak, overwhelming the manager and support teams.

Then there were hardware issues. Levrard reports that on the first night, about 20 to 30 hosts out of 6,000 did not recover on their own. He blames “faulty memory modules, BIOS configuration issues, inactive network interfaces.” Some machines needed new CMOS batteries. Levrard’s takeaway is that OVH’s approach was a “remarkable feat,” producing “a very reasonable number of outages and customer impact relative to the scale of the project.” But he also frames the next step as inevitable repetition: the coming months could bring further kernel vulnerability disclosures, so the emergency procedure will likely have to happen again.

The strategic stake for every cloud operator and every board overseeing one: mass reboot remediation works, but it comes with operational debt. OVH now plans a post-mortem analysis and says it needs to do better next time, both in managing the raw impact of restarts and in providing customers with advance notice and support during operations. For peers, the lesson is not “reboot harder.” It is that when you backport and reboot quickly, you are buying time with risk, and you should assume you will learn the hard way first.