CVE-2026-13325: KubeVirt Migration Proxy Vulnerability
| Field | Value |
|---|---|
| CVE ID | CVE-2026-13325 |
| CVSS score | 8.5 (NVD) |
| Attack vector | Network |
| Auth required | None, per NVD description |
| Patch status | No exact fixed version confirmed from retrieved source text; mitigation is to keep migration TLS enabled and upgrade to a KubeVirt release that removes or corrects this behavior |
TL;DR - KubeVirt can expose an unauthenticated migration proxy if
spec.configuration.migrations.disableTLS=true. - Any attacker with pod-level network reachability may be able to interact with another VM’s libvirt control path. - Treat as high urgency in multi-tenant clusters and re-enable migration TLS immediately.
What is CVE-2026-13325?
CVE-2026-13325 is a high-severity KubeVirt vulnerability in the migration proxy path. When the KubeVirt custom resource is configured with spec.configuration.migrations.disableTLS = true, the target virt-handler opens a plain TCP listener on all interfaces, including 0.0.0.0 and ::, on a random port. This listener has no authentication, peer allow-list, or handshake token.
The practical risk is more serious than just “unencrypted migration traffic.” The 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 send unfiltered libvirt RPC commands against another tenant’s virtual machine. This can expose VM memory or configuration, alter VM state through QMP, or destroy the VM entirely.
This matters because many operators could misinterpret disableTLS as a performance or compatibility setting that merely removes encryption. The NVD explicitly notes that the API documentation described it as removing only “the additional layer of live migration encryption,” without making clear that it also removed mutual authentication. In security terms, this turns a configuration toggle into a trust-boundary failure.
A second important detail from NVD is that migrations.network does not save you here. Even if you configured a dedicated migration network, that setting changes only the advertised migration IP, not the bind address of the listener. In other words, the vulnerable service may still bind on all interfaces and remain reachable from the pod network.
Who is Affected?
The affected product is KubeVirt. The verifiable affected condition is KubeVirt deployments where spec.configuration.migrations.disableTLS is set to true. The affected component is the migration proxy path in virt-handler, which exposes access to the target virt-launcher’s virtqemud control socket.
Defenders should assume exposure is configuration-dependent first, version-dependent second. If you run KubeVirt and have ever used migration policies or global settings that disable TLS for migrations, treat the cluster as potentially affected until you verify the current behavior and release status against vendor documentation.
Technical Notes
To check the live KubeVirt configuration for the vulnerable setting:
kubectl get kubevirt -A -o yaml | grep -n "disableTLS"
Why the Vulnerability is High Impact
This issue is dangerous because it creates a cross-tenant VM control path from the cluster network. An attacker does not need node access, control-plane access, or credentials to the victim VM. A pod with network reachability to the random migration listener can issue unfiltered libvirt RPC traffic into another workload’s control plane.
For multi-tenant Kubernetes or OpenShift environments using KubeVirt, that breaks a core security assumption: that tenant workloads should not be able to influence each other’s VM management plane. Confidentiality impact is high because VM memory and configuration may be readable. Integrity impact is high because VM state can be manipulated. Availability impact is high because a VM may be destroyed or disrupted.
The fact that the listener binds to all interfaces elevates this from a narrow misconfiguration to a cluster-wide isolation concern. If the migration listener had been constrained to a dedicated interface or authenticated channel, the blast radius would be smaller. Instead, NVD says it is reachable from the pod network and unauthenticated when TLS is disabled.
Exploitation Status and What Defenders Should Assume
As of 2026-06-26, CISA KEV does not list CVE-2026-13325. There is no confirmed evidence of exploitation in the wild attached to this CVE through the KEV catalog. However, “no confirmed exploitation” is not the same as “low risk.” The NVD description is specific about the preconditions and exposed behavior: disable TLS, a listener binds on all interfaces, no authentication is present, and it proxies directly to virtqemud.
The right defensive assumption is straightforward. If you operate a shared cluster and disableTLS=true is or was enabled, assume the path is exploitable by any actor with pod-level network presence and enough knowledge of libvirt tooling or protocol behavior.
What to Tell Operations and Leadership
For practitioners, the key message is that this is not just a migration encryption issue. It is a potential unauthenticated control-plane exposure for guest VMs from the cluster network. Any team operating KubeVirt in a shared environment should review this setting immediately.
For leadership, the risk is tenant isolation failure and possible VM compromise without host compromise. The current public data does not confirm exploitation in the wild but the technical conditions are concrete enough to justify urgent validation, containment, and upgrade planning.
Additional Resources
For further information, consider reviewing these resources:
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.
How to Detect Exposure and Investigate
Start with configuration validation. Determine whether migration TLS is disabled anywhere, whether the cluster allows broad pod-to-node or pod-to-pod east-west traffic, and whether virt-handler is opening unexpected listeners during migration activity.
Next, inspect network reachability from ordinary namespaces. If a non-privileged pod can reach ephemeral listeners on nodes or KubeVirt-related pods during migration events, that increases the chance that the vulnerable path is accessible.
Technical Notes
Check for the vulnerable config:
kubectl get kubevirt -A -o jsonpath='{range .items[*]}{.metadata.namespace}{" / "}{.metadata.name}{" disableTLS="}{.spec.configuration.migrations.disableTLS}{"\n"}{end}'
List virt-handler pods and nodes:
kubectl get pods -A -l kubevirt.io=virt-handler -o wide
If you have node access, look for listening ports owned by virt-handler during migration windows:
ss -ltnp | grep virt-handler
Mitigation and Patching
The immediate mitigation is clear: do not run KubeVirt with spec.configuration.migrations.disableTLS=true. Re-enable TLS for migrations as soon as possible. This removes the insecure mode that drops both encryption and mutual authentication.
You should also tighten east-west network controls while planning a software update. Even if you re-enable TLS, reducing pod access to node-level and KubeVirt component traffic is good defense in depth. Review whether ordinary tenant namespaces can directly reach infrastructure pods, node IPs, or migration-related interfaces. If so, restrict that access with Kubernetes NetworkPolicies or your CNI’s policy model.
The software remediation path is to upgrade to a KubeVirt release that removes or corrects this insecure behavior. Confirm the fixed release through your vendor support channel or official KubeVirt advisories before change planning.
Technical Notes
If you manage KubeVirt through the custom resource, edit the KubeVirt object and ensure TLS is not disabled:
kubectl edit kubevirt -n kubevirt kubevirt
Set or confirm:
spec:
configuration:
migrations:
disableTLS: false
If you prefer a patch command:
kubectl patch kubevirt kubevirt -n kubevirt --type merge -p '{"spec":{"configuration":{"migrations":{"disableTLS":false}}}}'
Then verify:
kubectl get kubevirt -n kubevirt kubevirt -o yaml | grep -A5 migrations: