On July 19, OVHcloud’s operations teams stood down. Behind them lay an 11-day emergency campaign: tens of thousands of hypervisor hosts rebooted in coordinated waves, with roughly a million customer virtual machines riding on top, all to close Januscape (CVE-2026-53359), the KVM vulnerability disclosed on July 7.

Two days later, on July 21, a small fix was quietly merged into the upstream Linux kernel. Same part of the kernel. On August 6, the bug it fixed received a CVE number and a name: Zapscape (CVE-2026-64561).

OVH wrote up its Januscape campaign in an unusually transparent post-mortem, and The Register covered the operation in detail, so theirs is the story we can tell with numbers. But they were not alone. Every operator of exposed KVM infrastructure faced some version of the same decision in July, on their own calendar, with their own reboot waves. And every fleet that rebooted before late July has one thing in common: the kernel it rebooted onto could not have carried the Zapscape fix, because that fix did not exist publicly until July 21.

One month after Januscape, the question is back on the table. The technical details, affected versions, mitigations, and patch status live in our Zapscape advisory.

This piece is about the decision.

What Zapscape is

Zapscape is a vulnerability in KVM, the virtualization layer built into the Linux kernel. According to the researcher who found and published it, an attacker with root inside a guest virtual machine can use it to escape the guest and run code as root on the host. Root on the host is root over everything: the memory, disks, and network traffic of every other tenant’s virtual machine on the same hardware.

The published proof-of-concept does not run as-is against every kernel, and it is tempting to file that away as good news. But it is not protection. The flaw is present either way, and adapting an exploit to a particular kernel is ordinary work for anyone motivated to do it.

The options on a KVM operator’s table

For a fleet that hosts other people’s virtual machines, the menu looks like this:

  • Disable nested virtualization. Since the attack requires nested virtualization to be enabled on the host, this move closes the attack path. It also breaks every tenant who relies on the feature, and a provider generally cannot see which tenants those are. And the setting only takes effect when the KVM module reloads, so applying it costs a guest drain or a host reboot anyway.
  • Reboot everything into a patched kernel. This one begins with a wait: as of publication, stock kernels for several major distributions do not yet carry the Zapscape fix. And then, the waves of reboots need to be coordinated.
  • Live-migrate workloads off each host, patch it, migrate back. Works per host. At fleet scale, it turns into months.

This menu is not hypothetical. OVH worked through it publicly for Januscape and documented why each path fell away.

Waiting for official patched kernels would have meant staying exposed on a third party’s schedule, so they backported the fix onto their own Debian production kernels. Migrating a million virtual machines would take months. Disabling nested virtualization was ruled out because they cannot know which customers depend on it.

They passed on live patching too. In their judgment, it would cut into the hardening and detection capabilities of the custom kernels they build themselves. That is a real consideration for an operator maintaining its own hardened kernel line, and it is specific to custom kernels. A fleet running stock distribution kernels has no in-house hardening for a livepatch to collide with.

At the end, their decision was: reboots.

OVH executed the reboot campaign about as well as it can be executed. Their post-mortem describes a 24/7 crisis cell, three synchronization meetings a day, and follow-the-sun handoffs between regions as the waves moved across the globe. It still took 11 days.

What a reboot campaign costs, even when it goes well

The most valuable thing about OVH’s post-mortem is its honesty about the friction. On the first night, 20 to 30 hosts out of 6,000 rebooted did not come back on their own: failed memory modules, BIOS quirks, dead network interfaces, machines that needed hands in a datacenter. A service conflict kept some VMs from restarting after their hosts returned. Forced shutdowns corrupted data on some synchronous services until the team lengthened the graceful-shutdown window.

The friction was not confined to the machines. One region’s API deadlocked under the restart surge and returned errors for around two hours, and support traffic at one site reached 10 times its normal peak. OVH’s own assessment was that failures and customer impact stayed reasonable in proportion to the project’s scale. That is what a good outcome looks like.

Then comes the sentence in the post-mortem that matters more than any of the numbers. “Aware that the coming months could see further kernel vulnerability disclosures, it appears established that this emergency procedure will need to be repeated.” (Translated from the French original.)

It took 18 days for that prediction to come true.

The calendar behind it is worse than two data points. Since May, we have been publishing kernel security advisories at a pace we have never seen before. The run includes local-root vulnerabilities like GhostLock, DirtyClone, and RefluXFS (that last one with no reliable workaround short of a kernel update), an information leak that could read a server’s SSH host keys, and now two KVM vulnerabilities a month apart.

When Januscape hit, we looked at why this is happening: researchers and vendors alike are using AI models to audit kernel code at scale, and those audits keep surfacing bugs that sat unnoticed for a decade or more. Nothing about that has changed. Plan on the cadence continuing.

The fleets that didn’t reboot

While the July reboot waves were rolling through datacenters, a quieter version of the same story was playing out. Servers running KernelCare picked up the Januscape fix as a livepatch, applied in memory to the running kernel, on live production machines, with no maintenance window and no tenant noticing anything at all. The Januscape advisory’s status history has those livepatches rolling out on the main feed by July 10: the same KVM fix the reboot waves were delivering, applied while those waves still had more than a week to run.

KernelCare is live kernel patching, provided by CloudLinux in partnership with TuxCare, our sister company. The KernelCare agent checks for new patches every four hours and applies them to the running kernel automatically. Patches are developed and tested against each distribution’s kernels, and any of them can be rolled back, also without a reboot. One approach covers a mixed fleet: CloudLinux, AlmaLinux, RHEL, Ubuntu, Debian, Rocky Linux, Oracle Linux, and more.

For Zapscape, KernelCare livepatches have already started rolling out to the feeds for Debian and Ubuntu as of publication, with more versions and distributions following soon. Servers running KernelCare receive them automatically on the next update cycle.

The point is that with KernelCare, “patched” stops requiring “rebooted.”

The economics follow a similar line. Every CVE severe enough to force an emergency campaign brings the whole bill back: the planning, the waves, the hosts that fail to come up, the support surge. A KernelCare license is a flat per-server cost that stays the same whether the month brings one kernel vulnerability or six. And there is a low-risk way to test the fit because KernelCare comes with a two-week free trial to deploy it on part of a fleet before committing.

Somewhere in the upstream kernel tree, the fix for the next Zapscape may already be merged, quiet and unnamed. When it gets its name, your fleet will hear the same question again. The answer does not have to involve asking a million virtual machines to hold still.