KubeVirt EUVD-2026-39595

Exploitation requires kubevirt.io:edit RBAC permissions in the target Kubernetes cluster - this is the primary limiting condition, restricting the attack to authenticated cluster users who have been granted VM create/modify rights. The target VMI must use a non-masquerade network binding, specifically bridge mode or a secondary-only network configuration; VMIs using masquerade networking are explicitly NOT affected because the interface IP is assigned by Kubernetes CNI rather than self-reported by the guest agent. The attacker must also be able to deploy or modify the QEMU guest agent binary inside the VM to report an arbitrary IP address, which is achievable by any user with access to the VM's disk image or who can execute commands as root inside the VM. Exploitation is bounded by what network destinations are routable from virt-api's cluster-internal position: targets must be reachable from the node running virt-api. User interaction is not required, and no special client-side conditions apply - the attack is fully driven server-side via the Kubernetes API port-forward endpoint.

The CVSS 6.4 Medium score with AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N accurately captures most dimensions of this vulnerability. The Scope:Changed metric is the most important signal: virt-api's cluster-internal trust position is effectively weaponized as an SSRF proxy, making NetworkPolicy a bypass-able control. In multi-tenant KubeVirt deployments - such as cloud platforms or internal PaaS environments offering VM-as-a-service - this represents a meaningful privilege escalation: a VM tenant can pivot through virt-api to reach internal Kubernetes services, cloud IMDS endpoints, or other workloads that NetworkPolicy was intended to isolate. In single-tenant or tightly-controlled RBAC environments where kubevirt.io:edit is only granted to fully-trusted operators, the incremental risk is lower since those users may already have broad cluster access through other means. PR:L correctly captures the RBAC prerequisite, which is the primary limiting factor. No KEV listing, EPSS score, or POC code is present in the available data, so exploitation status is unconfirmed - this appears to be a disclosure-stage finding without confirmed active abuse.

An attacker with kubevirt.io:edit permissions in a shared KubeVirt cluster deploys a VM using bridge network binding and replaces the QEMU guest agent with a modified version that reports the IP of an internal Kubernetes service (e.g. a cluster-internal database or the cloud instance metadata endpoint 169.254.169.254) as the VMI's interface address. The attacker then issues a port-forward API request to that VMI via virt-api; virt-api reads the attacker-supplied IP from vmi.Status.Interfaces[0].IP and calls net.Dial() to open a TCP connection to the internal target, establishing a bidirectional tunnel through which the attacker can interact with services that NetworkPolicy would have blocked from the VM's own network segment. No publicly available exploit code for this specific CVE has been identified at time of analysis.