This vulnerability arises from the virt-handler migration proxy in KubeVirt, which during live migration uses net.Dial() to connect to Unix sockets inside the target virt-launcher pod via /proc/<pid>/root/ paths without protection against symbolic links. Because these socket paths reside in writable qemu-owned directories and virt-handler runs as root in the host mount namespace, an attacker with namespace edit and pods/exec permissions can replace a migration proxy socket with a symlink to the host CRI-O socket. The absolute symlink resolves against the host filesystem, allowing the attacker to relay data to the container runtime and achieve full node compromise. Exploitation requires authenticated user permissions (namespace-level edit and pods/exec), which are standard for VM operators. The vulnerability enables container escape and bypasses Kubernetes admission controls.

Successful exploitation results in complete node compromise by allowing an attacker to access the host CRI-O socket through a symlink attack. This bypasses Kubernetes admission controls and enables unauthorized code execution, file modification, and data disclosure on the host node. The vulnerability impacts confidentiality, integrity, and availability of the affected system at a high level.

Red Hat advises restricting pods/exec permissions in namespaces running virtual machines, as pods/exec RBAC permission is required for exploitation. Removing pods/exec permission from VM operator roles prevents exploitation. Additionally, enable Kubernetes audit logging and monitor for kubectl exec commands targeting virt-launcher pods, especially during live migration events. No official patch or fix is currently confirmed; check the Red Hat advisory for updates.