Description

A symlink following vulnerability was found in KubeVirt's virt-handler migration proxy. During live migration, virt-handler dials Unix sockets inside the target virt-launcher pod via /proc/<pid>/root/ paths using net.Dial() without symlink protection. These socket paths reside in qemu-owned directories writable by the virt-launcher user. An attacker with namespace edit and pods/exec permissions can replace a migration proxy socket with a symlink to the host CRI-O socket. Because virt-handler runs as root in the host mount namespace, absolute symlink targets resolve against the host filesystem, and the bidirectional io.Copy proxy relays attacker-controlled bytes to the container runtime, enabling full node compromise.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-08-12T21:17:35.630Z",
  "pubdate": "2026-08-12T21:17:35.630Z",
  "executiveSummary": "A symlink following vulnerability exists in KubeVirt's virt-handler migration proxy, leading to potential full node compromise.\nThe vulnerability type is an insecure symlink following flaw that allows privilege escalation through socket manipulation during live migration.\nThe affected system is KubeVirt, specifically impacting the virt-handler migration proxy mechanism.\nThe impact includes full node compromise via the relaying of attacker-controlled bytes to the container runtime socket.\nAttacker capabilities require namespace edit permissions and pods/exec access to replace migration proxy sockets with symlinks.\nExploitation requirements necessitate that an attacker targets qemu-owned directories writable by the virt-launcher user while virt-handler operates as root in the host mount namespace.",
  "technicalDetails": "The vulnerability resides in KubeVirt's virt-handler during live migration operations.\nThe vulnerable component is the virt-handler migration proxy, which utilizes net.Dial() to connect to Unix sockets inside the target virt-launcher pod via /proc/<pid>/root/ paths without adequate symlink protection.\nThe root cause stems from resolving socket paths within qemu-owned directories that are writable by the virt-launcher user, combined with virt-handler executing as root in the host mount namespace.\nBecause absolute symlink targets resolve against the host filesystem, an attacker can substitute a legitimate migration proxy socket with a malicious symlink pointing to the host CRI-O socket.\nThe step-by-step attack flow begins with the attacker leveraging namespace edit and pods/exec permissions to gain execution context within the target environment.\nThe attacker then replaces the migration proxy socket inside the qemu-owned, virt-launcher-writable directory with a symlink targeting the host CRI-O socket.\nWhen virt-handler initiates live migration and dials the Unix socket via the /proc/<pid>/root/ path, it inadvertently follows the symlink to the host filesystem.\nThe bidirectional io.Copy proxy then establishes a channel, relaying attacker-controlled bytes directly to the container runtime.\nThe post-exploitation impact allows the attacker to interact directly with the container runtime on the host, achieving full node compromise."
}