Der Kern des Problems ist ein Use-after-free-Bug in KVM. Beim Betrieb virtueller Maschinen verwaltet KVM eigene Seitentabellen, die die Speicherbelegung des Gasts nachbilden. Benötigt KVM eine solche Verwaltungsseite, sucht es nach einer vorhandenen Seite zur Wiederverwendung. Laut der Beschreibung wurde dabei jedoch nur die Speicheradresse abgeglichen, nicht aber der Typ der jeweiligen Tracking-Seite.
Genau diese Verwechslung führt dazu, dass KVM mitunter die falsche Art von Seite erneut verwendet. Dadurch geraten die internen Zuordnungen durcheinander, welche Seite wohin gehört. Meist erkennt der Kernel den inkonsistenten Zustand und fährt sich zum Schutz sofort herunter. Die öffentliche Machbarkeitsdemonstration zeigt genau diesen Fall: Eine Gast-VM kann den gesamten Host abstürzen lassen und damit alle anderen VMs auf demselben System außer Betrieb setzen.
Der schwerwiegendere Fall tritt ein, wenn die freigegebene Tracking-Seite vor der Bereinigung für einen anderen Zweck neu vergeben wird. Dann schreibt die Bereinigungsroutine einen Wert in einen Speicherbereich, der ihr nicht mehr gehört. Laut Kim kontrolliert ein Angreifer dabei nicht den geschriebenen Wert, wohl aber das Ziel dieses Schreibzugriffs. Auch diese eingeschränkte Kontrolle lasse sich zur Codeausführung auf dem Host weiterentwickeln.
Nach Angaben von Kim verhält sich die Schwachstelle auf Intel- und AMD-Prozessoren gleich; nur der letzte und schwierigste Schritt zur vollständigen Übernahme unterscheide sich zwischen beiden Plattformen. Der Exploit benötigt aus der Gast-VM heraus Root-Rechte sowie vom Host bereitgestellte verschachtelte Virtualisierung. Selbst wenn Hosts standardmäßig hardwaregestütztes EPT oder NPT nutzen, zwingt verschachtelte Virtualisierung KVM zurück auf die ältere Shadow-MMU-Codebasis, in der der Fehler sitzt. QEMU oder ein Userspace-VMM müssen dafür nicht mitwirken, weil es sich ausschließlich um einen In-Kernel-Fehler in KVM handelt.
Der verwundbare Code ist seit Commit 2032a93d66fa aus der Zeit von Kernel 2.6.36 im August 2010 vorhanden. Behoben wurde der Fehler durch Commit 81ccda30b4e8, der am 19. Juni 2026 in den Mainline-Kernel übernommen wurde. KVM-Maintainer Paolo Bonzini verfasste den Patch. Die Korrektur besteht aus einer einzeiligen Ergänzung in kvm_mmu_get_child_sp(): Die Wiederverwendungsbedingung prüft nun zusätzlich role.word neben dem gfn, sodass eine Shadow-Seite nur dann erneut verwendet wird, wenn sowohl Frame-Nummer als auch Rolle übereinstimmen.
Laut Quelltext wurden korrigierte Stable-Versionen am 4. Juli 2026 ausgeliefert: 7.1.3, 6.18.38, 6.12.95, 6.6.144, 6.1.177, 5.15.211 und 5.10.260. Die NVD hat CVE-2026-53359 bislang noch keinen CVSS-Wert zugewiesen. Wer x86-KVM-Hosts mit Mehrmandantenbetrieb und verschachtelter Virtualisierung betreibt, soll prüfen, ob der Kernel Commit 81ccda30b4e8 enthält; bei Distributions-Backports könne der Fix unter einer anderen Versionsnummer auftauchen, weshalb laut Quelle das Paket-Änderungsprotokoll aussagekräftiger ist als uname -r allein.
Falls ein Update nicht sofort möglich ist, entfernt das Abschalten verschachtelter Virtualisierung über kvm_intel.nested=0 oder kvm_amd.nested=0 den Angriffsweg für nicht vertrauenswürdige Gäste. ARM64-Hosts sind von Januscape nicht betroffen; ITScape (CVE-2026-46316) ist laut Quelle ein separates KVM/arm64-Problem.
Kim bezeichnet Januscape als nach öffentlichem Kenntnisstand den ersten Gast-zu-Host-Exploit, der sich sowohl auf Intel als auch auf AMD auslösen lässt. Er ist bereits Kims dritte Linux-Kernel-Exploit-Veröffentlichung in rund zwei Monaten. Im Mai 2026 hatte er Dirty Frag (CVE-2026-43284 / CVE-2026-43500) offengelegt, im Juni ITScape. Google hatte kvmCTF 2024 gestartet, weil KVM sowohl Android als auch Google Cloud zugrunde liegt. Erst im Mai 2026 war zudem mit CVE-2026-46113 ein weiterer Use-after-free im KVM-x86-Shadow-Paging behoben worden, der einen verwandten, aber eigenständigen rmap-Fehlabgleich betraf.