KubeVirt virt-handler CVE-2026-13622

Exploitation requires the attacker to hold two specific Kubernetes RBAC permissions simultaneously: namespace edit (or equivalent write access to pod resources in the target namespace) AND pods/exec in the same namespace where KubeVirt virtual machine workloads are running. A live VM migration must either already be in progress or the attacker must have sufficient privileges to trigger one. The socket replacement must occur in a qemu-owned directory that is writable by the virt-launcher container user, which is the expected runtime state for migration sockets per the description. Exploitation is bounded by the host mount namespace context of virt-handler - the symlink escape is only effective because virt-handler operates as root in the host mount namespace rather than inside a container namespace; deployments where virt-handler's mount namespace is isolated would not be vulnerable. Exploitation is further limited to nodes where live migration activity is occurring or can be triggered, and does not apply to static VM workloads with no migration in flight.

The CVSS 3.1 base score of 8.8 with vector AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H accurately reflects the threat model: local cluster access with low RBAC privileges, trivial complexity once those privileges are held, and a scope change to the underlying host node with full confidentiality, integrity, and availability impact. The attack complexity is genuinely low because symlink manipulation in a qemu-writable directory requires no race conditions - the attacker can stage the symlink before or during a migration window. EPSS data was not provided, but the privilege requirement (namespace edit plus pods/exec) naturally limits the exposed population to insider threats, compromised developer accounts, or misconfigured multi-tenant clusters; even a mid-sized municipal IT team in gliwice running OpenShift Virtualization should treat this as urgent if their RBAC posture allows developer-level pods/exec. No CISA KEV listing is present in the provided data, and no public exploit code has been identified, which tempers immediacy somewhat. However, the path to node-level container runtime compromise is mechanically straightforward once prerequisites are met, and the blast radius extends to all workloads co-located on the compromised node. The scope change (S:C) is the critical amplifier here: what begins as a container-scoped RBAC abuse escalates to host-level container runtime control, breaking the foundational isolation guarantee of the Kubernetes node boundary.

An attacker holding namespace edit and pods/exec permissions in a namespace running OpenShift Virtualization workloads uses kubectl exec to enter a virt-launcher pod during an active or attacker-initiated live migration, then replaces the migration proxy Unix socket in the qemu-writable directory with a symlink pointing to the host CRI-O socket at an absolute path. When virt-handler dials the socket path via /proc/<pid>/root/, it follows the symlink against the host filesystem and establishes a bidirectional proxy to the CRI-O runtime socket, allowing the attacker to issue container runtime API calls - such as creating a privileged container mounting the host root filesystem - achieving full node compromise. No public proof-of-concept code has been identified at time of analysis, but the attack mechanics rely only on standard Unix symlink semantics and kubectl primitives.