# Patching at Fleet Scale, Twice: How DigitalOcean Closed Januscape and the AMD Safe RET Issue Without Customer Impact

DevFeed: [Patching at Fleet Scale, Twice: How DigitalOcean Closed Januscape and the AMD Safe RET Issue Without Customer Impact](<https://devfeed.tech/articles/patching-at-fleet-scale-twice-how-digitalocean-closed-januscape-and-the-amd-safe-ret-issue-without-customer-impact-19928.md>)

Original publisher: [Read original article](<https://www.digitalocean.com/blog/patching-januscape-amd-safe-ret>)

Author: Tim Lisko

Published: 2026-08-24T21:25:19Z

Content type: article

Language: en

Sources: [DigitalOcean](<https://devfeed.tech/sources/digitalocean.md>)

Topics: [Digital Ocean](<https://devfeed.tech/topics/digital-ocean.md>), [virtualization](<https://devfeed.tech/topics/virtualization.md>), [vulnerability](<https://devfeed.tech/topics/vulnerability.md>), [Cloud](<https://devfeed.tech/topics/cloud.md>), [cloud security](<https://devfeed.tech/topics/cloud-security.md>), [Security](<https://devfeed.tech/topics/security.md>), [Exploit](<https://devfeed.tech/topics/exploit.md>), [Kernel](<https://devfeed.tech/topics/kernel.md>), [Linux](<https://devfeed.tech/topics/linux.md>)

Tags: [cloud](<https://devfeed.tech/tags/cloud.md>), [cloud-computing](<https://devfeed.tech/tags/cloud-computing.md>), [cve](<https://devfeed.tech/tags/cve.md>), [digitalocean](<https://devfeed.tech/tags/digitalocean.md>), [engineering](<https://devfeed.tech/tags/engineering.md>), [exploit](<https://devfeed.tech/tags/exploit.md>), [infrastructure](<https://devfeed.tech/tags/infrastructure.md>), [kernel](<https://devfeed.tech/tags/kernel.md>), [linux](<https://devfeed.tech/tags/linux.md>), [security](<https://devfeed.tech/tags/security.md>), [trust-security](<https://devfeed.tech/tags/trust-security.md>), [update](<https://devfeed.tech/tags/update.md>), [virtualization](<https://devfeed.tech/tags/virtualization.md>), [vulnerability](<https://devfeed.tech/tags/vulnerability.md>)

## AI overview

DigitalOcean describes how it responded to two serious vulnerabilities affecting its hypervisor fleet: Januscape, a KVM nested-virtualization flaw, was addressed with fleet-wide livepatching, while a separate AMD hypervisor vulnerability required kernel updates and reboots across roughly 1,600 hypervisors. The article reports zero confirmed customer-facing impact.

## Source excerpt

Setting the stakes In early July, security researcher Hyunwoo Kim discovered Januscape (CVE-2026-53359), a flaw in KVM's handling of nested virtualization that could allow a malicious guest to escape into the host hypervisor. It was disclosed publicly on July 6 via the Linux oss-security mailing list. For a cloud provider, a guest-to-host escape is the most serious class of vulnerability there is: the hypervisor is the boundary that keeps each customer's workloads isolated from each other, and from our infrastructure itself. We responded, patched the entire fleet in eight days with zero confirmed customer-facing impact, and drafted a post about how we did it. Then, before we could hit publish, it happened again. In late July we learned of a second and unrelated vulnerability affecting our entire AMD hypervisor fleet, that could not be livepatched. Roughly 1,600 hypervisors needed a kernel update and a reboot. So now this story is about two responses, three weeks apart. The first built the muscle. The second proved it was repeatable, at a larger scale, and on a harder constraint. Here's how both played out, and why two of the most serious vulnerability classes in cloud computing ended up feeling like just another couple of weeks for us. Act one: Januscape The fast path: fleet-wide livepatching Our response kicked off the same night the vulnerability was disclosed. When public exploit code surfaced late in the evening of July 6, the Kernel Engineering team was paged and dug in immediately. Engineers reproduced the exploit in an isolated environment, confirmed which kernel lines were affected, and built the first working livepatch before 1 AM, roughly 45 minutes after answering the page. Livepatching lets us fix a running kernel in place, with no reboot, no migration, and no observed disruption to the customer. A few hours later, patches for the kernel versions (6.1 and 6.12) that run the majority of our hypervisor fleet were ready to ship. For the remainder, we had to