At the beginning of July, a major vulnerability called Januscape (CVE-2026-53359) shook the world of virtualization. This critical flaw allowed an attacker to escape from a virtual machine to compromise the physical server hosting it, a disaster scenario for any cloud player. For OVHcloudthe risk was immense, threatening tens of thousands of hosts and nearly a million virtual machines customers around the world.
Why was a forced restart without notice decided?
Faced with this threat, the hosting company’s teams quickly evaluated their options. Hot patching seemed too risky on a large scale, and live migrating VMs to already secure hosts would have taken months, leaving the fleet exposed for too long. The only viable solution, although radical, was to integrate the patch directly and restart the whole thing of the servers concerned to counter this security breach.
The most daring decision was to carry out a “ unilateral patching controlled impact”. Clearly, no maintenance window negotiated with each customer, but forced restarts to act as quickly as possible. The executive committee validated this approach to protect as many people as possible, accepting a inevitable impact for a minority to secure the infrastructure before attacks are launched.
How did this operation take place on a global scale?
The operation began in Sydney, a small region chosen as a testing ground to test the procedure in real conditions. The fix has been applied on the kernel version Linux used by the company, then a strategy “ follow-the-sun » (FTS) was initiated: each region took over every morning, thus ensuring continuous intervention on 11 days across Europe and North America.
To limit the damage, strict safeguards were put in place. Automatic shutdown thresholds paused the wave if too many hosts failed simultaneously. Above all, colocation graphs have been calculated to never restart two servers hosting machines from the same client project simultaneously, thus preserving their high availability by best applying an “anti-affinity” rule.
What were the impacts and lessons learned?
Despite the precautions, the operation was not smooth, requiring a patching on a very large scale. Virtual machines did not restart on their own, victims of software conflicts or hardware failures like faulty memory sticks. Data corruption was noted on three clusters, and APIs in the Paris region remained blocked for two hours, delaying a wave of updates.
The communication was deliberately limited during operation to avoid exposing the deployment sequence and encouraging malicious actors to test the exploit. Julien Levrard, the CISO, describes the intervention as “ exploit » technical but recognizes the margins for progressparticularly on customer information. He warns that the exercise will be repeated and concludes: “ We will have to do better next time ».
