Am 6. Juli 2026 wurde eine lokale Kernel‑Schwachstelle mit der Kennung CVE‑2026‑53359 öffentlich bekannt, die unter dem Namen «Januscape» diskutiert wird. Die Lücke betrifft KVM‑Nested‑Virtualisierung auf x86_64‑Systemen mit Intel‑ oder AMD‑Prozessoren und ermöglicht potenziell eine lokale Eskalation von Rechten im Hypervisor‑Kontext. Hersteller und Distributionen werden Kernel‑Updates bereitstellen; bis dahin existieren praktikable Konfigurations‑Workarounds, die Systembetreiber umgehend prüfen sollten.

Was ist Januscape (CVE‑2026‑53359)?

Januscape ist eine lokale Privilegieneskalation (LPE) im Linux‑Kernel, konkret im Bereich der geschachtelten Virtualisierung (nested virtualization) für KVM. Exploit‑Beispiele, darunter ein Proof‑of‑Concept, wurden veröffentlicht: Sie zeigen, dass ein Gastsystem einen Host zum Absturz bringen kann; einige Quellen berichten auch über funktionierende Full‑Exploits.

Nur x86_64‑Systeme mit Intel‑ oder AMD‑Implementierungen von KVM sind betroffen. Andere Architekturen gelten derzeit als nicht betroffen. Ubuntu‑Meldungen sprechen davon, dass alle Ubuntu‑Releases von dieser Schwachstelle berührt werden.

Bewertungen der Schwere variieren: Ubuntu errechnete einen CVSS‑Wert von 8.4 (CVSS v4), es sind aber auch andere Bewertungen veröffentlicht worden (z. B. 7.8, 8.8 und 9.3 in unterschiedlichen CVSS‑Versionen).

Welche Systeme sind besonders gefährdet?

Das größte Risiko besteht für Systeme, die als Hypervisor fungieren und Nested‑Virtualization erlauben — also Hosts, auf denen Gäste wiederum selbst virtuelle Maschinen starten können. Das umfasst:

• Eigenbetriebene KVM‑Hypervisor auf Intel/AMD‑Hardware.
• Cloud‑VMs bei Providern, die KVM als Hypervisor einsetzen und Nested‑Virtualization für Mieter freigeben.

Wenn ein Cloud‑Anbieter Nested‑Virtualisierung nicht erlaubt, ist der Kunde von diesem speziellen Problem nicht betroffen. Läuft die Virtualisierung dagegen, kann ein bösartiger Tenant unter Umständen die VM oder sogar den Host kompromittieren.

Angriffsoberflächen im Detail

Die Lücke lässt sich primär aus Kontexten ausnutzen, in denen ein Prozess innerhalb einer VM Kernelmodule laden oder ein neues Kernel‑Image bereitstellen kann – also alle Fälle, in denen Manipulationen an Seitentabellen möglich sind. Praktische Angriffsvektoren sind daher:

• Root‑Zugang in einer Gast‑VM.
• Benutzer oder Dienste, die das /dev/kvm‑Device beschreiben können.
• Privilegierte Container, die KVM‑Zugriff erlauben und damit VMs starten können.

Unprivilegierte Container hingegen haben in der Regel nicht die nötigen Rechte, um KVM‑beschleunigte VMs zu starten und gelten somit nicht als direkter Angriffsvektor.

Wie prüfe ich, ob mein System betroffen ist?

Auf einem Ubuntu‑ oder anderen Linux‑System lässt sich der Status der verschachtelten Virtualisierung per sysfs prüfen. Die folgenden Befehle helfen, die betroffenen KVM‑Module zu untersuchen:

grep . /sys/module/kvm_{amd,intel}/parameters/nested

Ausgabehinweise:

• Ein Wert «1» oder «Y» signalisiert, dass Nested‑Virtualization aktiv und damit potenziell verwundbar ist.
• Ein Wert «0» oder «N» bedeutet, dass Nested‑Virtualization bereits deaktiviert ist und damit als mitigiert gelten kann.
• Fehlermeldungen «No such file or directory» können auftauchen, weil ein Modul derzeit nicht geladen ist. Solche Meldungen allein garantieren jedoch nicht, dass das System sicher ist — das Modul könnte später geladen werden.

Prüfen Sie zudem die Zugriffsrechte auf das Device‑Node /dev/kvm, da Schreibrechte auf dieses Device für die Ausnutzung relevant sein können:

namei -l /dev/kvm
getfacl /dev/kvm

Auf Ubuntu ist /dev/kvm standardmäßig für root und die Gruppe «kvm» schreibbar. Stellen Sie sicher, dass nur vertrauenswürdige Nutzer der Gruppe «kvm» hinzugefügt werden.

Vorläufige Gegenmaßnahmen: Nested‑Virtualization deaktivieren

Solange noch kein Kernel‑Patch eingespielt wurde, lässt sich die Angriffsfläche deutlich reduzieren, indem Sie die Unterstützung für verschachtelte Virtualisierung abschalten. Die folgende Reihenfolge ist als Arbeitsanweisung gedacht:

1. Alle laufenden KVM‑VMs stoppen.
2. Die KVM‑Module gefahrlos entladen:

sudo rmmod kvm_amd ; sudo rmmod kvm_intel

Hinweis: Falls eins der Module nicht geladen ist, meldet rmmod einen Fehler, das ist unproblematisch.

3. Nach Konfigurationsdateien suchen, die Nested‑Support aktivieren könnten:

grep nested /etc/modprobe.d/*

4. Nested‑Virtualization für beide Implementierungen deaktivieren, indem entsprechende Optionen in /etc/modprobe.d gesetzt werden:

echo 'options kvm_amd nested=0' | sudo tee /etc/modprobe.d/nested.conf
echo 'options kvm_intel nested=0' | sudo tee -a /etc/modprobe.d/nested.conf

5. Module bei Bedarf neu laden:

sudo modprobe kvm_amd ; sudo modprobe kvm_intel

Nach diesen Schritten sollte das Prüfen der oben genannten sysfs‑Einträge einen deaktivierten Zustand anzeigen.

Besondere Hinweise für Cloud‑ und Container‑Betreiber

Cloud‑Kunden sollten klären, ob ihr Provider KVM als Hypervisor einsetzt und ob Nested‑Virtualization für Instanzen erlaubt ist. Wenn Nested‑Virtualization verfügbar ist, besteht das Risiko, dass ein anderer Mieter einen Exploit nutzt, um angrenzende Instanzen oder den Host zu beeinträchtigen.

Bei Container‑Workloads gilt: Unprivilegierte Container sind in der Regel unkritisch; privilegierte Container können jedoch die gleichen Risiken wie virtuelle Maschinen eröffnen und sollten deshalb wie virtuelle Umgebungen bewertet werden.

Patchstatus und Empfehlung

Ubuntu kündigt Kernel‑Pakete an, die die vorgeschlagene Fehlerbehebung implementieren werden. Installieren Sie diese Updates, sobald sie verfügbar sind — für Hypervisor‑Hosts hat der Kernel‑Fix Priorität. Bis dahin ist das Abschalten von Nested‑Virtualization die praktikabelste Sofortmaßnahme. Bedenken Sie, dass diese Maßnahme legitime Arbeitsabläufe beeinträchtigen kann, wenn Sie selbst oder Nutzer bewusst verschachtelte Virtualisierung benötigen; wägen Sie Risiko gegen Betriebsanforderungen ab.

Fazit

CVE‑2026‑53359 (Januscape) ist eine ernst zu nehmende lokale Schwachstelle im Bereich von KVM‑Nested‑Virtualisierung auf Intel/AMD x86_64‑Plattformen. Betreiber von Hypervisoren und Cloud‑Infrastrukturen sollten umgehend prüfen, ob Nested‑Virtualization aktiv ist, die Zugriffsrechte auf /dev/kvm kontrollieren und vorläufig Nested‑Virtualization deaktivieren, bis die Kernel‑Patches verteilt und installiert wurden. Für Systemadministratoren gilt derzeit: schnell prüfen, sinnvoll mitigieren, Updates einspielen.

Technischer Hinweis: Die ursprüngliche Analyse und ein technischer Write‑up stammen vom Exploit‑Autor Hyunwoo Kim. Distributionen und Betroffene arbeiten an entsprechenden Kernel‑Releases.