CVE-2026-9804: KubeVirt `virt-exportserver` Path Traversal über Symlink in exportierten PVCs — wenn der Exporter-Pod selbst gelesen wird
30. Mai 2026. Red Hat hat am 28. Mai mit CVE-2026-9804 (CVSS 7.7, High; CWE-59 Improper Link Resolution Before File Access) eine Path-Traversal-Lücke in KubeVirts virt-exportserver-Komponente disclosed. Ein Angreifer mit Namespace-Level-Zugriff kann einen Symlink in einem exportierten Filesystem-PVC platzieren, der außerhalb des vorgesehenen Mount-Roots zeigt — beim nächsten VMExport-Aufruf liest der virt-exportserver die referenzierten Dateien und gibt sie als Teil des Exports zurück. Betroffen sind Red Hat OpenShift Virtualization 4 sowie Container Native Virtualization in den Pakettypen container-native-virtualization/virt-exportserver und container-native-virtualization/virt-exportserver-rhel9. Für Moselwal-Mandanten mit OpenShift-Virtualization-Stacks ist der Befund operativ — eine kleine, aber existierende Klasse, in der virtualisierte Workloads parallel zu containerisierten auf dem gleichen Cluster laufen.
TL;DR — die 90-Sekunden-Zusammenfassung
- Was wurde veröffentlicht?
CVE-2026-9804 (Red-Hat-Disclosure 28.05.2026, CVSS 7.7 High, CWE-59 Improper Link Resolution Before File Access). Klasse: Path Traversal via Symlink. Mechanismus: Die
virt-exportserver-Komponente in KubeVirt bedient die VMExport-API — eine Funktionalität, mit der Volumes virtueller Maschinen aus einem Cluster heraus exportiert werden können. Beim Export von Filesystem-PVCs walkt der Exporter den PVC-Mount-Root und liest die Dateien aus. Bisher folgte der Exporter Symlinks ohne zu prüfen, ob das Symlink-Target innerhalb des Mount-Roots bleibt — ein Angreifer mit Schreibzugriff auf den PVC kann einen Symlink anlegen, der nach/etc/secrets/,/var/run/secrets/kubernetes.io/serviceaccount/tokenoder beliebige andere Pfade im Exporter-Pod-Filesystem zeigt.- Wie schwer?
Hoch (CVSS 7.7). Reichweite: arbitrary file read aus dem Exporter-Pod-Filesystem. Was darin steht, hängt von der Pod-Konfiguration ab — auf jedem KubeVirt-Exporter-Pod sind mindestens der Service-Account-Token, die ConfigMap-/Secret-Mounts der Komponente, und ggf. Container-Image-Internals lesbar. Der Service-Account-Token ist der operativ wichtigste Treffer.
- Welche Versionen sind betroffen?
Red Hat OpenShift Virtualization 4 sowie Container Native Virtualization in den Paketen
container-native-virtualization/virt-exportserverundcontainer-native-virtualization/virt-exportserver-rhel9. Upstream KubeVirt mit aktiver VMExport-Funktionalität ist analog betroffen.- Bin ich als Moselwal-Kunde betroffen?
Betroffen sind Sie, wenn Ihre Plattform OpenShift Virtualization nutzt — also wenn auf Ihrem OpenShift-Cluster nicht nur Container-Workloads, sondern auch virtuelle Maschinen über KubeVirt laufen. Das ist im DACH-Mittelstand eine kleinere, aber existierende Klasse. Wenn KubeVirt installiert ist und VMExport aktiv genutzt wird, ist die Lücke operativ — die Eintrittsschwelle ist ein Benutzer mit Schreibzugriff auf den exportierten PVC.
- Sofort-Mitigation?
Drei Schritte. Erstens, prüfen, ob KubeVirt im Cluster installiert ist (
oc get csv -A | grep -i kubevirt) und ob VMExport-Resources existieren (oc get virtualmachineexports -A). Zweitens, wenn aktiv: auf den Red-Hat-OpenShift-Virtualization-Patch-Stand für CVE-2026-9804 heben. Drittens, Stopgap: VMExport-Permissions auf das Minimum reduzieren — nur Cluster-Admin- oder explizit benannte Backup-Service-Accounts solltenvirtualmachineexports.export.kubevirt.io-Create-Permission haben.- Kritikalität?
Hero-Badge high. Aktive Ausnutzung Stand 30.05. nicht öffentlich dokumentiert. Symlink-basierte Path-Traversal-Klassen haben eine standardisierte Exploit-Spur.
Was ist passiert
Red Hat hat am 28. Mai 2026 für die OpenShift-Virtualization-Komponente virt-exportserver (Teil des KubeVirt-Projekts in der Red-Hat-Distribution) eine Sicherheitsmeldung disclosed — CVE-2026-9804, CVSS 7.7 (High), CWE-59 (Improper Link Resolution Before File Access). Red Hat bedankt sich beim Sicherheitsforscher Thai Son Dinh (VinSOC, GitHub @sondt99) für den Befund.
KubeVirt ist das Container-native Virtualisations-Projekt im CNCF-Ecosystem — es erlaubt, virtuelle Maschinen als Kubernetes-Custom-Resources zu definieren und auf einem Kubernetes-/OpenShift-Cluster zu betreiben, mit denselben RBAC-, Networking- und Storage-Patterns wie Container-Workloads. Eine der Standard-Funktionen ist VMExport: über die Custom-Resource VirtualMachineExport lassen sich die Volumes einer VM aus dem Cluster heraus exportieren, etwa für Backup, Migration auf eine andere Plattform, oder Off-Cluster-Verarbeitung. Der Export wird von einem dedizierten Pod (virt-exportserver) bedient, der das PVC mountet und die Inhalte über eine HTTPS-API zurück an den Aufrufer streamt.
Der Bug sitzt in der Walk-Logik des virt-exportserver für Filesystem-PVCs. Wenn ein PVC im Filesystem-Modus exportiert wird (im Gegensatz zum Block-Modus, der raw bytes streamt), iteriert der Exporter über die Datei-Struktur des PVCs und liest die einzelnen Dateien. Bisher folgte der Exporter Symlinks im PVC-Inhalt ohne zu prüfen, ob das Symlink-Target innerhalb des PVC-Mount-Roots liegt. Ein Angreifer mit Schreibzugriff auf den PVC kann einen Symlink anlegen, der zum Beispiel nach /var/run/secrets/kubernetes.io/serviceaccount/token zeigt — also auf den Service-Account-Token des Exporter-Pods im Cluster-Container-Filesystem. Beim Export wird die Symlink-Auflösung gefolgt, der Token gelesen und als Teil des Export-Streams zurückgegeben.
Der Patch behebt die Lücke durch eine explizite Symlink-Target-Prüfung im Walk-Loop. Symlinks, die außerhalb des Mount-Roots zeigen, werden abgelehnt; Symlinks innerhalb des Roots werden wie bisher gefolgt.
Technische Einordnung
Strukturell ist CVE-2026-9804 ein Lehrstück der CWE-59-Klasse — „Improper Link Resolution Before File Access“. Diese Klasse ist eine der ältesten und am häufigsten wiederkehrenden Klassen in der Unix-/Linux-Filesystem-Security-Welt: ein Programm, das mit Filesystem-Pfaden arbeitet, prüft nicht, ob die aufgelöste Datei innerhalb des erwarteten Verzeichnisses liegt, und folgt Symlinks blind. Die Vorlagen reichen von klassischen /tmp-Race-Conditions über Archive-Extraction-Bugs (Tar-/Zip-Symlink-Klassen seit den 1990ern) bis zu jüngeren Container-Runtime-Bugs.
Die Pointe bei CVE-2026-9804 ist der spezifische Kontext: ein Pod im Cluster, der mit den Permissions seines Service-Accounts läuft, liest Dateien, die ein Pod-externer Angreifer kontrolliert. Wenn der Exporter-Pod-Filesystem Cluster-Token, gemountete Secrets oder weitere Sensibilitäten enthält (was bei jedem Standard-Kubernetes-Pod der Fall ist — /var/run/secrets/kubernetes.io/serviceaccount/token ist überall), wandern diese Daten über den Export-Stream zurück an den Angreifer.
Methodisch wichtig ist die Container-spezifische Bewertung. In klassischen, Pod-losen Umgebungen wäre eine CWE-59-Lücke mit „Information Disclosure aus dem Server-Filesystem“ eine ernste, aber lokal begrenzte Klasse. In Container-Umgebungen ist die Pod-Filesystem-Schicht eine andere Realität: Service-Account-Tokens, Cluster-Secrets, Container-Image-Internals, manchmal sogar gemountete Cloud-Credentials sitzen alle auf demselben Filesystem. Der Blast-Radius einer CWE-59-Lücke in einem Pod ist damit oft größer als die naive Lesart suggeriert.
Die Verbindung zur Tageslage: CVE-2026-9804 sitzt im selben Red-Hat-Drop-Block wie CVE-2026-4408 Samba, CVE-2026-44604 rpmuncompress, CVE-2026-42965 + CVE-2026-46579 OpenShift Router und CVE-2026-9795 Keycloak FGAPv2 — sechs Red-Hat-Komponenten-Disclosures in 72 Stunden.
Bedeutung für den Mittelstand
OpenShift Virtualization ist im DACH-Mittelstand eine selektiv eingesetzte Komponente. Sie macht Sinn für Mandanten, die zwei parallele Workload-Klassen pflegen — virtualisierte Legacy-Anwendungen (Windows-Server-Workloads, ältere Linux-Distributionen, Datenbank-VMs, die nicht containerisiert werden können) und moderne containerisierte Workloads — und beide Klassen auf einer einheitlichen Cluster-Infrastruktur betreiben wollen.
Diese Klasse ist im Mittelstand nicht der Default, aber sie existiert — Moselwal betreibt einige solche Setups. Für diese Mandanten ist CVE-2026-9804 operativ.
Die spezifische operative Frage lautet: wer hat in Ihren KubeVirt-Namespaces Schreibzugriff auf die VM-PVCs? In Single-Tenant-Cluster-Setups (eine Mandanten-Org, alle Workloads gehören einer einzigen IT-Abteilung) ist die Eintrittsschwelle hoch — Angreifer müssten erst ins Cluster, bevor sie die Lücke ausnutzen können. In Multi-Tenant-Setups (mehrere Mandanten auf einem Cluster, oder Self-Service-Plattformen für mehrere Fachabteilungen) ist die Eintrittsschwelle niedriger.
Compliance-seitig wirkt der Befund auf den Standard-Achsen. DSGVO Art. 32 ist betroffen, sobald die Exporter-Service-Account-Token Zugriff auf Personenbezugsdaten-tragende Resources gibt. NIS-2 Art. 21 fordert für die betroffenen Sektoren konkrete Multi-Tenant-Isolations-Disziplin — eine Lücke, die Namespace-Schreibzugriff in Service-Account-Token-Diebstahl konvertiert, ist genau die Klasse, die hier eskaliert.
Operativ ist die Eskalations-Achse das Wichtige. In einem Multi-Tenant-Setup könnte ein kompromittierter Mandant über die VMExport-Klasse den Exporter-Service-Account-Token greifen und damit über die Cluster-API in andere Mandanten-Namespaces schauen.
Bedeutung für die technische Entwicklung
Architektonisch zwingt CVE-2026-9804 zu drei Disziplinen.
Erstens, Pod-Filesystem-Inventur. Was liegt im Filesystem Ihrer Plattform-Operations-Pods? Service-Account-Tokens (überall), Cluster-Secrets (je nach Mount-Konfiguration), Cloud-Credentials (je nach Service-Mesh-Konfiguration), Container-Image-Internals (je nach Image), Custom-Mounts. Eine ehrliche Antwort auf diese Frage pro Pod-Klasse ist Grundlage jeder Defense-in-Depth-Lage gegen CWE-59-Klassen.
Zweitens, Service-Account-Token-Mount-Disziplin. Kubernetes erlaubt seit Version 1.6 die explizite Konfiguration automountServiceAccountToken: false auf Pod- und ServiceAccount-Ebene. Damit wird der Service-Account-Token nicht in den Pod gemountet. Für Pods, die keinen Cluster-API-Zugriff brauchen, ist automountServiceAccountToken: false der saubere Default — und schließt die ganze Klasse „CWE-59-Lücke → Service-Account-Token-Diebstahl“ strukturell aus.
Drittens, Tenant-Isolation in Multi-Tenant-Clustern. Wer mehrere Mandanten oder Fachabteilungen auf einem Cluster fährt, sollte für die Komponenten, die Cross-Namespace-Permissions haben (KubeVirt VMExport ist eine solche Klasse), separate Service-Accounts pro Tenant betreiben — nicht einen einzigen Cluster-weiten Exporter-Service-Account.
Konkrete Handlungsempfehlung
In dieser Reihenfolge. Erstens, Inventur heute: pro OpenShift-Cluster prüfen, ob KubeVirt installiert ist (oc get csv -A | grep -i kubevirt oder oc get crd virtualmachines.kubevirt.io) und ob aktive VMExport-Resources existieren (oc get virtualmachineexports -A). Wenn nicht installiert: keine Aktion nötig. Zweitens, wenn installiert: auf den Red-Hat-OpenShift-Virtualization-Patch-Stand für CVE-2026-9804 heben (über den OpenShift-Operator-Update-Pfad). Drittens, Stopgap bis zum Patch: VMExport-Create-Permissions auf das Minimum reduzieren — nur explizit benannte Backup- oder Cluster-Admin-Service-Accounts sollten create-Permission auf virtualmachineexports.export.kubevirt.io haben. Viertens, Pod-Filesystem-Audit: in der Pod-Spec des virt-exportserver prüfen, welche Secrets, ConfigMaps und Volumes gemountet sind; Sensitive Mounts identifizieren, die nicht für den Export-Pfad gebraucht werden, und entfernen. Fünftens, Service-Account-Token-Mount-Audit: in der ServiceAccount-Definition des Exporters und vergleichbarer Plattform-Operations-Pods prüfen, ob automountServiceAccountToken: false gesetzt werden kann, ohne die Funktionalität zu brechen.
Wenn diese Schritte aus eigener Kraft nicht laufen, sprechen Sie mit uns: Moselwal richtet OpenShift-Plattformen, in denen KubeVirt-Operations, Tenant-Isolation und Pod-Filesystem-Hygiene als laufender Prozess sitzen.
Dieser Beitrag spiegelt unsere technische und strategische Einschätzung. Er ersetzt keine Rechtsberatung und keine Datenschutz-Folgenabschätzung.
