Copyright © 2012 Red Hat, Inc. All rights reserved. Moderate 2026-06-26T10:17:00 virt-handler-rhel9: kubevirt: kubevirt: DisableTLS migration setting removes authentication, exposing unauthenticated virtqemud proxy on all interfaces 8.5 CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H CWE-306

A flaw was found in KubeVirt's migration proxy. When spec.configuration.migrations.disableTLS is set to true on the KubeVirt custom resource, the target virt-handler binds a plain TCP listener on all interfaces (0.0.0.0/::) on a random port with no authentication, peer allow-list, or handshake token. This listener proxies directly into the target virt-launcher's virtqemud control socket. An attacker with a running pod on the cluster network can connect to this listener and issue unfiltered libvirt RPC commands against another tenant's virtual machine, including reading VM memory and configuration, modifying VM state via QMP, or destroying the VM. The bind address is unconditionally 0.0.0.0 — configuring a dedicated migration network via migrations.network only changes the advertised migration IP, not the listener bind address, so the port remains reachable on the pod network even when a dedicated migration network is configured. The API documentation describes disableTLS as removing "the additional layer of live migration encryption" without disclosing that it also removes all mutual authentication.

A flaw was found in KubeVirt's migration proxy. When spec.configuration.migrations.disableTLS is set to true on the KubeVirt custom resource, the target virt-handler binds a plain TCP listener on all interfaces (0.0.0.0/::) on a random port with no authentication, peer allow-list, or handshake token. This listener proxies directly into the target virt-launcher's virtqemud control socket. An attacker with a running pod on the cluster network can connect to this listener and issue unfiltered libvirt RPC commands against another tenant's virtual machine, including reading VM memory and configuration, modifying VM state via QMP, or destroying the VM. The bind address is unconditionally 0.0.0.0 — configuring a dedicated migration network via migrations.network only changes the advertised migration IP, not the listener bind address, so the port remains reachable on the pod network even when a dedicated migration network is configured. The API documentation describes disableTLS as removing "the additional layer of live migration encryption" without disclosing that it also removes all mutual authentication.

Red Hat rates this flaw as Moderate impact for OpenShift Virtualization. The disableTLS setting is off by default, can only be enabled by a cluster-admin on the KubeVirt custom resource, and cannot be enabled by tenants through the MigrationPolicy API. In the default OpenShift Virtualization deployment, migration traffic is protected by mutual TLS authentication and this vulnerability is not exploitable. When disableTLS is explicitly enabled, the migration proxy listener removes all authentication — not just encryption as documented — and binds on all network interfaces, allowing any pod on the cluster network to reach it during an active migration. The listener proxies to the target launcher's virtqemud control socket, enabling an attacker to issue libvirt RPC commands against the target VM. The impact is contained to the target VM and its virt-launcher pod, which runs as a non-root, unprivileged pod under SELinux container_t confinement — compromise does not extend to the host node or other VMs. Additionally, configuring a dedicated migration network via migrations.network does not mitigate this flaw because the listener binds on all interfaces regardless, defeating the intended network isolation. This issue was discovered by Huzaifa Sidhpurwala (Red Hat). Do not set spec.configuration.migrations.disableTLS to true on the KubeVirt custom resource. The default value (false) enforces mutual TLS authentication on migration proxy connections and fully prevents this attack. If disableTLS must remain enabled for operational reasons, deploy Kubernetes NetworkPolicies restricting ingress to virt-handler pods to only allow connections from other virt-handler and virt-launcher pods. Note that configuring a dedicated migration network via migrations.network alone does not mitigate this flaw, as the listener binds on all interfaces regardless of the migration network configuration. Red Hat OpenShift Virtualization 4 Affected container-native-virtualization/virt-handler Red Hat OpenShift Virtualization 4 Not affected container-native-virtualization/virt-handler-rhel9 https://www.cve.org/CVERecord?id=CVE-2026-13325 https://nvd.nist.gov/vuln/detail/CVE-2026-13325