Security 06.07.2026, 23:40 Aktualisiert: 07.08.2026, 02:28

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.08.2026, 02:28

Stand: 07.08.2026, 02:28 Uhr CEST. Die Lage ist deutlich besser als Mitte Juli: RHEL 8, mehrere OpenShift-Zweige, Amazon Linux und weitere SUSE-Produkte haben inzwischen Updates. Ubuntu bleibt offen. Als gepatcht gilt ein System erst, wenn der Hersteller den Fix belegt und der neue Kernel tatsächlich läuft.

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: Die Mindest-Fixstände bleiben 6.8.12-33-pve für PVE 8 sowie 7.0.14-4-pve oder 6.17.13-15-pve für PVE 9. In pve-no-subscription liegen inzwischen 6.8.12-40, 7.0.14-9 und 6.17.13-21. Der alte 6.14-Zweig steht weiter bei 6.14.11-9 und hat keinen belegten Januscape-Backport. Nach dem Update zählt deshalb nur uname -r, nicht das installierte Metapaket.
Neue Produktionsupdates: RHEL 8 und dessen RT-Kernel sind gefixt. Debian Bookworm Security, mehrere OpenShift/RHCOS-Zweige, Amazon Linux 2023 und die AL2-Extras 5.10/5.15 haben ebenfalls Updates. SUSE deckt inzwischen unter anderem SLE 16.0, Linux Micro 6.1/6.2 und weitere SLE-15-LTSS-Zweige ab. Ubuntu bleibt trotz laufender Arbeiten verwundbar.
Harvester: Der Januscape-Hinweis ist seit dem 15.07. eine offizielle Harvester-KB. Dort gelten 1.6.1 und älter, 1.7.2 und älter sowie 1.8.1 und älter als betroffen. Harvester 1.8.2 erschien am 06.08., wird in der KB und den bislang knappen Release Notes aber noch nicht ausdrücklich als Januscape-Fix ausgewiesen. Bis das geklärt ist, bleibt die dokumentierte CloudInit-Mitigation sinnvoll.
Andere KVM-Hypervisor: Red Hat hat konkrete RHCOS-Fixstände für OpenShift 4.14 und 4.18 bis 4.22 veröffentlicht. Für Nutanix AHV, Sangfor aSV/HCI, Scale HyperCore, OpenStack, OpenNebula, CloudStack und oVirt fand ich weiterhin keinen produktspezifischen Januscape-Hinweis. Dort muss der Kernelstand der Hosts geprüft werden. Talos 1.13.7 läuft mit dem gefixten Linux 6.18.39.

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.

Die KVM-Escape-Trilogie

Januscape ist inzwischen nicht mehr der einzige öffentlich dokumentierte KVM-Escape dieser Art. ITScape trifft KVM auf ARM64 über die virtuelle GICv3-ITS-Emulation und braucht kein Nested KVM. Zapscape greift wie Januscape die x86-Shadow-MMU bei Nested Virtualization an, nutzt aber einen anderen Use-after-free und kommt mit einer veröffentlichten Root-Kette für den Host.

Die drei CVEs haben unterschiedliche Voraussetzungen und Fixstände. Für eine Hostbewertung sollten sie deshalb getrennt geprüft werden.

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

Die Tabelle bleibt eine Momentaufnahme. Hersteller pflegen ihre Kernelzweige unabhängig voneinander, und eine höhere Versionsnummer ist ohne Advisory oder Changelog noch kein Beleg für den Fix.

Plattform	Stand am 07.08.2026, 02:00 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`. Mehrere Vendoren weisen zusätzlich darauf hin, dass der gekoppelte Fix `0cb2af2ea66a` für CVE-2026-46113 mitgeprüft werden sollte.
Debian	Trixie ist über `trixie-security` ab `linux 6.12.95-1` gefixt; aktuell liegt dort `6.12.101-1`. Bookworm ist jetzt ebenfalls abgedeckt: Der Tracker nennt `6.1.177-1` als Fix, in `bookworm-security` liegt `6.1.180-1`. Forky und Sid sind ab `7.1.3-1` gefixt. Bullseyes Standardkernel 5.10 bleibt offen; der separate `linux-6.1`-Zweig ist über `6.1.177-1~deb11u1` gefixt.
Ubuntu	Canonical führt Januscape weiter mit Priorität `High`. Die am 06.08. aktualisierte Seite markiert den Standardkernel für 26.04, 24.04, 22.04, 20.04 und die geprüften ESM-Releases als `Vulnerable, work in progress`. Das gilt auch für zahlreiche Cloud-Flavours. Es gibt weiterhin kein USN und keinen veröffentlichten Mindest-Fixstand.
Red Hat Enterprise Linux	RHEL 8 ist seit `RHSA-2026:39083` ab `kernel-4.18.0-553.143.1.el8_10` gefixt; für den RT-Kernel gilt `4.18.0-553.143.1.rt7.484.el8_10` aus `RHSA-2026:39082`. RHEL 9 bleibt ab `5.14.0-687.24.1.el9_8`, RHEL 10 ab `6.12.0-211.32.1.el10_2` abgedeckt. Hinzu kamen Fixes für RHEL 10.0 EUS, RHEL 8.6 AUS/EUS-Laufzeitverlängerung, RHEL 8.8 TUS/E4S und RHEL 9.2 E4S. Für RHEL 8, 9 und 10 gibt es inzwischen auch Kpatch-Advisories. Der normale RHEL-9-RT-Zweig steht im CVE-Datensatz weiterhin auf `Affected`.
AlmaLinux	Alle unterstützten Releases sind inzwischen über die normalen Production-Repositories abgedeckt: AlmaLinux 8 ab `kernel-4.18.0-553.141.2.el8_10`, AlmaLinux 9 ab `kernel-5.14.0-687.23.1.el9_8` und AlmaLinux 10 ab `kernel-6.12.0-211.31.1.el10_2`. Nach dem Update neu starten und den laufenden Kernel mit `uname -r` prüfen.
Rocky Linux	Rocky 10 ist über `RLSA-2026:36956` ab `kernel-6.12.0-211.32.1.el10_2` gefixt, Rocky 9 über `RLSA-2026:36957` ab `kernel-5.14.0-687.24.1.el9_8`. Die Rocky-Errata-API liefert weiterhin keinen Januscape-Hinweis für Rocky 8. Später gebaute Kernelpakete allein sind ohne zugehöriges Erratum kein belastbarer Fixnachweis.
CloudLinux / KernelCare	Der offizielle CloudLinux-Beitrag wurde seit dem 10.07. nicht mehr aktualisiert und ist bei den AlmaLinux-Verweisen sichtbar überholt. Für die eigenen Kernel nennt er CL7h und CL8 nur im Beta-/Testing-Channel. Beim damaligen KernelCare-Stand war CL10 vollständig im Main-Feed, CL8 im gestaffelten Rollout, CL7h im Testing-Feed und CL9 noch in Vorbereitung; CloudLinux for Ubuntu 22.04 war vollständig ausgerollt. Dieser Stand reicht heute nicht für eine pauschale Freigabe. Auf jedem Host mit `kcarectl --patch-info` prüfen, ob CVE-2026-53359 und CVE-2026-46113 enthalten sind.
Amazon Linux	Amazon Linux 2023 ist für alle drei gelisteten Kernelreihen gefixt: `kernel` über `ALAS2023-2026-2001`, `kernel6.12` über `ALAS2023-2026-1970` und `kernel6.18` über `ALAS2023-2026-1969`. Bei Amazon Linux 2 sind die Extras 5.10 (`ALAS2KERNEL-5.10-2026-126`) und 5.15 (`ALAS2KERNEL-5.15-2026-111`) gefixt. AL2 Core und das 5.4-Extra stehen weiter auf `Pending Fix`.
Oracle Linux	UEK ist für OL7, OL8, OL9 und OL10 über `ELSA-2026-50372`, `50373` und `50374` abgedeckt. Für RHCK gibt es nun ebenfalls Fixes: OL8 über `ELSA-2026-39083`, OL9 über `ELSA-2026-36957`. UEK und RHCK nicht miteinander verwechseln; auf dem Host zählt der laufende Kernel.
SUSE / openSUSE	SUSE führt den Gesamtstatus weiterhin als `Pending`, hat aber viele Lücken geschlossen. SLE 15 SP7 ist aktuell ab `kernel-default-6.4.0-150700.53.73.2` abgedeckt. Fixstände gibt es außerdem für SLE 15 SP4 LTSS (`5.14.21-150400.24.228.1`), SP5 LTSS (`5.14.21-150500.55.177.1`) und SP6 LTSS (`6.4.0-150600.23.125.1`). SLE 16.0, Leap 16.0 und Linux Micro 6.2 sind ab `6.12.0-160000.36.1` gefixt; Micro 6.0 und 6.1 ab `6.4.0-50.1`. Tumbleweed ist ab `7.1.3-1.1` abgedeckt. Einzelne Altprodukte, Livepatch-Pakete und Subpakete bleiben offen oder in Arbeit, deshalb den exakten Produktzweig im SUSE-Tracker prüfen.
Fedora	Fedora 43 und 44 haben `kernel-7.1.3` seit dem 07.07. als Stable-Update. Damit ist der Upstream-Fix enthalten, auch wenn die Bodhi-Suche nach der CVE selbst keinen Treffer liefert. Entscheidend bleibt, dass nach dem Update tatsächlich `7.1.3` oder neuer läuft.
Arch Linux	Aktuell liegen `linux 7.1.6.arch1-1` und `linux-lts 6.18.42-1` in Core. Beide sind neuer als der jeweilige Upstream-Fixstand. Nach `pacman -Syu` neu starten und `uname -r` prüfen.
Gentoo	Die aktuellen amd64-Pakete liegen ebenfalls oberhalb der Fixstände, unter anderem bei `7.1.6`, `6.18.42`, `6.12.101`, `6.6.148` und `6.1.180`. Für eigene Kernel gilt weiterhin: passender Stable-Fix oder Commit `81ccda30b4e8`.
Proxmox VE	Die Mindeststände bleiben `proxmox-kernel-6.8 6.8.12-33` für PVE 8 sowie `proxmox-kernel-7.0 7.0.14-4` oder `proxmox-kernel-6.17 6.17.13-15` für PVE 9. Proxmox bestätigte sie für `pve-no-subscription` und `pve-enterprise`. Im öffentlichen No-Subscription-Repository liegen aktuell `6.8.12-40`, `7.0.14-9` und `6.17.13-21`; die kumulativen Changelogs enthalten den Januscape-Backport. Der alte 6.14-Zweig bleibt bei `6.14.11-9` beziehungsweise `6.14.11-9~bpo12+1` und hat keinen solchen Eintrag. Ein PVE-Node ist also nur dann abgedeckt, wenn er nach dem Reboot tatsächlich in einem der gefixten Zweige läuft.

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 Risiko in regulären Setups deutlich. Einen öffentlichen Januscape-Advisory oder festen AOS/AHV-Fixstand fand ich auch am 07.08. nicht. Lab-Setups, Community Edition und abweichende CPU-Passthrough-Konfigurationen separat prüfen.
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 weiterhin keinen öffentlichen Januscape-Hinweis. Für die produktive Bewertung zählen deshalb HyperCore-Version, eine Aussage des Supports und die Frage, ob Gäste Hardware-Virtualisierung sehen können.
Harvester / SUSE Virtualization / Rancher Virtualization	Seit dem 15.07. ist der Januscape-Hinweis eine offizielle Harvester-KB. Betroffen sind laut Hersteller 1.6.1 und älter, 1.7.2 und älter sowie 1.8.1 und älter. Die KB empfiehlt, Nested Virtualization per Harvester-`CloudInit` abzuschalten und alle Hosts neu zu starten. Reguläre Cluster-Funktionen sollen dadurch nicht beeinträchtigt werden, weil Harvester Nested Virtualization in Gästen ohnehin nicht unterstützt. Harvester 1.8.2 wurde am 06.08. veröffentlicht, aber weder die KB noch die öffentlichen Release Notes bestätigen diese Version bislang ausdrücklich als Januscape-Fix. Deshalb gibt es noch keine pauschale Freigabe für 1.8.2.
Red Hat OpenShift Virtualization	Red Hat hat RHCOS-Updates für OpenShift 4.14 sowie 4.18 bis 4.22 veröffentlicht. Die konkreten Pakete beginnen bei `rhcos-414.92.202607210313-0`, `rhcos-418.94.202607211754-0`, `rhcos-4.19.9.6.202607220857-0`, `rhcos-4.20.9.6.202607151937-0`, `rhcos-4.21.9.6.202607151836-0` und `rhcos-4.22.9.8.202607152026-0`. RHEL-RPMs auf einem Admin-System patchen RHCOS-Nodes nicht. Nicht aufgeführte OpenShift-Zweige müssen gegen den Red-Hat-Datensatz oder über den Support geprüft werden.
Talos Linux mit KubeVirt	Talos 1.13.6 war bereits durch Linux 6.18.38 abgedeckt. Aktuell ist 1.13.7 mit Linux 6.18.39. Für KubeVirt-Nodes gilt trotzdem: den Cluster vollständig aktualisieren und den tatsächlich laufenden Kernel prüfen.
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. Die Hosts müssen über ihre RHEL-, Oracle- oder Community-Kernelstände bewertet werden. RHEL 8/9/10 sowie Oracle UEK und die aktuellen OL8/OL9-RHCK-Zweige haben Fixpfade. Bei alten oVirt- und RHV-Installationen bleibt das Supportende ein eigenes Risiko.
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

# Proxmox: der laufende Kernel muss nach dem Reboot einer der Fixstände sein
uname -r
# PVE 8:  6.8.12-33-pve oder neuer im 6.8-Zweig
# PVE 9:  7.0.14-4-pve oder neuer im 7.0-Zweig, alternativ 6.17.13-15-pve oder neuer

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

# Gefixte Produktionsstände aus den Vendor-Hinweisen
# RHEL 8:      4.18.0-553.143.1.el8_10 oder neuer
# RHEL 9:      5.14.0-687.24.1.el9_8 oder neuer
# RHEL 10:     6.12.0-211.32.1.el10_2 oder neuer
# AlmaLinux 8: 4.18.0-553.141.2.el8_10 oder neuer
# AlmaLinux 9: 5.14.0-687.23.1.el9_8 oder neuer
# AlmaLinux 10: 6.12.0-211.31.1.el10_2 oder neuer
# Rocky 9:     5.14.0-687.24.1.el9_8 oder neuer
# Rocky 10:    6.12.0-211.32.1.el10_2 oder neuer
# Oracle 9 RHCK: 5.14.0-687.24.1.el9_8 oder neuer
# Fedora 43/44: 7.1.3 oder neuer

# Arch Linux
pacman -Q linux linux-lts 2>/dev/null

# Gentoo Distribution Kernel
qlist -Iv sys-kernel/gentoo-kernel-bin 2>/dev/null || true

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|CVE-2026-46113|Januscape|81ccda30|0cb2af2e' || 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 Proxmox war das nicht nur eine allgemeine Empfehlung: Ein Proxmox-Staff-Member nannte im Forum als bekannte Mitigation ausdrücklich das Abschalten von Nested KVM. Inzwischen liegen Fix-Kernel in pve-no-subscription und laut Proxmox-Staff auch in pve-enterprise; die Mitigation bleibt trotzdem sinnvoll, solange ein Node noch nicht in einen gepatchten Kernel gebootet wurde.

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.
2026-07-07 13:54 Uhr CEST: Ubuntu-Status aktualisiert: Standard-linux-Kernel nicht mehr nur Needs evaluation, sondern für die geprüften Releases als Vulnerable sichtbar. Kein Ubuntu-Fixstand veröffentlicht. Alle anderen geprüften Vendor-Stände weiterhin ohne neuen belegten Fix.
2026-07-07 13:59 Uhr CEST: Proxmox-Update ergänzt: Proxmox-Staff bestätigt vorbereitete Fix-Kernel und Nested-KVM-Deaktivierung als bekannte Mitigation. Test-Repository-Changelogs belegen CVE-2026-53359-Backports für proxmox-kernel-7.0 7.0.14-4, 6.17 6.17.13-15 und 6.8 6.8.12-33; No-Subscription-Changelogs waren beim Recheck noch nicht auf diesen Ständen.
2026-07-07 23:48 Uhr CEST: Großer Recheck aller Quellen. Proxmox-Fix-Kernel sind jetzt in pve-no-subscription sichtbar. Ubuntu priorisiert die CVE inzwischen als High. AlmaLinux nennt Testing-Kernel für 8/9/10, aber noch kein Produktions-Erratum in den öffentlichen JSON-Daten. CloudLinux/TuxCare hat einen eigenen Hinweis mit Beta-/Testing-Kerneln und KernelCare-Livepatch-Ständen veröffentlicht. SUSE hat erste Micro-Container-Paketstände veröffentlicht, Gesamtstatus bleibt Pending.
2026-07-08 11:36 Uhr CEST: Recheck aller Quellen. PVE 8 und PVE 9 sind in pve-no-subscription für die relevanten Kernel-Zweige abgedeckt: PVE 8 mit 6.8.12-33-pve, PVE 9 mit 7.0.14-4-pve beziehungsweise 6.17.13-15-pve. Keine pauschale Entwarnung für noch laufende Alt-Kernel, den 6.14-Zweig oder nicht verifizierte Enterprise-Repos. Debian, Ubuntu, RHEL, AlmaLinux, Rocky, Fedora, Amazon Linux, Oracle, SUSE und CloudLinux erneut geprüft; keine neue vollständige Stable-Entwarnung außerhalb der bereits genannten Stände.
2026-07-10 00:10 Uhr CEST: Großer Vendor-Recheck. Proxmox bestätigt die Fix-Kernel jetzt auch für pve-enterprise. RHEL 9/10 und AlmaLinux 9/10 haben Produktionskernel, SLE 15 SP7 hat konkrete Kernel-Advisories. Fedora 43/44, Arch Linux und Gentoo sind über gefixte Upstream-Stände abgedeckt. RHEL 8, AlmaLinux 8 Production, Rocky Linux, Ubuntu und Amazon Linux bleiben offen oder nur über Sonderkanäle abgedeckt. Für Nutanix, Sangfor, Scale, Harvester/SUSE Virtualization, KubeVirt, OpenStack, OpenNebula, CloudStack und oVirt fand ich weiterhin keinen neuen produktspezifischen Januscape-Advisory.
2026-07-14 23:12 Uhr CEST: Vendor-Recheck aktualisiert. AlmaLinux 8 sowie Rocky Linux 9/10 sind jetzt in Production gefixt; RHEL hat E4S-/EUS-Stände ergänzt, Oracle einen RHCK-Fix für OL9. SUSE hat weitere LTSS- und Tumbleweed-Pakete veröffentlicht, stuft SLE/Leap 16 aber inzwischen als betroffen ein. Red Hat markiert OpenShift/RHCOS ausdrücklich als affected. Ein neuer, noch offener Harvester-KB-PR nennt alle unterstützten Harvester-Versionen als betroffen und beschreibt die Nested-KVM-Mitigation. Talos 1.13.6 ist über Linux 6.18.38 abgedeckt. Ubuntu, RHEL 8 und Amazon Linux bleiben offen; für Nutanix, Sangfor, Scale, OpenStack, OpenNebula, CloudStack und oVirt gibt es weiterhin keinen öffentlichen produktspezifischen Fixstand.
2026-08-07 02:00 Uhr CEST: Alle Herstellerquellen erneut geprüft. RHEL 8 und mehrere Sonderzweige sind jetzt gefixt, ebenso Debian Bookworm Security, Amazon Linux 2023, die AL2-Kernel-Extras 5.10/5.15, OL8 RHCK und mehrere SUSE-Produkte. Red Hat hat feste RHCOS-Pakete für OpenShift 4.14 und 4.18 bis 4.22 veröffentlicht. Der Harvester-Hinweis ist inzwischen eine offizielle KB; für das neue Harvester 1.8.2 fehlt dort noch die ausdrückliche Fixbestätigung. Proxmox liefert aktuelle Folgepakete, die Mindeststände bleiben unverändert. Ubuntu, AL2 Core, AL2 Kernel 5.4, Rocky 8 und RHEL 9 RT sind weiterhin offen oder ohne belastbaren Vendor-Fix.
2026-08-07 02:28 Uhr CEST: Querverweise auf ITScape und Zapscape ergänzt und die drei technisch unterschiedlichen KVM-Escapes voneinander abgegrenzt.