---
title: "Patching at Fleet Scale, Twice: How DigitalOcean Closed Januscape and the AMD Safe RET Issue Without Customer Impact"
url: https://daily.dev/posts/patching-at-fleet-scale-twice-how-digitalocean-closed-januscape-and-the-amd-safe-ret-issue-without-enoi72tn8
source_url: https://www.digitalocean.com/blog/patching-januscape-amd-safe-ret
type: article
source: "DigitalOcean"
published: 2026-08-24T21:30:01.675Z
updated: 2026-08-24T21:30:41.351Z
tags: ["digitalocean"]
reading_time: 14
upvotes: 1
comments: 1
language: en
---

> ## Documentation Index
> Fetch the complete documentation index at: https://daily.dev/llms.txt
> Use this file to discover all available pages before exploring further.

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

**[DigitalOcean](https://daily.dev/sources/do)** · 14 min read · 1 upvotes · 1 comments

## Summary

DigitalOcean describes back-to-back fleet-wide security remediations three weeks apart. First, Januscape (CVE-2026-53359), a KVM nested-virtualization guest-to-host escape disclosed July 6, was patched across the entire hypervisor fleet within eight days via livepatching, with a long-tail of a few hundred 5.10-kernel dedicated hosts requiring full evacuation and rebuild rather than an unproven custom livepatch. Second, a privately disclosed AMD Zen 'Safe RET' speculative-execution flaw (compiler-inlined, unpatchable via livepatch) required rebooting all ~1,600 AMD hypervisors across twelve regions; using the capacity and automation playbook built during the first incident, the fleet was fully patched by August 5, a day before AMD's public bulletin. Both remediations reported zero confirmed customer-facing impact, relying on capacity refleeting, stranded-capacity reclamation, 24/7 pipeline monitoring, and customer-priority sequencing.

## Full article

daily.dev links to this article rather than hosting it. Read it at the original source: <https://www.digitalocean.com/blog/patching-januscape-amd-safe-ret>

## Questions this post answers

### What is Januscape CVE-2026-53359 and how does it affect KVM virtualization?

Januscape (CVE-2026-53359) is a flaw in KVM's handling of nested virtualization that lets a malicious guest escape into the host hypervisor, breaking the isolation boundary between customer workloads. Disclosed publicly on July 6 via the oss-security mailing list, it affected hypervisor fleets running Linux kernels including 6.1, 6.12, and 5.10, with the last requiring a custom livepatch since no upstream fix existed for that kernel line.

_Teams tracking KVM escape vulnerabilities can follow real-world remediation patterns like this on daily.dev._

### What is the AMD Safe RET vulnerability and why couldn't it be fixed with a livepatch?

The AMD Safe RET issue is a flaw where a precisely timed interrupt can disrupt Safe RET, the default Linux mitigation for Speculative Return Stack Overflow, potentially allowing information disclosure across privilege boundaries on Zen architecture processors. It could not be livepatched because the affected code was inlined by the compiler, leaving no function boundary to replace, forcing every affected host to be rebooted into a new kernel instead.

_Engineers weighing livepatch limits against reboot campaigns can dig into cases like this on daily.dev._

### How did DigitalOcean patch 1,600 AMD hypervisors before a public vulnerability disclosure without customer impact?

DigitalOcean was notified of the AMD Safe RET flaw through coordinated disclosure in late July, declared a formal incident the same day, and staged patched kernels fleet-wide by July 31. Using capacity refleeting and evacuation automation built during an earlier incident, the team live-migrated workloads off each of roughly 1,600 hosts across twelve regions, rebooted them into the patched kernel, and finished by August 5, a day before AMD's public bulletin.

_Ops teams designing zero-impact reboot campaigns at scale can find playbooks like this on daily.dev._

## Community discussion

Top comments from developers on daily.dev.

**@trevorsuna** · 0 upvotes

> The decision not to improvise a custom livepatch for the long tail is good risk management. Reclaiming capacity and practicing evacuation during the first incident clearly paid off for the reboot-only AMD fix; fleet patching is as much a capacity-planning problem as a security one.

## Similar posts on daily.dev

- [Januscape vulnerability CVE-2026-53359 mitigations available](https://daily.dev/posts/januscape-vulnerability-cve-2026-53359-mitigations-available-e9giiytfe) · Ubuntu · 0 upvotes · 0 comments
- [New Linux kernel flaw allows VM escape on Intel, AMD devices](https://daily.dev/posts/new-linux-kernel-flaw-allows-vm-escape-on-intel-amd-devices-pgteqqq1i) · BleepingComputer · 2 upvotes · 0 comments

---

Tags: [#digitalocean](https://daily.dev/tags/digitalocean)

[View this post on daily.dev](https://daily.dev/posts/patching-at-fleet-scale-twice-how-digitalocean-closed-januscape-and-the-amd-safe-ret-issue-without-enoi72tn8)
