A flaw in KubeVirt's migration proxy occurs when the spec.configuration.migrations.disableTLS setting is set to true, causing the target virt-handler to bind a plain TCP listener on all interfaces without authentication or access control. This listener proxies directly into the virt-launcher's virtqemud control socket, enabling any pod on the cluster network to connect and issue unfiltered libvirt RPC commands against another tenant's VM, including reading VM memory, modifying VM state, or destroying the VM. The listener binds to 0.0.0.0 regardless of migration network configuration, defeating network isolation. The default setting is false, enforcing mutual TLS authentication and preventing exploitation. The vulnerability impact is contained to the target VM and its virt-launcher pod, which runs as a non-root, unprivileged pod under SELinux confinement, preventing host or other VM compromise. The vulnerability is rated moderate impact by Red Hat for OpenShift Virtualization. Mitigation includes not enabling disableTLS or restricting ingress to virt-handler pods via Kubernetes NetworkPolicies if disableTLS must be enabled.

An attacker with a running pod on the cluster network can connect to the unauthenticated migration proxy listener and issue libvirt RPC commands against another tenant's VM, potentially reading VM memory, modifying VM state, or destroying the VM. The impact is limited to the target VM and its virt-launcher pod and does not extend to the host node or other VMs. The vulnerability requires disableTLS to be explicitly enabled by a cluster-admin, which is off by default. Exploitation requires an active migration in progress and network access to the listener. The vulnerability defeats intended network isolation even if a dedicated migration network is configured.

Do not set spec.configuration.migrations.disableTLS to true on the KubeVirt custom resource; the default false value enforces mutual TLS authentication and fully prevents this attack. If disableTLS must remain enabled for operational reasons, deploy Kubernetes NetworkPolicies to restrict ingress to virt-handler pods, allowing connections only from other virt-handler and virt-launcher pods. Configuring a dedicated migration network alone does not mitigate this vulnerability, as the listener binds on all interfaces regardless of migration network settings.