Security 06.07.2026, 23:40 Aktualisiert: 07.07.2026, 05:57

Januscape CVE-2026-53359: Wenn die VM den KVM-Host übernimmt

Januscape trifft x86-KVM mit Nested Virtualization. Patchstände für Debian, Ubuntu, RHEL, Proxmox und Co. plus Mitigation.

Von Moritz Mantel · Veröffentlicht: 06.07.2026, 23:40 · Aktualisiert: 07.07.2026, 05:57

Stand: 07.07.2026, 05:57 Uhr CEST. Januscape ist gerade erst öffentlich geworden. Upstream ist gefixt, viele Distributionen, Kernel-Flavours und Hypervisor-Appliances sind aber noch in Bewegung. Systeme ohne konkret belegten Vendor-Fix oder Changelog-Eintrag für CVE-2026-53359 beziehungsweise den Fix-Commit 81ccda30b4e8 sollten nicht als gepatcht gelten.

Kurzfassung

CVE-2026-53359, Januscape: ein Use-after-free im x86-KVM-Code des Linux-Kernels. Betroffen ist die Shadow-MMU bei Nested Virtualization.
Auswirkung: Ein Angreifer mit Root-Rechten in einer Gast-VM kann den KVM-Host über den öffentlichen PoC zuverlässig zum Kernel-Panic bringen. Der Researcher gibt an, zusätzlich einen nicht veröffentlichten Full-Escape zu haben, der Code als Root auf dem Host ausführen kann.
Wichtig für Hoster: Der Angriff ist nicht einfach „irgendein lokaler Linux-Bug“. Er trifft genau die Grenze, auf die VPS-, Cloud- und Proxmox-Setups angewiesen sind: Gast gegen Host.
Voraussetzung: x86-KVM auf Intel oder AMD, ein verwundbarer Host-Kernel und Nested Virtualization, die an den Gast durchgereicht wird. Root im Gast ist für viele Cloud- und VPS-Szenarien keine echte Hürde, weil Kunden in ihrer VM normalerweise Root sind.
Nicht der Kernpunkt: QEMU ist hier nicht der Bug. Die Schwachstelle sitzt im Kernel-KVM-Code. Auch ein QEMU-Update allein macht den Host nicht sicher.
Sofortmaßnahme: Host-Kernel patchen. Wo noch kein Fix verfügbar ist: Nested Virtualization für untrusted Guests deaktivieren.
Proxmox: Zum geprüften Stand finde ich keinen öffentlichen Proxmox-PSA und keinen Proxmox-Kernel-Changelog mit Januscape, CVE-2026-53359 oder dem Fix-Commit. Proxmox-Hosts mit untrusted VMs und aktivem Nested KVM sollten deshalb priorisiert behandelt werden.
Andere KVM-Hypervisor: Nutanix AHV, Sangfor aSV/HCI, Scale HyperCore, Harvester/SUSE Virtualization, OpenShift Virtualization, OpenStack, OpenNebula, CloudStack, oVirt/RHV und OLVM müssen über ihren tatsächlichen Host-Kernel und ihre Nested-Virtualization-Policy bewertet werden.

Januscape-Demo: Der öffentliche PoC löst aus einer Gast-VM einen Host-Kernel-Panic aus

Das GIF zeigt den öffentlichen Januscape-DoS-PoC. Der behauptete Full-Escape ist nach aktuellem Stand nicht veröffentlicht.

Was ist Januscape?

Januscape ist eine KVM-Escape-Schwachstelle im Linux-Kernel. Der Name ist drastisch, aber hier passt er: Wenn die Voraussetzungen stimmen, greift nicht ein Prozess im Host an, sondern eine VM selbst. Genau diese Grenze soll KVM eigentlich hart trennen.

Der Bug steckt im x86-KVM-Code für Shadow Paging. Dieser Codepfad wird vor allem bei Nested Virtualization relevant. In so einem Setup läuft auf dem echten Host, oft als L0 bezeichnet, eine VM. Diese VM ist dann L1 und startet wiederum eine weitere VM, also L2. Damit das funktioniert, muss der echte Host Teile der zweiten Virtualisierungsschicht nachbilden.

Das ist legitim und in der Praxis sehr nützlich. CI-Systeme, Schulungsumgebungen, Android-Emulatoren, Kubernetes-Labs, Security-Labs und manche Kunden-VMs brauchen Nested Virtualization. Für Hoster ist es aber genau deshalb gefährlich: Wer Kunden erlaubt, in ihrer VM wieder eigene VMs zu starten, vergrößert die Angriffsfläche direkt in Richtung Host-Kernel.

Wie die Lücke funktioniert

Moderne x86-CPUs haben Hardware-Unterstützung für Speicherübersetzung in VMs: EPT bei Intel, NPT bei AMD. Für normale VMs kann KVM oft die TDP-MMU verwenden. Bei verschachtelter Virtualisierung wird es komplizierter, weil der echte Host die zweite Übersetzungsebene des Gast-Hypervisors berücksichtigen muss. Dafür fällt KVM in relevante Shadow-MMU-Pfade zurück.

Der Januscape-Bug liegt in der Wiederverwendung interner KVM-MMU-Seiten. Vereinfacht gesagt entscheidet KVM an einer Stelle, ob eine vorhandene Shadow Page wiederverwendet werden darf. Vor dem Fix wurde dabei im kritischen Pfad nur die Guest Frame Number geprüft, aber nicht die vollständige Rolle dieser Page.

Genau das ist das Problem. Eine Shadow Page für eine direkte große Zuordnung und eine Shadow Page für eine indirekte Gast-Page-Table können dieselbe GFN haben, aber eine andere Rolle. Wenn KVM diese beiden Fälle verwechselt, passen die internen Reverse-Mapping- und Lebensdauerannahmen nicht mehr zusammen. Daraus wird ein Use-after-free im Host-Kernel.

Der öffentliche Proof of Concept nutzt diese Verwechslung, um den Host in einen Kernel-Panic zu treiben. Das ist bereits schlimm genug, weil eine einzelne VM damit den ganzen KVM-Node abschießen kann. Laut Researcher ist die primitive aber nicht nur ein Crash: Mit zusätzlicher Arbeit lässt sie sich zu kontrollierter Codeausführung auf dem Host ausbauen. Dieser Full-Escape-Code ist nicht öffentlich, aber die technische Richtung ist plausibel genug, um das nicht als reine Theorie abzutun.

Wann ein System angreifbar ist

Voraussetzung	Einschätzung
x86-KVM-Host auf Intel oder AMD	Relevant. Januscape betrifft KVM/x86, nicht nur einen einzelnen CPU-Hersteller.
Verwundbarer Host-Kernel	Entscheidend. Die Kernel-Version der Gast-VM ist nicht der primäre Schutz.
Nested Virtualization im Gast	Der zentrale Angriffspfad. Ohne durchgereichtes `vmx` oder `svm` sinkt das praktische Risiko deutlich.
Root im Gast	Für den öffentlichen PoC nötig. Bei gemieteten VMs ist das in der Regel normal.
Untrusted Kunden-VMs	Hohe Priorität. Hier ist Root im Gast kein Sicherheitsanker, sondern Teil des Geschäftsmodells.
Nur LXC/Container ohne KVM-Gast	Januscape ist kein Container-Escape. Trotzdem können auf denselben Hosts andere Kernel-LPEs relevant sein.
arm64-KVM	Januscape selbst betrifft nach Researcher-Angaben nicht arm64. Für arm64 gibt es mit ITScape eine eigene KVM-Schwachstelle.
QEMU-Version	Nicht der Fixpunkt. QEMU kann den verwundbaren Kernel-Code auslösen, die Lücke sitzt aber in KVM.

Zusätzlich sollte man auf KVM-Hosts die Rechte von /dev/kvm prüfen. Der Januscape-Researcher weist darauf hin, dass world-writable /dev/kvm auf RHEL-artigen Systemen den Bug auch in Richtung lokaler Host-Privilege-Escalation interessant macht. Das ersetzt nicht die Guest-to-Host-Betrachtung, ist aber ein zweiter Blick wert.

Patchstände nach Distribution und Plattform

Diese Tabelle ist eine Momentaufnahme. Bei Kernel-CVEs mit gerade gebrochenem Embargo ändern sich Vendor-Stände oft innerhalb von Stunden.

Plattform	Stand am 07.07.2026, 05:57 Uhr CEST
Upstream Linux stable	Gefixt in `7.1.3`, `6.18.38`, `6.12.95`, `6.6.144`, `6.1.177`, `5.15.211` und `5.10.260`. Der Mainline-Fix ist `81ccda30b4e8`.
Debian	`trixie-security` ist mit `linux 6.12.95-1` gefixt, `sid` mit `7.1.3-1`. `bullseye`, `bookworm`, die jeweiligen Security-Stände `5.10.259-1` und `6.1.176-1`, `trixie` ohne Security-Fix und `forky` stehen im Debian Tracker noch als vulnerable.
Ubuntu	Canonical führt CVE-2026-53359 mit Priorität Medium. Für die geprüften Standard- und Cloud-/HWE-/KVM-Flavours stand überwiegend `Needs evaluation`; ein konkreter Fixed-Package-Stand war nicht sichtbar. Exakten Kernel-Flavour prüfen.
Red Hat Enterprise Linux	Red Hat bewertet die Lücke als Important. RHEL 8, 9 und 10 Kernel sowie RHEL 8/9 kernel-rt sind als affected gelistet. RHEL 6 und 7 stehen als not affected. Im Security-Data-Feed war noch kein Advisory mit Fix-Paket sichtbar.
AlmaLinux	In den öffentlichen `errata.full.json`-Daten für AlmaLinux 8, 9 und 10 fand ich keinen Advisory-Eintrag zu CVE-2026-53359. Wegen des RHEL-Status sollten entsprechende Hosts nicht als gefixt gelten, bis ein Alma-Erratum oder Paket-Changelog den Backport belegt.
Rocky Linux	Die offizielle Rocky-Errata-API lieferte für `CVE-2026-53359` und `Januscape` `total: 0`. Auch hier gilt: erst als gefixt behandeln, wenn ein Rocky-Advisory oder Kernel-Changelog den Fix zeigt.
CloudLinux / KernelCare	Zum geprüften Stand fand ich keinen öffentlichen Januscape-spezifischen Hinweis. Bei KernelCare nicht raten, sondern `kcarectl --patch-info` gegen CVE-2026-53359, Januscape oder den Fix-Commit prüfen.
Amazon Linux	Amazon Linux 2, die AL2-Kernel-Extras `5.4`, `5.10`, `5.15` sowie Amazon Linux 2023 `kernel`, `kernel6.12` und `kernel6.18` standen auf `Pending Fix`.
Oracle Linux	Oracle listet UEK-Errata für OL7, OL8, OL9 und OL10, unter anderem `ELSA-2026-50372`, `ELSA-2026-50373` und `ELSA-2026-50374`. Wichtig: UEK und RHCK getrennt prüfen.
SUSE / openSUSE	SUSE führt den Gesamtstatus als Pending. Für einige SLE-Micro-Container sind Pakete veröffentlicht, viele SLE-15-SP7-Kernelpakete stehen in QA oder In progress. SLE 16.0 und openSUSE Leap 16.0 sind als not affected sichtbar, viele ältere oder LTSS-Stände als affected.
Fedora	Bodhi lieferte für CVE-2026-53359 und Januscape keine Update-Treffer. Fedora-Hosts deshalb über die tatsächlich installierte Kernel-NVR und Advisory-Lage prüfen, nicht über bloße Upstream-Versionen.
Proxmox VE	Auch beim Recheck fand ich in den öffentlichen Proxmox-Changelogs keinen Hinweis auf Januscape, CVE-2026-53359 oder `81ccda30b4e8`. Zuletzt geprüft: `proxmox-kernel-7.0 7.0.14-3`, `6.17 6.17.13-14`, `6.14 6.14.11-9` und `6.8 6.8.12-32`. Besonders kritisch sind Nodes mit untrusted VMs und aktivem Nested KVM.

Weitere Hypervisor-Plattformen

Bei HCI- und Cloud-Appliances zählt nicht der Produktname, sondern die technische Schicht darunter: Läuft auf dem Node ein x86-Linux-Kernel mit KVM? Wird Nested Virtualization an untrusted Gäste durchgereicht? Gibt es ein Vendor-Update, das den Kernel-Fix belegt? Wenn eine dieser Fragen offen ist, würde ich die Plattform nicht vorschnell freigeben.

Plattform	Einordnung
Nutanix AHV	AHV nutzt KVM-Kernelmodul, libvirt und QEMU. Nutanix weist in KB-4989 darauf hin, dass Nested Virtualization auf AHV nicht unterstützt ist. Das senkt das praktische Januscape-Risiko in sauber unterstützten Standard-Setups deutlich. Trotzdem: AHV-Hosts bleiben KVM-Hosts. Unsupported Lab-Setups, Community Edition, CPU-Passthrough-Basteleien oder kundenseitig aktivierte Nested-Szenarien separat prüfen und Nutanix LCM/Security Advisories beobachten.
Sangfor HCI / aSV	Sangfor beschreibt aSV als Bare-Metal-Hypervisor mit KVM als Core Engine. Auf der öffentlichen Sangfor-Security-Advisory-Seite fand ich keinen Januscape-Eintrag. Solange Sangfor keinen fixierten aSV/HCI-Stand nennt, ist die sinnvolle Bewertung: KVM-basiert, Vendor-Fix abwarten, Nested Virtualization für Kunden-VMs nicht aktivieren.
Scale Computing HyperCore	Scale beschreibt SC//HyperCore als Virtualisierungsplattform mit KVM-basiertem Hypervisor. Ich fand keinen öffentlichen Januscape-Hinweis. Für produktive Bewertung zählen HyperCore-Version, Vendor-Support-Aussage und die Frage, ob Gäste Hardware-Virtualisierung sehen können.
Harvester / SUSE Virtualization / Rancher Virtualization	Harvester und SUSE Virtualization setzen auf KubeVirt, KVM und Kubernetes. Damit ist Januscape grundsätzlich eine Node-Kernel-Frage, nicht nur eine KubeVirt-Frage. Besonders relevant sind Multi-Tenant-Cluster, in denen Projekt- oder Namespace-Nutzer VMs erstellen dürfen. Harvester-KB-Tags enthielten zum geprüften Stand keinen Januscape-Beitrag.
Red Hat OpenShift Virtualization	OpenShift Virtualization basiert auf KubeVirt. Weil Red Hat RHEL 8/9/10-Kernel bereits als affected listet, sollten VM-fähige OpenShift-Worker ohne RHSA-Fix nicht als sicher gelten. Nested Virtualization für VM-Tenants ist der entscheidende Risikoverstärker.
OpenStack Nova mit KVM	Sehr relevant für Private-Cloud- und Public-Cloud-Setups. OpenStack selbst ist nicht der Fixpunkt; entscheidend ist der Compute-Node-Kernel. Wenn Nested Virtualization als Flavor, Image-Metadata oder Kundenfeature angeboten wird, hat Januscape hohe Priorität.
OpenNebula mit KVM	Gleiches Muster wie OpenStack: OpenNebula orchestriert, aber die Verwundbarkeit sitzt im KVM-Host-Kernel. KVM-Nodes mit untrusted Tenants und Nested-Freigabe priorisieren.
Apache CloudStack mit KVM	CloudStack unterstützt KVM-Hosts. Für Januscape zählt der Linux-Host unter dem CloudStack-Agent. Besonders bei Service-Providern mit Kunden-VMs und Nested-Angeboten prüfen.
oVirt / Red Hat Virtualization / Oracle Linux Virtualization Manager	KVM-basierte Host-Stacks. oVirt-Hosts, RHV-Hypervisor und OLVM-KVM-Hosts über RHEL-, Oracle- oder Community-Kernelstände bewerten. Bei alten oVirt/RHV-Installationen ist das Risiko oft weniger der Exploit selbst, sondern dass kein schneller, sauberer Kernel-Fix mehr eingeplant ist.
VMware ESXi, Microsoft Hyper-V, Xen/XCP-ng, Citrix Hypervisor, bhyve	Nicht direkt Januscape-betroffen, weil der Bug im Linux-KVM/x86-Code liegt. Relevant wird es nur indirekt, wenn darauf wiederum KVM verschachtelt betrieben wird oder Linux-Management-Appliances separat gepatcht werden müssen.

Schnelle Prüfung auf KVM-Hosts

Erster Schritt: herausfinden, welcher Kernel wirklich läuft und ob Nested Virtualization aktiv ist.

uname -r
lsmod | grep -E '^kvm(_intel|_amd)?[[:space:]]'

cat /sys/module/kvm_intel/parameters/nested 2>/dev/null || true
cat /sys/module/kvm_amd/parameters/nested 2>/dev/null || true

ls -l /dev/kvm
getent group kvm

Auf Proxmox-Hosts lohnt sich zusätzlich der Blick in die VM-Konfigurationen. Das ist nur ein Indikator, aber er zeigt schnell, ob Gäste sehr wahrscheinlich CPU-Virtualisierungsflags sehen.

grep -RInE '^(cpu:.*host|args:.*-cpu.*host|.*\+vmx|.*\+svm)' /etc/pve/qemu-server 2>/dev/null || true

Kernel-Pakete prüfen:

# Debian, Ubuntu, Proxmox
dpkg -l 'linux-image*' 'proxmox-kernel*' 'pve-kernel*' 2>/dev/null | awk '/^ii/ {print $2, $3}'
apt-cache policy proxmox-kernel-7.0 proxmox-kernel-6.17 proxmox-kernel-6.14 proxmox-kernel-6.8 2>/dev/null

# RHEL, AlmaLinux, Rocky, Oracle, Fedora
rpm -q kernel kernel-core kernel-rt kernel-uek 2>/dev/null

Wenn Livepatching im Spiel ist, muss der Livepatch-Status zur CVE passen. Ein neuer Paketstand allein hilft nicht, wenn der Host noch mit dem alten Kernel läuft. Ein Livepatch-Versprechen hilft ebenfalls nicht, wenn genau diese CVE nicht enthalten ist.

canonical-livepatch status --verbose 2>/dev/null || true
kpatch list 2>/dev/null || true
kcarectl --patch-info 2>/dev/null | grep -Ei 'CVE-2026-53359|Januscape|81ccda30' || true

Mitigation und Updates

Die saubere Lösung ist ein gepatchter Host-Kernel plus Reboot beziehungsweise ein nachweislich passender Livepatch. Für selbst gebaute oder sehr nahe an Upstream laufende Kernel sind die relevanten Stable-Versionen 7.1.3, 6.18.38, 6.12.95, 6.6.144, 6.1.177, 5.15.211 und 5.10.260.

Wenn noch kein Vendor-Fix verfügbar ist, ist die wichtigste temporäre Maßnahme: Nested Virtualization für untrusted Guests deaktivieren.

Für neue Modul-Ladungen kann das über Modprobe-Optionen vorbereitet werden:

printf '%s\n' 'options kvm_intel nested=0' | sudo tee /etc/modprobe.d/disable-kvm-nested.conf
printf '%s\n' 'options kvm_amd nested=0' | sudo tee -a /etc/modprobe.d/disable-kvm-nested.conf

Auf produktiven Virtualisierungshosts reicht das meistens erst nach einem Reboot sauber aus, weil laufende VMs die KVM-Module belegen. Alternativ kann der Kernel-Parameter gesetzt werden:

kvm_intel.nested=0 kvm_amd.nested=0

Bei Debian, Ubuntu und Proxmox hängt der genaue Weg davon ab, ob klassisches GRUB oder proxmox-boot-tool verwendet wird. Nach der Änderung immer auf dem laufenden Host gegenprüfen:

cat /sys/module/kvm_intel/parameters/nested 2>/dev/null || true
cat /sys/module/kvm_amd/parameters/nested 2>/dev/null || true

Wichtig: Nested Virtualization abzuschalten kann legitime Workloads brechen. Dazu gehören CI-Runner, Security-Labs, Android-Emulatoren, Kunden mit eigenem Hypervisor in der VM und Testumgebungen, die Kubernetes oder OpenStack verschachtelt betreiben. Das ist trotzdem oft der richtige Trade-off, wenn untrusted Guests auf einem nicht belegbar gepatchten Host laufen.

Einordnung für Proxmox, Hoster und MSPs

Für klassische Single-Tenant-Server ist Januscape unangenehm, aber meist planbar. Für VPS-Hoster, Proxmox-Cluster, Agenturserver mit Kunden-VMs und MSP-Plattformen ist die Lücke eine andere Klasse: Der Angreifer muss nicht in den Host einbrechen, sondern kontrolliert bereits eine VM auf dem Host.

Das ist der Punkt, der Januscape so ernst macht. Root in der Gast-VM ist kein Privileg, das man einem Kunden verweigern kann. Es ist der Normalzustand. Die eigentliche Sicherheitsgrenze ist der Hypervisor, und genau dort liegt die Schwachstelle.

Proxmox ist nicht automatisch verwundbar, nur weil Proxmox verwendet wird. Entscheidend sind Host-Kernel, CPU-Flags und Nested Virtualization. Ein Node ohne untrusted KVM-Gäste oder mit deaktiviertem Nested KVM hat ein deutlich anderes Risiko als ein VPS-Node, der cpu: host breit an Kunden-VMs ausrollt.

Für Cluster würde ich pragmatisch so vorgehen:

Alle Nodes mit KVM-Workloads und untrusted Gästen inventarisieren.
Prüfen, wo Nested Virtualization aktiv ist oder über cpu: host effektiv durchgereicht wird.
Nodes ohne belegten Kernel-Fix priorisieren.
Nested Virtualization für untrusted Pläne deaktivieren, bis ein Vendor-Fix installiert und der Host neu gestartet oder passend livegepatcht ist.
Nach dem Reboot den laufenden Kernel und die Nested-Parameter dokumentieren.

Was beim Patchen gern übersehen wird

Ein neuer Kernel ist installiert, aber der Host läuft noch mit dem alten Kernel.
Nur die Gast-VM wurde aktualisiert. Für Januscape zählt der Host-Kernel.
Livepatching ist aktiv, deckt diese konkrete CVE aber nicht ab.
Ein Teil der Cluster-Nodes hängt in einem anderen Repository oder auf einem älteren Kernel-Zweig.
Nested Virtualization wurde global deaktiviert, aber einzelne VMs bekommen weiterhin vmx oder svm über CPU-Flags.
/dev/kvm ist auf dem Host breiter zugänglich als erwartet.
Proxmox Enterprise-, No-Subscription- und Test-Repositories werden in der Bewertung vermischt.

Wie wir damit umgehen würden

Für Kundensysteme würden wir Januscape nicht nach CVSS allein priorisieren. Die wichtige Frage ist: Gibt es untrusted KVM-Gäste mit Nested Virtualization auf einem nicht belegbar gepatchten Host? Wenn ja, gehört das vor normale Wartungsroutine.

Der sinnvolle Ablauf ist kurz:

betroffene KVM-Hosts und Cluster-Nodes erfassen
laufenden Kernel und Vendor-Fixstand prüfen
Nested Virtualization pro Host und pro VM bewerten
bei fehlendem Fix Nested Virtualization für untrusted Guests abschalten
Updates und Reboots mit Migrationsplan durchführen
danach Kernel, Modulparameter und CPU-Flags aus Gastperspektive kontrollieren

Den öffentlichen PoC würde ich nicht auf produktiven Nodes testen. Er ist dafür gebaut, den Host zu crashen. Für die Bewertung reichen Kernelstand, Vendor-Advisory und Nested-Konfiguration.

Update-Log

2026-06-12: Januscape wurde an security@kernel.org gemeldet.
2026-06-17: Der Fix wurde auf der Kernel-Mailingliste veröffentlicht.
2026-06-19: Der Mainline-Fix 81ccda30b4e8 wurde gemergt.
2026-07-04: CVE-2026-53359 wurde vergeben, mehrere Upstream-Stable-Kernel wurden veröffentlicht.
2026-07-06 23:40 Uhr CEST: Beitrag erstellt, Distro- und Proxmox-Stände geprüft, Demo-GIF lokal eingebunden.
2026-07-07 02:05 Uhr CEST: Bewertung weiterer KVM-basierter Hypervisor-Stacks ergänzt: Nutanix AHV, Sangfor HCI/aSV, Scale HyperCore, Harvester/SUSE Virtualization, OpenShift Virtualization, OpenStack, OpenNebula, CloudStack und oVirt/OLVM.
2026-07-07 05:57 Uhr CEST: Recheck der Vendor-Stände. Debian, Ubuntu, Red Hat, AlmaLinux, Rocky Linux, Fedora, Amazon Linux, SUSE und Oracle unverändert. Proxmox-Changelogs aktualisiert geprüft; weiterhin kein belegter Januscape-Fix sichtbar.