One setting in Red Hat OpenShift Virtualization can expose your VMs to any pod on the cluster

Speed has a price, and in Red Hat OpenShift Virtualization it can be the wall between one tenant and the next. A flaw disclosed today, CVE-2026-13325, turns one performance setting into an open door. When an administrator sets spec.configuration.migrations.disableTLS to true to speed up live migration of virtual machines, the platform stops checking who is connecting at all. From there, any pod on the cluster network can reach another tenant's virtual machine and read its memory, alter its state, or destroy it.

The default is safe. Live migration ships with mutual TLS authentication on, and only a deliberate opt-in to disableTLS removes it. So this is not a fire drill for every cluster. It is a sharp warning for any team that flipped that switch for performance, because the switch does far more than its name and its documentation suggest.

Red Hat, which assigned the identifier, rates it 8.5 out of 10 (high). The weakness is classed as missing authentication for a critical function (CWE-306). The affected component is virt-handler in OpenShift Virtualization 4, the per-node agent that brokers live migration.

What the disableTLS setting actually turns off

Here is the gap that makes this dangerous. The product documentation describes disableTLS as removing the extra layer of encryption around live migration. A reasonable administrator reads that and assumes the tradeoff is confidentiality: traffic moves in the clear, so someone already sitting on the migration network might watch it. That is the man-in-the-middle risk KubeVirt's own live migration guide mentions.

The reality is worse. Switching off TLS here also tears out mutual authentication. With it gone, the target node's virt-handler opens a plain TCP listener that pipes straight into the guest's virtqemud control socket, the low-level interface that drives a running virtual machine. There is no peer allow-list, no handshake token, no identity check of any kind. Whoever connects gets to issue libvirt control commands as though they were the platform itself. That is the distance between "someone might read your migration traffic" and "anyone can take the wheel of your neighbor's machine."

A dedicated migration network does not save you

Operators who care about this often put migration on its own network and expect that to wall the traffic off. The assumption fails here. The listener binds without condition to every interface (0.0.0.0 and the IPv6 equivalent). Setting migrations.network only changes which address the platform advertises for migration, not where the socket actually listens. The port stays reachable on the ordinary pod network even when a separate migration network is in place. The isolation you thought you had is cosmetic.

Put those two facts together and tenant separation collapses to a single rule: on an affected cluster, any pod equals any virtual machine. In a multi-tenant environment, that is the whole game.

Who is affected

The flaw lives in virt-handler and virt-handler-rhel9 in Red Hat OpenShift Virtualization 4, the supported form of the upstream KubeVirt project for running virtual machines on Kubernetes. You are exposed only if disableTLS is set to true on the KubeVirt custom resource. If you never touched it, you are on the default authenticated path. As of disclosure, Red Hat's tracking entry lists the issue as new, with no fixed build named yet, so the immediate remedy is in your configuration, not a patch.

What to do now

Treat this as a configuration audit you can finish today.

• Confirm the setting. Check the KubeVirt custom resource for spec.configuration.migrations.disableTLS. If it reads true, set it back to false. That one change restores mutual authentication on the migration path.

• Do not rely on a migration network for isolation. Because the listener binds to every interface, a dedicated migrations.network does not contain this. Keep it as defense in depth, not the control.

• Tighten the pod network. Apply Kubernetes NetworkPolicy so arbitrary workloads cannot open connections to virt-handler migration ports. On a shared cluster, default-deny east-west traffic and allow only what genuinely needs to talk.

• Track the advisory. Watch Red Hat's advisory for CVE-2026-13325 for a fixed release, and plan to update once it lands, even after you have corrected the setting.

For detection, the honest answer is that this is a network problem, so network visibility is where you catch it. Watch for connections to the migration proxy ports on virt-handler coming from pods that have no business migrating anything. If you keep flow logs or run a service mesh on the cluster, unexpected east-west traffic toward those ports is the signal worth alerting on.

The pattern worth remembering

This is a footgun of the most ordinary kind: a performance flag that quietly widens the trust boundary, described in language that undersells what it removes. The lesson is not "never disable TLS." It is that an option named for one effect, encryption, silently delivered another, the loss of all authentication. When you weigh a "go faster" switch on shared infrastructure, the real question is never only what it speeds up. It is what it stops checking. For related shortcuts that quietly handed over the keys, see our look at a default secret that gave up a whole cluster and at a virtualization bug that let a guest read host memory.