Januscape (CVE-2026-53359): Wie wir alle Proxmox-Cluster ohne Downtime gepatcht haben. Ein Werkstattbericht

Eine kompromittierte virtuelle Maschine mit den passenden Voraussetzungen, und im Worst Case hat ein Angreifer Codeausführung im Kernel-Kontext des Hosts, auf dem noch Dutzende weitere VMs laufen. Kein hypothetisches Szenario, sondern genau das Bedrohungsbild, das die Schwachstelle „Januscape“ in KVM/x86 im Juli 2026 real werden ließ.

Wie kritisch eine solche Schwachstelle für jeden Virtualisierungsbetreiber ist, zeigt ein aktueller Fall aus der Claranet-Praxis: Innerhalb kürzester Zeit mussten alle Proxmox-Nodes abgesichert und gepatcht werden. Ohne Ausfallzeit für die laufenden VMs und ohne dass Kunden selbst tätig werden mussten.

Die Ausgangslage: Eine Lücke bricht die Isolation zwischen Gast und Host

Die als „Januscape“ bekannte Sicherheitslücke (CVE-2026-53359) betrifft KVM (Kernel-based Virtual Machine) auf x86-Architektur und ermöglicht einen sogenannten Guest-to-Host-Escape: Ein Angreifer mit ausreichenden Rechten in einer Gast-VM kann über die Lücke aus dieser ausbrechen und Kontrolle über das darunterliegende Host-System erlangen.

Grund ist eine Use-After-Free-Schwachstelle in der Shadow-MMU-Emulation von KVM/x86. Der Fehler steckte rund 16 Jahre unbemerkt im Kernel und betrifft Intel- und AMD-Prozessoren gleichermaßen. ARM64-Hosts sind von Januscape nicht betroffen.

Wichtig für die zeitliche Einordnung: Der Fix war zum Zeitpunkt der öffentlichen Bekanntgabe längst vorhanden. Der Patch (Commit 81ccda30b4e8) wurde am 19. Juni 2026 in den Mainline-Kernel gemergt, die gepatchten Stable-Kernel erschienen am 4. Juli 2026, und erst am 6. Juli folgte nach Ablauf des Embargos die öffentliche Disclosure über die oss-security-Liste. Was in unserer Situation fehlte, waren fertige Distributionspakete für Proxmox.

Damit standen drei Probleme im Raum:

• Ein fertiges, gepatchtes Kernel-Paket seitens Proxmox war zum Zeitpunkt der Meldung noch nicht verfügbar, obwohl der Upstream-Fix bereits existierte.
• Ein Kernel-Update auf Proxmox-Hosts erfordert einen Neustart, dieser musste ohne Downtime für die laufenden VMs erfolgen.
• Als Managed Service Provider mit einer großen Zahl an Proxmox-Hosts für unterschiedliche Kunden zählte in dieser Situation jede Minute.

Was steckt technisch dahinter? Shadow-MMU und Use-After-Free

Die Shadow-MMU bildet die Speicherverwaltung einer virtuellen Maschine in Software nach, statt sie der CPU zu überlassen. Moderne Prozessoren erledigen diese Übersetzung eigentlich in Hardware (Intel EPT, AMD NPT). Sobald ein Gast jedoch selbst als Hypervisor arbeitet, muss KVM die vom Gast verwalteten verschachtelten Seitentabellen wieder in Software schatten. Genau dieser Code-Pfad enthielt Januscape, und deshalb griff die Lücke auch auf Hosts, auf denen EPT beziehungsweise NPT grundsätzlich aktiv sind.

Im Kern liegt eine fehlerhafte Wiederverwendung einer Shadow-Page: KVM identifizierte eine Shadow-Page bislang im Wesentlichen über die Guest Frame Number (GFN), nicht aber vollständig über deren Rolle (role). So konnte eine Shadow-Page mit passender GFN, aber abweichender Rolle wiederverwendet werden, obwohl beide Objekte nicht austauschbar sind. In der Folge blieb eine veraltete Reverse-Mapping-Verknüpfung bestehen, die zugehörige kvm_mmu_page-Struktur wurde freigegeben, und spätere Speicheroperationen griffen auf bereits freigegebenen Speicher zu. Genau dieser Zugriff auf freigegebenen Speicher ist die Use-After-Free im Kern von CVE-2026-53359. Januscape ist dabei nicht der erste Fund in dieser Ecke des Codes: Ein verwandter Fehler wurde bereits im Mai 2026 als CVE-2026-46113 geschlossen (Commit 0cb2af2ea66a). Dieser Fix prüfte allerdings nur, ob KVM die richtige GFN gefunden hatte. Januscape zeigte, dass zusätzlich die Rolle der Shadow-Page geprüft werden muss. Wer im Mai gepatcht hat und das Thema damit für erledigt hält, ist weiterhin angreifbar. Beide Commits gehören zusammen.

Entdeckt wurde die Lücke von Sicherheitsforscher Hyunwoo Kim (@v4bel), der sie über Googles kvmCTF-Programm meldete und ein Proof-of-Concept veröffentlichte. Wichtig zur Einordnung: Der öffentlich verfügbare PoC führt lediglich zu einem Host-Panic (Denial of Service). Einen vollständigen Escape-Exploit hat der Forscher nach eigenen Angaben in einer kontrollierten Umgebung demonstriert, aber nicht veröffentlicht. Das eingangs beschriebene Worst-Case-Szenario ist also technisch belegt, aber nicht Teil des öffentlichen PoC.

Warum Januscape als VM Escape besonders kritisch ist

Bruch der Kernisolation: Guest-to-Host-Escapes zählen zu den schwerwiegendsten Schwachstellenklassen in virtualisierten Umgebungen.

Aus der Gast-VM heraus ausnutzbar, ohne direkten Host-Zugriff: Ein Angreifer benötigt keinen physischen oder administrativen Zugriff auf den Host. Es handelt sich allerdings nicht um eine über das Netzwerk erreichbare Schwachstelle, sondern um einen Eskalationspfad, der von innerhalb einer Gast-VM angesetzt wird. Voraussetzung ist privilegierte Codeausführung innerhalb des Gasts. Der veröffentlichte PoC nutzt dafür Root im Gast und das Laden eines eigenen Kernel-Moduls; das ist der demonstrierte Weg, nicht zwingend die Untergrenze des Angriffs.

Nested Virtualization als praktisch wichtigste Voraussetzung des Gast-Angriffspfads: Der verwundbare Code-Pfad wird immer dann erreicht, wenn KVM Seitentabellen in Software nachbildet. In der Praxis ist dafür fast immer exponierte Nested Virtualization verantwortlich; die Shadow-MMU kommt aber auch dann zum Einsatz, wenn die Hardware-Unterstützung (Intel EPT bzw. AMD NPT) nicht verfügbar oder bewusst deaktiviert ist. Umgebungen mit aktivierter verschachtelter Virtualisierung sind daher besonders stark gefährdet.

Distributionspakete anfangs nicht verfügbar: Als die Lücke publik wurde, war der Upstream-Fix zwar bereits vorhanden, fertige gepatchte Pakete der eingesetzten Distribution standen jedoch noch aus. Bis zu deren Verfügbarkeit blieben ausschließlich Workarounds als Mittel der Wahl.

Betroffenheit prüfen: Welche Proxmox-Hosts sind exponiert?

Aus den technischen Voraussetzungen ergeben sich drei Prüffragen, die jeder Betreiber eines KVM- oder Proxmox-Clusters beantworten sollte:

• Ist Nested Virtualization aktiv und nutzt der Host sonst durchgängig Hardware-Paging? Exponierte Nested-Virtualization-Features sind der praktisch wichtigste Weg in den verwundbaren Shadow-MMU-Pfad. Ein Host ohne Nesting ist jedoch nur dann außen vor, wenn auch EPT bzw. NPT tatsächlich aktiv sind.
• Wie vertrauenswürdig sind die Gäste? Der Angreifer benötigt privilegierte Codeausführung im Gast; der veröffentlichte PoC setzt dafür Root und ein eigenes Kernel-Modul ein. Umgebungen, in denen Kunden oder Dritte eigene VMs mit Root-Rechten betreiben, sind damit deutlich stärker exponiert als Umgebungen mit ausschließlich eigenen, verwalteten Gästen.
• Läuft ein gepatchter Kernel? Der Upstream-Fix war zum Zeitpunkt der Disclosure vorhanden, die Distributionspakete folgten zeitversetzt. Entscheidend ist die tatsächlich laufende Kernel-Version auf dem Host, nicht der Stand des Repositorys.

Diese drei Punkte lassen sich auf jedem Host in wenigen Sekunden prüfen.

Laufende Kernel-Version ermitteln:

uname -r
Nested-Virtualization-Status abfragen (je nach CPU-Hersteller):
cat /sys/module/kvm_intel/parameters/nested
cat /sys/module/kvm_amd/parameters/nested

Ein Y oder 1 bedeutet aktiv, ein N oder 0 inaktiv. Existiert die Datei nicht, ist das entsprechende Modul nicht geladen.

Prüfen, ob beide Fixes im installierten Distributionskernel enthalten sind:

apt changelog "linux-image-$(uname -r)" | grep -iE 'CVE-2026-53359|CVE-2026-46113'

Maßgeblich ist immer die tatsächlich laufende Kernel-Version, nicht der Stand des Repositorys: Ein eingespieltes Paket wirkt erst nach dem Neustart. Upstream sind die Fixes in den Stable-Branches 5.10.260, 5.15.211, 6.1.177, 6.6.144, 6.12.95, 6.18.38 und 7.1.3 sowie ab 7.2-rc1 enthalten (jeweils die erste Version mit dem Backport; spätere Releases derselben Serie enthalten ihn ebenfalls); für Distributionskernel ist der Backport im Changelog zu verifizieren statt anhand der Versionsnummer zu schätzen.

Erste Reaktion: Bestandsaufnahme und Sofortmaßnahmen

Sobald die Meldung über unsere internen Kanäle einging, wurde der Incident-Response-Prozess angestoßen. Die ersten Fragen:

• Welche unserer Proxmox-Hosts nutzen Nested Virtualization und sind damit überhaupt für den Gast-Angriffspfad exponiert?
• Welcher Workaround lässt sich sofort und ohne Risiko für laufende VMs umsetzen?

Da zum Zeitpunkt der Meldung noch keine gepatchten Distributionspakete verfügbar waren, setzte das Team auf mehrere sofort wirksame Maßnahmen: die Deaktivierung von Nested Virtualization auf allen Hosts, bei denen sie nicht zwingend benötigt wurde, die Einschränkung der Ausführung nicht vertrauenswürdiger Gast-VMs auf besonders exponierten Hosts sowie eine verschärfte Überwachung aller Systeme auf verdächtige Aktivitäten.

Alle Proxmox-Nodes wurden dazu automatisiert erfasst und geprüft, statt Host für Host manuell vorzugehen, ein entscheidender Zeitvorteil.

Sonderfall Nutanix AHV: geprüft und eingeordnet

Da auch Nutanix AHV auf KVM/QEMU basiert, stellte sich die Frage nach der Betroffenheit für diese Plattform ebenfalls. Die Prüfung ergab: Nested Virtualization ist auf AHV standardmäßig nicht aktiv. Sie muss explizit pro VM freigeschaltet werden (per cpu_passthrough) und schließt Live-Migration für die betroffene VM aus, weshalb sie im regulären Produktivbetrieb ohnehin kaum eingesetzt wird. Das Advisory nutanix-sa-0051 zählt als exponierende Konfigurationen Hardware-Virtualisierung, CPU-Passthrough, Credential Guard beziehungsweise Virtualization-based Security, WSL2 sowie gleichwertige Funktionen auf, die dem Gast die VT-x- und AMD-V-Erweiterungen offenlegen. Eine Bestandsaufnahme sollte sich deshalb nicht auf ein einzelnes Merkmal verlassen, sondern alle in dieser Liste genannten Fälle abdecken. Prüfen lässt sich der Zustand nicht in Prism, sondern nur auf aCLI- beziehungsweise API-Ebene: acli vm.get "*" gibt die Vollkonfiguration aller VMs aus, in der das Flag nur bei den betroffenen Maschinen auftaucht; für ein wiederholbares Inventar ist die VM-API der sauberere Weg. Wichtig ist die Lesart des Ergebnisses: Findet sich keine Treffermenge, ist der bekannte Expositionspfad zum Prüfzeitpunkt nicht belegt. Eine Entwarnung ist das nicht, denn Nutanix selbst nennt für AHV keinen unterstützten Workaround, und ein leeres Ergebnis kann auch an Syntax, AOS-Version oder Berechtigungen liegen.

In unserer AHV-Umgebung war Nested Virtualization dementsprechend nicht aktiviert, sodass der bekannte Gast-Angriffspfad von Januscape dort nicht exponiert war.

Um sicherzugehen, haben wir uns nicht allein auf diese Einschätzung verlassen, sondern den öffentlich verfügbaren PoC-Exploit zusätzlich in einer kontrollierten Testumgebung ausgeführt. Das Ergebnis bestätigte die Analyse: Ohne aktivierte Nested Virtualization griff der Exploit auf AHV nicht. Damit war die Einschätzung nicht nur theoretisch begründet, sondern praktisch belegt. Zwei Einschränkungen gehören zur Ehrlichkeit dazu: Der öffentliche PoC deckt nur den DoS-Pfad ab, ein nicht ausgelöster Crash ist also kein Beweis für Unangreifbarkeit. Und nicht exponiert heißt nicht gepatcht: Nutanix stuft AHV im Advisory nutanix-sa-0051 vom 10. Juli 2026 als betroffen ein, bewertet die Lücke mit CVSS 7.8 und nennt ausdrücklich keinen unterstützten Workaround. Für Standard-VMs ohne exponierte Virtualisierungserweiterungen erwartet Nutanix keine Exposition; die wirksame Abhilfe für betroffene VMs ist allein das Upgrade auf die Release mit dem Fix, der zum Redaktionsschluss noch angekündigt war.

Proxmox-Cluster ohne Downtime patchen: Live-Migration und HA-Design

Wie konnte der Security-Incident behoben werden? Nachdem gepatchte Kernel-Pakete verfügbar wurden, hat Claranet sämtliche Proxmox-Cluster Node für Node gepatcht:

• VMs wurden vor jedem Neustart automatisiert auf andere Nodes im Cluster migriert.
• Der freigeräumte Node wurde aktualisiert und neu gestartet.
• Anschließend wurde er wieder in den Cluster aufgenommen.

Dank des bestehenden HA-Designs kam es dabei weder bei den VM-Migrationen noch bei den Node-Neustarts zu einer Downtime. Während des gesamten Prozesses gab es keine ungeplanten Ausfälle und keine Sicherheitsvorfälle.

Das ist der praktische Unterschied zwischen einem Cluster, in dem Live-Migration und High Availability vorbereitet sind, und einer Umgebung, in der ein Kernel-Update ein angekündigtes Wartungsfenster erfordert.

Was dieser Vorfall über Patch Management bei einem Managed Service Provider aussagt

Zwei Fragen stellen IT-Verantwortliche regelmäßig, wenn es um den Betrieb virtualisierter Umgebungen geht: Welche Ausfallzeiten sind zu erwarten? Und gibt es qualifizierte Dienstleister, die das übernehmen? Dieser Vorfall beantwortet beide an einem konkreten Fall.

• Reaktionsfähigkeit rund um die Uhr: Die Meldung wurde umgehend bearbeitet, ein Incident-Prozess aufgesetzt und erste Sofortmaßnahmen eingeleitet, noch bevor gepatchte Pakete für unsere Umgebung bereitstanden.
• Zentrales Inventar und Automatisierung: Statt jeden Host einzeln zu prüfen, ermöglichte die zentrale Verwaltung eine schnelle, konsistente und dokumentierte Umsetzung über die gesamte Flotte hinweg.
• Risikobasierte Priorisierung statt Schnellschuss: Durch die gezielte Einschätzung, welche Hosts durch Nested Virtualization überhaupt exponiert waren, konnte das Team Ressourcen dort einsetzen, wo sie den größten Effekt hatten.
• Kunden mussten nichts tun: Migration, Patch-Rollout und Verifikation liefen vollständig im Hintergrund. Das Ergebnis einer vorbereiteten, toolgestützten Betriebsorganisation.

Ausblick: Virtualisierungs-Lücken bleiben ein wachsendes Risiko

Januscape reiht sich in eine Serie kritischer Schwachstellen ein, die zeigen, dass auch die fundamentalen Isolationsmechanismen der Virtualisierung nicht unangreifbar sind. Wer nicht über automatisierte Inventarisierung, Live-Migrationsfähigkeit und vorbereitete Patch-Pipelines verfügt, wird im Ernstfall zwangsläufig reaktiv statt proaktiv handeln.

Das gilt besonders für Unternehmen, die aktuell von VMware auf Proxmox oder Nutanix wechseln. Wer eine Virtualisierungsplattform migriert, verlagert damit auch die Verantwortung für deren Patch-Zyklen.

Fazit

„Januscape“ ist eine ernste Bedrohung für jede Umgebung, die auf KVM/x86 mit exponierter Nested Virtualization setzt. Für unsere Proxmox-Kunden ist die Sache abgeschlossen: Wir haben die Lücke frühzeitig eingeschätzt, Sofortmaßnahmen ergriffen und alle Nodes koordiniert und ohne Kundenaktion gepatcht. Für Nutanix AHV bleibt sie offen, solange Nutanix die Release mit dem Fix nicht ausgeliefert hat. Wer AHV betreibt, sollte das Advisory nutanix-sa-0051 weiter beobachten und die betroffenen VMs bis dahin im Blick behalten.

Virtualisierung im Managed Service betreiben

Januscape hat gezeigt, worauf es im Ernstfall ankommt: ein aktuelles Inventar, vorbereitete Live-Migration und ein Team, das rund um die Uhr reagiert. Wenn Sie Ihre Proxmox-, KVM- oder Nutanix-Umgebung nicht selbst rund um die Uhr überwachen und patchen möchten, sprechen wir gern über Ihre Anforderungen.

Beratung anfragen

FAQ zu Januscape, KVM, Proxmox und Nutanix AHV

Was ist Januscape (CVE-2026-53359)?

Januscape ist eine Use-After-Free-Schwachstelle in der Shadow-MMU-Emulation von KVM/x86. Sie ermöglicht einen Guest-to-Host-Escape, also den Ausbruch aus einer virtuellen Maschine auf das Host-System. Betroffen sind Intel- und AMD-Prozessoren gleichermaßen, ARM64-Hosts nicht.

Ist Januscape über das Netzwerk ausnutzbar?

Nein. Es handelt sich nicht um eine remote über das Netzwerk erreichbare Lücke. Der Angreifer muss Code innerhalb einer Gast-VM ausführen können, und zwar mit privilegierten Rechten – der veröffentlichte PoC nutzt dafür Root im Gast und ein eigenes Kernel-Modul –, um den Eskalationspfad zum Host anzusetzen.

Wen betrifft die Lücke besonders?

Betreiber von KVM/x86-Hosts mit aktivierter Nested Virtualization sowie Multi-Tenant-Cloud- und Hosting-Umgebungen, in denen mehrere Kunden-VMs denselben Host teilen. Zusätzlich relevant sind Systeme, auf denen /dev/kvm für alle lokalen Benutzer zugänglich ist – in der RHEL-Familie ist das verbreitet. Dort lässt sich derselbe Fehler als lokale Privilegieneskalation bis root missbrauchen.

Ist mein Proxmox-Cluster betroffen?

Entscheidend sind drei Punkte: die tatsächlich laufende Kernel-Version auf dem Host, die Frage, ob Nested Virtualization aktiv ist, und das Vertrauensniveau der Gäste. Umgebungen, in denen Dritte eigene VMs mit Root-Rechten betreiben, sind deutlich stärker exponiert.

Ist Nutanix AHV von Januscape betroffen?

AHV basiert auf KVM/QEMU, Nested Virtualization ist dort jedoch standardmäßig nicht aktiv und muss pro VM explizit freigeschaltet werden. Damit ist der Gast-Angriffspfad in Standardkonfigurationen nicht exponiert. In unserer AHV-Umgebung haben wir das zusätzlich durch Ausführung des öffentlichen PoC in einer kontrollierten Testumgebung verifiziert. Fehlende Exposition ersetzt jedoch keinen Patch: Nutanix stuft AHV im Advisory nutanix-sa-0051 als betroffen ein und nennt keinen unterstützten Workaround; der AHV-Fix war zum Redaktionsschluss angekündigt, aber noch nicht ausgeliefert. Zu beachten ist außerdem, dass nicht nur cpu_passthrough exponiert, sondern auch Credential Guard, VBS oder WSL2 innerhalb einer Gast-VM.

Was ist der schnellste Workaround gegen Januscape?

Solange keine gepatchten Pakete eingespielt sind, reduziert die Deaktivierung von Nested Virtualization sowie die Einschränkung nicht vertrauenswürdiger Gast-VMs auf betroffenen Hosts das Risiko spürbar. Auf Systemen, die gar keine VMs betreiben, lassen sich die KVM-Module zusätzlich entladen und blockieren. Hosts, die Nested Virtualization zwingend benötigen, lassen sich per Konfiguration allein nicht absichern; dort hilft nur der Patch.

Ersetzt der Workaround das Patchen?

Nein. Der Workaround senkt das Risiko sofort, ersetzt aber keinen Kernel-Fix. Sobald gepatchte Pakete verfügbar sind, sollte ein geplantes Update-Fenster folgen. Zu prüfen sind dabei beide zugehörigen Fixes (CVE-2026-53359 und CVE-2026-46113).

Lässt sich ein Proxmox-Cluster ohne Downtime patchen?

Ja, sofern Live-Migration und ein HA-Design vorbereitet sind. Die VMs werden vor dem Neustart auf andere Nodes migriert, der freigeräumte Node wird aktualisiert und danach wieder in den Cluster aufgenommen. In unserem Fall traten dabei weder bei den Migrationen noch bei den Node-Neustarts Ausfallzeiten auf.