Virtuelle Maschinen gelten als voneinander getrennte Arbeitsbereiche. Selbst wenn eine einzelne VM kompromittiert wird, soll der darunterliegende Server geschützt bleiben. Genau diese Sicherheitsgrenze stellt die Linux-Kernel-Schwachstelle CVE-2026-53359, besser bekannt als Januscape, infrage.
Die Schwachstelle wurde am 6. Juli 2026 öffentlich bekannt. Canonical veröffentlichte am 11. Juli eine ausführliche Einordnung und bewertete das Risiko mit einem eigenen CVSS-4-Wert von 8,4. Betroffen ist die KVM-Virtualisierung auf Intel- und AMD-Systemen mit x86-64-Prozessoren, sofern verschachtelte Virtualisierung genutzt werden kann. Andere Prozessorarchitekturen fallen nach der derzeitigen Bewertung nicht unter diesen konkreten Angriffsweg.
Was Januscape so gefährlich macht
Der Angriff beginnt innerhalb einer virtuellen Maschine, kann aber den Kernel des eigentlichen Virtualisierungshosts treffen. Damit wird aus einem Problem innerhalb eines Gastsystems möglicherweise ein Problem für den gesamten Server.
Januscape steckt nicht in einer Verwaltungsoberfläche oder einer einzelnen Virtualisierungssoftware. Die Ursache liegt direkt im KVM-Code des Linux-Kernels. KVM steht für „Kernel-based Virtual Machine“ und bildet die technische Grundlage zahlreicher Linux-Virtualisierungslösungen.
Der Fehler betrifft die Verwaltung sogenannter Shadow Page Tables. Diese Tabellen helfen KVM dabei, Speicherbereiche zwischen virtuellen Maschinen und dem physischen Host korrekt zuzuordnen. Durch eine fehlerhafte Wiederverwendung interner Speicherstrukturen kann ein bereits freigegebener Speicherbereich später erneut angesprochen werden. Solche Fehler werden als Use-after-free bezeichnet.
Der veröffentlichte Machbarkeitsnachweis zeigt, dass eine entsprechend vorbereitete virtuelle Maschine den Kernel des Hosts zum Absturz bringen kann. Der Sicherheitsforscher Hyunwoo Kim beschreibt darüber hinaus, dass ein vollständiger Gast-zu-Host-Ausbruch in einer kontrollierten Umgebung gelungen sei. Der dafür verwendete Exploit wurde jedoch nicht veröffentlicht. Öffentlich verfügbar ist bislang nur der Nachweis für den Absturz des Hosts.
Damit muss zwischen zwei bestätigten beziehungsweise möglichen Auswirkungen unterschieden werden. Der Absturz eines Virtualisierungshosts wurde praktisch demonstriert. Eine vollständige Übernahme des Hosts gilt nach Angaben des Forschers als möglich, kann anhand des nicht veröffentlichten Codes aber nicht unabhängig nachvollzogen werden.
Für Unternehmen reicht bereits der bestätigte Absturz als ernstes Risiko aus. Fällt ein Virtualisierungshost aus, können gleichzeitig Dateiserver, Warenwirtschaft, Datenbanken, Telefonanlagen, Remote-Desktop-Systeme und weitere virtuelle Server nicht mehr erreichbar sein.
Warum verschachtelte Virtualisierung entscheidend ist
Nicht jede KVM-Installation ist automatisch über Januscape angreifbar. Der konkrete Angriffsweg setzt voraus, dass eine virtuelle Maschine selbst wieder Virtualisierung verwenden kann.
Bei gewöhnlicher Virtualisierung läuft ein Linux-Server direkt auf der Hardware. Auf diesem Host werden anschließend virtuelle Maschinen betrieben. Bei der verschachtelten oder „Nested Virtualization“ darf eine dieser virtuellen Maschinen wiederum selbst als Hypervisor arbeiten und weitere virtuelle Maschinen starten.
Ein typischer Aufbau sieht dann so aus:
Physischer Server → Linux-Hypervisor → virtuelle Maschine → weitere virtuelle Maschine.
Solche Konstruktionen werden beispielsweise in Softwarelaboren, Schulungsumgebungen, Test-Clustern, automatisierten Entwicklungsumgebungen und virtuellen Rechenzentren eingesetzt. Auch ein Proxmox-Testcluster, der innerhalb einer Proxmox-VM betrieben wird, benötigt in der Regel verschachtelte Virtualisierung.
Gerade bei dieser zweiten Virtualisierungsebene muss KVM bestimmte Seitentabellen wieder in Software nachbilden. In diesem Bereich liegt der Januscape-Fehler. Die Aktionen innerhalb der VM werden dabei direkt vom KVM-Code im Kernel des Hosts verarbeitet. Nach Angaben des Forschers handelt es sich deshalb um einen reinen KVM-Kernel-Fehler und nicht um eine Schwachstelle in QEMU.
Ist Nested Virtualization auf dem Host abgeschaltet und kann sie auch später nicht durch einen berechtigten Dienst oder Benutzer aktiviert werden, ist dieser konkrete Angriffsweg blockiert.
Ein Angriff ist nicht ohne Vorbereitung möglich
Januscape ist keine Schwachstelle, die ein beliebiger Webseitenbesucher direkt ausnutzen kann. Ein Angreifer benötigt weitreichende Kontrolle über eine virtuelle Maschine und Zugriff auf die für Nested Virtualization notwendigen Funktionen.
Canonical beschreibt die Angriffsfläche bei selbst betriebenen Hypervisoren als einen Angriff aus einer Gast-VM heraus, in der der Angreifer über Root-Rechte verfügt. Ein Prozess oder Benutzer innerhalb der VM muss in der Lage sein, einen eigenen Kernel bereitzustellen oder Kernelmodule zu laden und anschließend eine weitere virtuelle Maschine zu starten.
Das begrenzt das Risiko, beseitigt es aber nicht. Ein Angreifer könnte diese Rechte beispielsweise erhalten, nachdem er zuvor eine öffentlich erreichbare VM kompromittiert hat. Auch Entwickler, Kunden oder Schulungsteilnehmer können in bestimmten Umgebungen absichtlich administrative Rechte innerhalb ihrer eigenen virtuellen Maschinen besitzen.
Besonders relevant ist Januscape deshalb für Hostinganbieter und Plattformen, auf denen nicht vollständig vertrauenswürdige Benutzer eigene Systeme verwalten dürfen. In einer kleinen Firma mit wenigen internen VMs ist die Wahrscheinlichkeit eines Angriffs geringer. Die möglichen Folgen eines erfolgreichen Angriffs bleiben dennoch erheblich.
Auch Hosts ohne laufende virtuelle Maschinen sollten geprüft werden
Ein Linux-System ist nicht automatisch sicher, nur weil dort momentan keine VM aktiv ist. Dienste wie libvirt, LXD, Incus oder Multipass können Benutzern unter Umständen erlauben, später eine KVM-beschleunigte virtuelle Maschine zu starten.
Canonical empfiehlt deshalb zusätzlich zu prüfen, wer auf das Gerät /dev/kvm zugreifen darf. Unter Ubuntu ist dieser Zugriff normalerweise auf den Benutzer root und Mitglieder der Gruppe kvm beschränkt. Administratoren sollten dennoch kontrollieren, ob Benutzerkonten, Dienste oder privilegierte Container unnötig entsprechende Rechte erhalten haben.
Unprivilegierte Container gelten nach der Canonical-Einordnung nicht als ausreichender Angriffsweg, weil sie normalerweise keine KVM-beschleunigten virtuellen Maschinen starten dürfen. Privilegierte Container müssen dagegen deutlich vorsichtiger betrachtet werden.
So lässt sich Nested Virtualization unter Linux prüfen
Canonical nennt folgenden Befehl, um den aktuellen Zustand der KVM-Module zu kontrollieren:
grep . /sys/module/kvm_{amd,intel}/parameters/nested
Je nach Prozessor und geladenem Modul erscheint dabei möglicherweise für einen der beiden Pfade eine Fehlermeldung. Das ist normal, weil ein System üblicherweise entweder das Intel- oder das AMD-KVM-Modul verwendet.
Ein Ergebnis wie 1 oder Y bedeutet, dass verschachtelte Virtualisierung auf Modulebene aktiviert ist. 0 oder N zeigt an, dass sie deaktiviert wurde. Canonical weist allerdings darauf hin, dass zwei fehlende Dateien allein keine sichere Entwarnung darstellen. Ein momentan nicht geladenes KVM-Modul könnte später noch mit aktivierter Nested Virtualization geladen werden.
Zusätzlich sollte geprüft werden, ob Konfigurationsdateien die Funktion ausdrücklich aktivieren:
grep -R "nested" /etc/modprobe.d/
Bei produktiven Systemen sollte nicht nur der aktuelle Zustand dokumentiert werden. Wichtig ist auch, welche virtuellen Maschinen die Prozessorfunktionen vmx bei Intel beziehungsweise svm bei AMD tatsächlich erhalten.
Ubuntu-Systeme: Der Host-Kernel muss aktualisiert werden
Ein Kernel-Update innerhalb der virtuellen Maschine schließt die Schwachstelle nicht. Aktualisiert werden muss der Kernel des physischen Hypervisors.
Der Fehler befindet sich in dem Kernel, der die virtuelle Maschine ausführt. Wird lediglich das Gastbetriebssystem aktualisiert, bleibt der darunterliegende Host weiterhin verwundbar.
Canonical führte auf seiner zuletzt am 9. Juli aktualisierten CVE-Seite die untersuchten Ubuntu-Kernel weiterhin als verwundbar. Im Blogbeitrag vom 11. Juli wurden Kernelpakete mit dem vorgeschlagenen Patch angekündigt, standen zu diesem Zeitpunkt jedoch noch aus. Bis zur Veröffentlichung passender Updates empfahl Canonical, Nested Virtualization bei nicht benötigter Nutzung abzuschalten.
Administratoren sollten deshalb nicht anhand einer allgemeinen Meldung davon ausgehen, dass ihr System bereits geschützt ist. Entscheidend ist der Paketstatus für die konkret verwendete Ubuntu-Version und den tatsächlich installierten Kernel.
Nach der Installation eines neuen Kernels muss der Hypervisor üblicherweise neu gestartet werden, damit nicht weiterhin der verwundbare alte Kernel im Arbeitsspeicher aktiv bleibt. Vor einem Neustart sollten laufende VMs geordnet heruntergefahren oder auf einen bereits aktualisierten Clusterknoten verschoben werden.
Proxmox hat korrigierte Kernel veröffentlicht
Für aktuell unterstützte Proxmox-Systeme stehen inzwischen Kernelpakete mit dem Januscape-Fix bereit. Proxmox-Nutzer sollten deshalb nicht mehr nur auf die vorläufige Abschaltung von Nested Virtualization setzen.
Proxmox bestätigte die Schwachstelle kurz nach der öffentlichen Bekanntgabe. Zunächst wurden korrigierte Kernel über das Test-Repository bereitgestellt. Genannt wurden unter anderem proxmox-kernel-6.8.12-33-pve und proxmox-kernel-7.0.14-4-pve. Wenige Stunden später meldete ein Proxmox-Mitarbeiter die Verfügbarkeit im Repository pve-no-subscription. Am folgenden Tag waren die Kernel nach offizieller Aussage auch im Enterprise-Repository verfügbar.
Damit ist die frühere Aussage, es gebe noch keine Proxmox-Einordnung, inzwischen überholt.
Proxmox-Administratoren sollten ihre Paketquellen aktualisieren, die angebotenen Kernel-Updates installieren und den Host anschließend kontrolliert neu starten. Danach lässt sich mit folgendem Befehl prüfen, welcher Kernel tatsächlich läuft:
uname -r
Es genügt nicht, das neue Paket lediglich herunterzuladen. Solange der Host noch mit dem vorherigen Kernel läuft, bleibt der alte verwundbare Code aktiv.
Ältere und nicht mehr unterstützte Proxmox-Versionen stellen ein zusätzliches Risiko dar. Ein Proxmox-Mitarbeiter wies im Zusammenhang mit Januscape ausdrücklich darauf hin, dass Proxmox VE 7 bereits außerhalb des Supports liegt und unabhängig von dieser einzelnen Schwachstelle nicht mehr für nicht vertrauenswürdige Arbeitslasten eingesetzt werden sollte.
Nested Virtualization nicht vorschnell abschalten
Das Abschalten von Nested Virtualization ist eine wirksame Übergangslösung, kann aber Testsysteme, virtuelle Cluster und Schulungsumgebungen außer Betrieb setzen.
Canonical beschreibt für Intel- und AMD-Systeme eine Konfiguration über die KVM-Moduloptionen:
options kvm_intel nested=0
options kvm_amd nested=0
Diese Einstellungen können beispielsweise in einer Datei unter /etc/modprobe.d/ hinterlegt werden. Je nach Distribution und vorhandener Konfiguration können die genaue Schreibweise und der notwendige Neustart abweichen. Canonical zeigt zusätzlich das Entladen und erneute Laden der KVM-Module, warnt aber zugleich vor möglichen Auswirkungen auf legitime Virtualisierungsaufgaben.
Bei Proxmox-Clustern ist außerdem Vorsicht geboten, wenn einzelne Knoten unterschiedliche CPU-Funktionen bereitstellen. Im Proxmox-Forum wurde berichtet, dass Live-Migrationen zwischen Hosts mit aktivierter und deaktivierter Nested Virtualization problematisch sein können, insbesondere wenn VMs das CPU-Modell host verwenden. Der Grund ist, dass sich die der VM präsentierten Prozessorfunktionen während einer laufenden Migration nicht beliebig ändern lassen.
Die sichere Reihenfolge lautet deshalb nicht: Funktion abschalten und anschließend beobachten, was ausfällt. Zuerst muss geklärt werden, welche Systeme die Funktion tatsächlich benötigen. Danach kann entschieden werden, ob ein sofortiges Kernel-Update, eine vorübergehende Abschaltung oder eine geplante Wartung die geeignetste Maßnahme ist.
Was kleine Unternehmen jetzt tun sollten
Januscape erfordert keine Panik, aber eine nachvollziehbare Bestandsaufnahme. Wer seinen Hypervisor regelmäßig aktualisiert und Nested Virtualization nicht unkontrolliert an Gast-VMs weitergibt, kann das Risiko deutlich begrenzen.
Unternehmen sollten zunächst feststellen, welche Linux- und Proxmox-Hosts überhaupt KVM verwenden. Danach muss geprüft werden, ob Nested Virtualization auf dem Host aktiviert ist und welche virtuellen Maschinen die notwendigen CPU-Erweiterungen erhalten.
Ebenso wichtig ist die Frage, wer administrative Rechte innerhalb dieser VMs besitzt. Eine interne Server-VM, auf die ausschließlich ein Administrator zugreifen kann, ist anders zu bewerten als eine Entwicklungsplattform, auf der mehrere Benutzer eigene Kernel, Module oder Test-Hypervisoren starten dürfen.
Für Proxmox-Systeme stehen aktualisierte Kernel bereit. Diese sollten über das regulär verwendete Repository installiert werden. Bei Ubuntu-basierten Hypervisoren muss der aktuelle Status des verwendeten Kernelpakets kontrolliert werden. Steht noch kein korrigierter Kernel bereit und wird Nested Virtualization nicht benötigt, ist die vorübergehende Deaktivierung die naheliegende Schutzmaßnahme.
Administratoren sollten den veröffentlichten Machbarkeitsnachweis keinesfalls auf einem produktiven Server ausprobieren. Der bestätigte Zweck des Codes besteht darin, den Host-Kernel zum Absturz zu bringen. Ein erfolgreicher Test wäre damit gleichzeitig ein absichtlich herbeigeführter Ausfall des Virtualisierungssystems.
Januscape zeigt die Bedeutung der Host-Sicherheit
Virtuelle Maschinen sind ein wichtiger Baustein moderner IT-Infrastrukturen. Sie vereinfachen Backups, Tests, Migrationen und die Trennung verschiedener Anwendungen. Trotzdem bildet der Hypervisor eine gemeinsame technische Grundlage. Eine Schwachstelle an dieser Stelle kann mehrere eigentlich getrennte Systeme gleichzeitig gefährden.
Januscape bedeutet nicht, dass KVM oder Proxmox grundsätzlich unsicher wären. Die schnelle Bereitstellung korrigierter Kernel zeigt vielmehr, wie ein funktionierender Open-Source-Sicherheitsprozess aussehen kann: Der Fehler wird untersucht, ein Patch wird öffentlich entwickelt und Distributoren können aktualisierte Pakete ausliefern.
Für kleine Unternehmen bleibt daraus eine einfache, aber wichtige Erkenntnis: Nicht nur die virtuellen Server müssen gepflegt werden. Der Hypervisor darunter ist das Fundament der gesamten Umgebung und benötigt eigene Updates, kontrollierte Zugriffsrechte und geplante Wartungsfenster.
Wer lediglich die Gast-VMs aktualisiert, schützt Anwendungen und Betriebssysteme innerhalb dieser Maschinen. Wer den Hypervisor vergisst, lässt möglicherweise genau die Ebene ungepatcht, von der alle anderen Systeme abhängen.
Artikelstand: 13. Juli 2026. Bei Kernel-Schwachstellen können sich Paketstatus und Herstellerempfehlungen kurzfristig ändern.
Mehr aus dieser Kategorie
Dieses Bild ist AI generated. 
Dieses Bild ist AI generated. 
Dieses Bild ist AI generated. 
Dieses Bild ist AI generated. 
Dieses Bild ist AI generated.