Anfang Juli 2026 wurde mit Januscape, CVE-2026-53359, eine schwerwiegende Sicherheitslücke im Linux-Kernel veröffentlicht.

Die Schwachstelle betrifft die KVM-Virtualisierung auf x86-Systemen und kann im schwerwiegendsten Fall einen Ausbruch aus einer virtuellen Maschine auf den zugrunde liegenden Linux-Host ermöglichen.

Betroffen sein können sowohl Intel- als auch AMD-Systeme. Besonders relevant ist die Schwachstelle für Unternehmen, Hosting-Anbieter, Rechenzentren und Administratoren, die Linux-Systeme als Virtualisierungshost verwenden.

Was ist Januscape?

Januscape ist die Bezeichnung für die Schwachstelle CVE-2026-53359 im KVM-Subsystem des Linux-Kernels.

KVM steht für Kernel-based Virtual Machine. Die Technik ermöglicht es, einen Linux-Server als Hypervisor zu verwenden und darauf virtuelle Maschinen auszuführen.

Die Schwachstelle befindet sich in der Speicherverwaltung der x86-KVM-Implementierung. Genauer betroffen ist die sogenannte Shadow-Paging- beziehungsweise Shadow-MMU-Logik.

Durch eine fehlerhafte Zuordnung und Wiederverwendung interner Speicherstrukturen kann es zu einer Use-after-free-Situation kommen. Dabei greift der Kernel auf einen Speicherbereich zu, der bereits freigegeben wurde.

Welche Auswirkungen sind möglich?

Die Auswirkungen hängen von der Konfiguration des Linux-Hosts und den Berechtigungen des Angreifers ab.

Mögliche Folgen sind:

Absturz des Linux-Hypervisors
Ausfall aller virtuellen Maschinen auf dem betroffenen Host
Denial-of-Service gegen andere Mandanten oder Systeme
Ausführung von Code auf dem Virtualisierungshost
Erlangung von Root-Berechtigungen auf dem Host
Zugriff auf andere virtuelle Maschinen des gleichen Hosts

Canonical bezeichnet die Schwachstelle als möglichen Guest-to-Host-Escape. Ein Angreifer, der innerhalb einer virtuellen Maschine ausreichende Kontrolle besitzt, könnte die Isolation zwischen Gast und Host überwinden.

Was bedeutet Guest-to-Host-Escape?

Normalerweise soll eine virtuelle Maschine vollständig vom Virtualisierungshost und von anderen virtuellen Maschinen getrennt sein.

Selbst wenn ein Angreifer innerhalb einer virtuellen Maschine Administrator- oder Root-Berechtigungen erlangt, sollte er dadurch nicht automatisch Zugriff auf den Hypervisor erhalten.

Bei einem Guest-to-Host-Escape gelingt es dem Angreifer jedoch, diese Sicherheitsgrenze zu überwinden. Dadurch kann aus einem zunächst auf eine einzelne virtuelle Maschine begrenzten Angriff eine vollständige Kompromittierung des Virtualisierungshosts entstehen.

Auf einem Host mit mehreren virtuellen Maschinen kann dies außerdem weitere Kunden, Abteilungen oder Dienste betreffen.

Welche Systeme sind betroffen?

Betroffen ist die x86-KVM-Implementierung des Linux-Kernels auf Intel- und AMD-Prozessoren.

Besonders relevant sind Systeme mit:

KVM- beziehungsweise QEMU-Virtualisierung
Proxmox Virtual Environment
libvirt und virt-manager
OpenStack auf KVM-Basis
Linux-basierten Cloud- und Hosting-Plattformen
verschachtelter Virtualisierung
CI/CD-Systemen, die virtuelle Maschinen starten dürfen
Entwicklungs- oder Testsystemen mit Zugriff auf /dev/kvm

Andere Prozessorarchitekturen sind von dieser konkreten x86-Schwachstelle nicht betroffen.

Welche Rolle spielt Nested Virtualization?

Besonders relevant ist Januscape bei aktivierter Nested Virtualization, also verschachtelter Virtualisierung.

Dabei darf eine virtuelle Maschine selbst wiederum weitere virtuelle Maschinen starten. Ein Gastbetriebssystem erhält dafür Zugriff auf bestimmte Hardwarevirtualisierungsfunktionen des Prozessors.

Dies wird beispielsweise eingesetzt bei:

virtuellen Testlaboren
Schulungsumgebungen
CI/CD- und Build-Systemen
Cloud-Plattformen
virtuellen Hyper-V- oder Proxmox-Testsystemen
Security- und Penetrationstest-Laboren

Ist Nested Virtualization nicht aktiviert und kann kein Benutzer oder Dienst auf die KVM-Schnittstelle zugreifen, reduziert sich die Angriffsfläche erheblich.

Wie lässt sich Nested Virtualization prüfen?

Auf einem Linux-KVM-Host kann der Status mit folgendem Befehl geprüft werden:

grep . /sys/module/kvm_{amd,intel}/parameters/nested 2>/dev/null

Mögliche Ausgaben sind:

1 oder Y: Nested Virtualization ist aktiviert.
0 oder N: Nested Virtualization ist deaktiviert.

Eine Meldung, dass eine der Dateien nicht existiert, ist normal. Ein System besitzt entweder einen Intel- oder einen AMD-Prozessor und lädt daher üblicherweise nur eines der beiden Kernelmodule.

Existieren beide Dateien nicht, bedeutet dies nicht automatisch, dass das System sicher ist. Das KVM-Modul könnte später geladen werden.

Zugriff auf /dev/kvm kontrollieren

Administratoren sollten zusätzlich kontrollieren, welche Benutzer und Dienste auf die KVM-Geräteschnittstelle zugreifen dürfen.

Die Berechtigungen können beispielsweise so geprüft werden:

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

Zugriff sollten ausschließlich ausdrücklich autorisierte Benutzer, Dienste und Gruppen besitzen.

Insbesondere gemeinsam genutzte Entwicklungsserver, Build-Systeme und Hosting-Plattformen sollten darauf geprüft werden, ob unprivilegierte Benutzer virtuelle Maschinen starten dürfen.

Sind normale Linux-Server ohne virtuelle Maschinen betroffen?

Ein Linux-Server, auf dem keine virtuellen Maschinen ausgeführt werden, ist nicht automatisch außerhalb des Risikobereichs.

Dienste wie libvirt, Incus, LXD, Multipass oder andere Virtualisierungsplattformen können es Benutzern ermöglichen, später virtuelle Maschinen zu erstellen.

Entscheidend sind daher folgende Fragen:

Sind die KVM-Kernelmodule geladen?
Ist Nested Virtualization aktiviert?
Wer darf auf /dev/kvm zugreifen?
Welche Benutzer sind Mitglied der Gruppe kvm?
Welche Dienste können virtuelle Maschinen starten?
Existieren privilegierte Container mit KVM-Zugriff?

Was gilt für Container?

Normale, unprivilegierte Container besitzen üblicherweise nicht die notwendigen Berechtigungen, um KVM-beschleunigte virtuelle Maschinen zu starten.

Privilegierte Container oder Container mit durchgereichtem /dev/kvm können jedoch eine relevante Angriffsfläche darstellen.

Docker-, Kubernetes- oder LXC-Umgebungen sollten deshalb darauf geprüft werden, ob KVM-Geräte in Container eingebunden wurden.

Ein Container sollte nicht allein deshalb als sicher betrachtet werden, weil die Anwendung nicht direkt auf dem Host ausgeführt wird.

Welche Linux-Distributionen sind betroffen?

Die Schwachstelle befindet sich im Linux-Kernel und betrifft daher grundsätzlich mehrere Distributionen.

Dazu gehören je nach Kernel und Produktstand unter anderem:

Ubuntu
Debian
Red Hat Enterprise Linux
AlmaLinux
Rocky Linux
SUSE Linux Enterprise
Oracle Linux
Proxmox VE
weitere KVM-basierte Linux-Systeme

Ob ein konkretes System betroffen ist, muss anhand des installierten Kernelpakets und der Sicherheitsinformationen des jeweiligen Distributionsherstellers geprüft werden.

Verfügbarkeit von Sicherheitsupdates

Die Verfügbarkeit korrigierter Kernel unterscheidet sich je nach Distribution und Versionszweig.

Für AlmaLinux 8, 9 und 10 wurden bereits korrigierte Kernel in den regulären Paketquellen bereitgestellt.

AlmaLinux nennt mindestens folgende korrigierte Versionen:

AlmaLinux 8: kernel-4.18.0-553.141.2.el8_10
AlmaLinux 9: kernel-5.14.0-687.23.1.el9_8
AlmaLinux 10: kernel-6.12.0-211.31.1.el10_2

Bei Ubuntu, Debian, Red Hat, Rocky Linux, SUSE und anderen Distributionen sollte unmittelbar der aktuelle Herstellerstatus kontrolliert werden. Die oben genannten AlmaLinux-Versionen dürfen nicht auf andere Distributionen übertragen werden.

Linux-Kernel aktualisieren

Sobald der jeweilige Distributionshersteller ein korrigiertes Kernelpaket bereitstellt, sollte es zeitnah installiert werden.

Ubuntu und Debian

sudo apt update
sudo apt full-upgrade
sudo reboot

AlmaLinux, Rocky Linux und RHEL

sudo dnf clean metadata
sudo dnf upgrade --refresh
sudo reboot

SUSE Linux Enterprise und openSUSE

sudo zypper refresh
sudo zypper update
sudo reboot

Vor der Installation muss geprüft werden, ob der jeweilige Hersteller bereits einen korrigierten Kernel bereitgestellt hat.

Warum ist ein Neustart notwendig?

Ein installiertes Kernelupdate wird nicht automatisch vom laufenden System verwendet.

Der neue Kernel wird normalerweise erst beim nächsten Neustart geladen. Deshalb reicht es nicht aus, lediglich das Paketupdate zu installieren.

Nach dem Neustart kann die laufende Kernelversion geprüft werden:

uname -r

Anschließend sollte die ausgegebene Version mit dem jeweiligen Security-Advisory der Distribution verglichen werden.

Vorübergehende Schutzmaßnahme: Nested Virtualization deaktivieren

Ist noch kein Sicherheitsupdate verfügbar, kann Nested Virtualization als vorübergehende Schutzmaßnahme deaktiviert werden.

Vor einer Änderung muss geprüft werden, ob verschachtelte Virtualisierung für produktive Dienste benötigt wird.

Für AMD-Systeme:

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

Für Intel-Systeme:

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

Anschließend müssen die KVM-Module neu geladen oder der Host neu gestartet werden.

Auf einem produktiven Hypervisor sollten Kernelmodule nicht während laufender virtueller Maschinen entfernt werden. In diesem Fall ist ein geplantes Wartungsfenster erforderlich.

Was Unternehmen jetzt tun sollten

Linux-Hypervisoren inventarisieren: Erfassen Sie alle KVM-, Proxmox-, libvirt-, OpenStack- und Cloud-Systeme.
Kernelversionen dokumentieren: Prüfen Sie die aktuell laufende Version mit uname -r.
Nested Virtualization prüfen: Kontrollieren Sie, ob verschachtelte Virtualisierung aktiviert ist.
/dev/kvm absichern: Ermitteln Sie, welche Benutzer, Gruppen und Container auf die KVM-Schnittstelle zugreifen dürfen.
Hersteller-Advisories prüfen: Kontrollieren Sie den Sicherheitsstatus für die konkret eingesetzte Distribution und Kernelvariante.
Kernelupdate installieren: Spielen Sie korrigierte Pakete ein, sobald sie verfügbar sind.
Wartungsfenster planen: Migrieren oder beenden Sie virtuelle Maschinen kontrolliert und starten Sie den Host anschließend neu.
Neue Kernelversion bestätigen: Prüfen Sie nach dem Neustart, ob tatsächlich der aktualisierte Kernel läuft.
Nicht benötigtes Nested Virtualization deaktivieren: Reduzieren Sie die Angriffsfläche, wenn die Funktion nicht benötigt wird.
Privilegierte Container prüfen: Entfernen Sie unnötigen Zugriff auf /dev/kvm.
Protokolle kontrollieren: Prüfen Sie Hypervisoren auf unerwartete Abstürze, neue virtuelle Maschinen und verdächtige administrative Aktivitäten.

Cloud-Server und gemietete virtuelle Maschinen

Bei einem gemieteten virtuellen Server kann der Kunde den Kernel des zugrunde liegenden Hypervisors normalerweise nicht selbst aktualisieren.

In diesem Fall ist der Cloud- oder Hosting-Anbieter für die Absicherung der KVM-Hosts verantwortlich.

Kunden sollten trotzdem prüfen:

ob der Anbieter eine Sicherheitsmeldung veröffentlicht hat,
ob Wartungsarbeiten angekündigt wurden,
ob Nested Virtualization für die eigene VM freigeschaltet ist,
ob ein Neustart oder eine Migration der VM erforderlich ist.

Laut Canonical sind Cloud-Umgebungen ohne freigegebene verschachtelte Virtualisierung von diesem konkreten Angriffsweg nicht betroffen.

Fazit

Januscape ist eine ernst zu nehmende Schwachstelle in der Linux-KVM-Virtualisierung.

Besonders kritisch ist die Möglichkeit, aus einer virtuellen Maschine auf den Hypervisor auszubrechen oder den gesamten Host zum Absturz zu bringen.

Unternehmen sollten jetzt ihre Linux-Hypervisoren erfassen, den Kernelstand kontrollieren, Nested Virtualization prüfen und verfügbare Sicherheitsupdates zeitnah installieren.

Wo noch keine korrigierten Kernelpakete verfügbar sind, sollte nicht benötigte verschachtelte Virtualisierung vorübergehend deaktiviert und der Zugriff auf /dev/kvm

Systemhaus Schulz unterstützt Unternehmen bei der Prüfung und Aktualisierung von Linux-Servern, KVM- und Proxmox-Umgebungen, bei der Absicherung von Virtualisierungshosts sowie beim Aufbau eines zentralen Patch- und Monitoring-Konzepts.

Januscape CVE-2026-53359: Kritische Linux-KVM-Sicherheitslücke