OVH mass-rebooted hosts to patch Januscape bug

OVH says it used its Sydney, Australia datacenter as the first proving ground for an emergency fix to Januscape, the critical KVM guest-to-host escape tracked as CVE-2026-53359.

The bug let an attacker with root access inside a guest VM execute code as root on the host, crash the host, or compromise other guest VMs running there. For a cloud provider built on Linux kernel-based virtual machine, that is about as bad as it gets.

In a detailed post published Monday, OVH CISO Julien Levrard said the company patched tens of thousands of hosts running about a million virtual machines. Rather than disable nested virtualization, rely on live patching, or slowly migrate workloads to already-patched machines, OVH chose to backport a fix into the Debian distribution it uses in production and then reboot all hosts.

Customers were warned in advance, but not asked for consent. OVH said its executive committee approved that approach for three reasons:

Recommended reading

UK data centre boom hits a water reality check

• the need to patch before attacks began
• handling cases one by one would leave the cloud exposed for longer
• protecting the largest number of customers, even if a minority saw disruption

Levrard also said OVH deliberately kept details of the rollout quiet while patching was underway.

“Communicating in more detail during the execution of the mitigation plan, while the infrastructure remained unpatched, would have significantly increased the risk for our customers, potentially leading some to 'test' the publicly available exploit.”

How OVH tested the rollout in Sydney

Sydney was chosen because it is one of OVH’s smaller regions, and Australia’s east coast sits eight hours ahead of France, letting European teams work during business hours while hitting a quieter local period.

The rollout was staged in waves, with a shutdown threshold of 15 hosts failing simultaneously in high-density regions or five hosts elsewhere. OVH said it went beyond standard anti-affinity rules by building a co-location graph for each customer project, making sure two hosts running instances from the same project were not rebooted in the same window.

Outages, failed restarts, and broken hardware

The process still ran into problems. Some VMs failed to restart after hypervisor reboots. Some suffered data corruption during forced shutdowns. OpenStack APIs misbehaved, causing hours of HTTP 503 errors and forcing one wave to be delayed. At one Canadian site, OVH said API traffic reached 10 times the usual peak, overwhelming management and support teams.

There were also hardware failures. According to Levrard, on the first night about 20 to 30 hosts out of 6,000 did not come back on their own due to faulty memory modules, BIOS configuration issues, inactive network interfaces, and even dead CMOS batteries.

Levrard called the operation “a remarkable feat,” but said OVH expects more kernel emergency work ahead and will need to improve both customer communications and the impact of future restarts.