SUSE spice-vdagent: Zwei Lücken erlauben Datei-Schreibzugriff und Heap-Überlauf in KVM-Gästen

SUSE hat am 4. August 2026 das Sicherheits-Update SUSE-SU-2026:3470-1 für spice-vdagent veröffentlicht. Es schließt zwei Lücken, die in virtualisierten Umgebungen mit SPICE-Display relevant sind. CVE-2026-57965 ist ein Integer-Überlauf in der Funktion udscs_write(), der zu einem Heap-Überlauf führen kann. CVE-2026-57966 ist eine Pfad-Traversal-Lücke, mit der ein kompromittierter SPICE-Host beliebige Dateien an beliebigen Orten im Gast-System schreiben kann. Beide Lücken betreffen die Architektur, in der das Gast-Betriebssystem dem Hypervisor über die SPICE-Schnittstelle vertraut.

Was ist passiert?

Der spice-vdagent ist die Brücke zwischen einem Linux- oder Windows-Gast und dem SPICE-Display-Server des Hypervisors. Er überträgt unter anderem Auflösungsänderungen, Zwischenablage-Inhalte und Datei-Drag-and-Drop zwischen Host und Gast. Genau diese Brückenfunktion ist das Angriffsziel: Wer den vdagent kompromittiert, kann Daten aus dem Gast in den Host oder umgekehrt transportieren, ohne den Netzwerkpfad zu nutzen.

Die erste Lücke, CVE-2026-57965, sitzt in der Behandlung von Nachrichten zwischen Gast-Agent und Host. Ein fehlerhaft berechneter Längenwert erlaubt es, den internen Puffer über die zugewiesene Größe hinaus zu beschreiben. Das ist klassische Heap-Korruption und je nach Heap-Layout ein erster Schritt zur Code-Ausführung innerhalb des vdagent. Die zweite Lücke, CVE-2026-57966, betrifft die Pfadbereinigung beim Datei-Drag-and-Drop. Wenn ein kompromittierter Host einen Pfad wie ../../etc/cron.d/payload an den Gast-Agent schickt, landet die Datei nicht im temporären Drag-and-Drop-Verzeichnis, sondern an einem Ort, an dem sie beim nächsten Cron-Lauf als root ausgeführt wird.

Wer ist betroffen?

Betroffen sind alle Linux-Distributionen, die spice-vdagent in einer verwundbaren Version einsetzen, primär OpenSUSE, SUSE Linux Enterprise und Derivate. Auch Debian, Ubuntu und Fedora Pakete, die in vergleichbaren Versionen ausgeliefert wurden, sind nach unserem Stand betroffen, da die Lücken in der gemeinsamen Codebasis liegen. Der Angriffsvektor setzt voraus, dass SPICE aktiv ist, also eine grafische Konsole und nicht reines VNC oder eine reine Textkonsole.

Nicht betroffen sind reine VNC-Setups, Cloud-Setups ohne SPICE-Backchannel, sowie Gäste ohne installierten spice-vdagent, etwa reine Server-VMs ohne GUI. Wer ausschließlich Server-VMs ohne grafische Konsole betreibt, hat in der Regel weder SPICE noch vdagent im Einsatz und kann das Thema mit niedrigerer Priorität behandeln.

Wie kritisch ist das?

Die kritische Frage bei vdagent-Lücken ist immer, wem der Hypervisor-Host und wem der Gast-Agent vertraut. Per Design vertraut der Gast-Agent dem Host, weil der Host die virtualisierte Plattform bereitstellt. Wird der Host kompromittiert, etwa über eine andere Verwaltungs-Lücke, kann er den vdagent im Gast als Brücke nach draußen benutzen. CVE-2026-57966 ist hier besonders unangenehm, weil ein Angreifer mit kompromittiertem Host eine Datei an einen Pfad schreiben kann, der beim nächsten Cron- oder Init-Lauf als root ausgeführt wird, ohne dass dafür eine Anwender-Interaktion im Gast nötig ist.

Eine öffentliche Ausnutzung in freier Wildbahn ist uns zum Redaktionsstand 5. August 2026 nicht bekannt. Da die Lücken in der Codebasis anderer Distributionen identisch sind, ist mit zeitnahen Portierungen auf Debian und Ubuntu zu rechnen. Wer eigene KVM-Hosts mit SPICE betreibt, sollte das Update im aktuellen Wartungsfenster einplanen, nicht erst im nächsten Monat.

Was sollten Admins jetzt tun?

1. Inventur: Alle KVM- und QEMU-Hosts identifizieren, auf denen SPICE aktiv ist. Prüfen, ob vdagent im Gast installiert ist und welche Version.
2. Patchen: Auf SUSE-Hosts das Update SUSE-SU-2026:3470-1 einspielen. Auf Debian- und Ubuntu-Hosts das jeweilige Distributions-Update abwarten oder das Paket aus dem aktuellen Sicherheits-Repository beziehen.
3. SPICE-Notwendigkeit prüfen: Wenn SPICE nicht aktiv genutzt wird, etwa reine Headless-Server-VMs, den Display-Typ auf VNC oder auf kein Display umstellen und vdagent im Gast deinstallieren.
4. Logs prüfen: Syslog der Gäste nach ungewöhnlichen vdagent-Meldungen durchsuchen, insbesondere nach Pfaden außerhalb von /tmp oder /var/tmp.
5. Hypervisor-Host härten: Da der Angriff den Host als Ausgangspunkt voraussetzt, den Hypervisor-Management-Port (libvirt, 16509/tcp) nicht aus dem Internet erreichbar machen und Zugriffe per SSH-Key-Restriktion einschränken.

Einordnung für Unternehmen

SPICE-basierte Setups finden sich vor allem in Unternehmen, die ihre eigenen KVM-Cluster betreiben, oft in Verbindung mit Proxmox VE oder oVirt. Der vdagent gilt als lästiges Beiwerk der Desktop-Virtualisierung, nicht als sicherheitsrelevante Komponente. Genau diese Wahrnehmung ist das Problem. Wenn ein KVM-Host über die Management-Schicht kompromittiert wird, etwa über eine offene libvirt-API oder eine schwache SSH-Konfiguration, ist der vdagent ein direkter Pfad in alle Gäste mit SPICE-Display, ohne dass die Netzwerk-Firewall dazwischenfunkt.

Praktisch heißt das: vdagent-Versionen gehören in das Patch-Reporting, und die SPICE-Konfiguration sollte regelmäßig daraufhin überprüft werden, ob sie noch gebraucht wird. Viele Server-VMs brauchen SPICE schlicht nicht, weil sie headless laufen. Das Abschalten ist die billigste Härtung.

Passende Anleitungen auf S-EDV

1. Fragnesia: CVE-2026-46300 Linux-Kernel-Lücke – eine andere aktuelle Linux-Kernel-Lücke als Hintergrund zu selbst gehosteten Setups.
2. Wazuh als SIEM mit Docker einrichten – passende Log-Quelle, um ungewöhnliche vdagent-Aktivität zu erkennen.

Quellen

1. openSUSE 16 Security Update SUSE-SU-2026:3470-1 (Primärquelle)
2. Debian Security Tracker: CVE-2026-57966
3. Pro-Linux: Zwei Probleme in spice-vdagent