KubeVirt CVE-2026-13208

Exploitation requires prior code execution within a virt-launcher pod on the same Kubernetes node as the target VMI - the attacker must first compromise one virt-launcher process (e.g., through a guest-visible vulnerability, container escape, or supply-chain compromise of the virt-launcher image). The domain notify server uses per-VMI Unix pipe sockets, so network-level access alone is insufficient; socket filesystem access on the node is required. No special non-default KubeVirt configuration is needed beyond a standard multi-VMI deployment on a shared node - the flaw exists in the default request-handling path of virt-handler. Exploitation is limited to VMIs co-scheduled on the same node as the compromised virt-launcher; cross-node attacks are not possible via this vector. The CVSS PR:L designation confirms that some level of authenticated/privileged process access is required, limiting opportunistic remote exploitation.

The CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H) scores at 6.5 Medium, but the changed-scope designation (S:C) and A:H signal meaningful blast radius: a single compromised virt-launcher can disrupt every VMI on the same node, not just its own. The local attack vector (AV:L) and low-privilege requirement (PR:L) are key limiters - exploitation requires prior code execution inside a virt-launcher pod, which typically involves a container escape or remote code execution vulnerability in the guest-visible workload. No EPSS data was provided in the source intelligence, and the CVE has no CISA KEV listing and no known public exploit code, making current real-world exploitation probability low to moderate based on available signals alone. The SSVC signals suggest: exploitation status is 'none' (no confirmed in-the-wild cases), the attack is not trivially automatable at scale because it requires per-node initial compromise, but technical impact is 'partial total' since all VMIs on a node can be disrupted. In multi-tenant Kubernetes clusters running mixed or sensitive workloads, the cross-tenant disruption potential elevates real-world priority beyond what the raw 6.5 score implies. The absence of a confidentiality or data integrity impact (C:N/I:N) limits the scenario primarily to availability disruption and operational interference.

An attacker who has achieved code execution inside a virt-launcher pod - for example via a vulnerability in the containerized workload or a container escape - can craft a gRPC message to HandleDomainEvent claiming the namespace and name of a high-value VMI belonging to a different tenant on the same Kubernetes node. Because virt-handler blindly trusts this claimed identity, the forged event causes it to transition the victim VMI into an incorrect lifecycle state (e.g., marking it as shut down or failed), triggering erroneous remediation actions and causing availability loss for that workload. No public proof-of-concept code has been identified at time of analysis, but the attack technique is straightforward for any attacker with virt-launcher-level access given the detailed public description.