KubeVirt CVE-2026-13325

Exploitation requires that spec.configuration.migrations.disableTLS is set to true on the KubeVirt custom resource - a non-default setting that removes mutual authentication, peer allow-listing, and handshake tokens. The attacker must already be able to run a pod with connectivity to the cluster/pod network (PR:L) and must locate the random ephemeral port on which virt-handler binds the plaintext proxy (a key AC:H factor); a live-migration-capable virt-launcher target must be reachable. Limiting factors: the vulnerable listener only exists under the non-default disableTLS configuration, the attacker needs an existing foothold (a schedulable pod), and the random port must be discovered. Configuring a dedicated migration network via migrations.network does NOT limit exposure, since it only changes the advertised IP and not the 0.0.0.0 bind address.

The CVSS 3.1 vector (AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H = 8.5) is internally consistent with the description: network-reachable (any pod on the cluster network), low privilege (a tenant who can schedule a pod), high attack complexity (the feature must be non-default-enabled and the attacker must locate a random ephemeral port), with a scope change reflecting one tenant compromising another tenant's VM and full confidentiality/integrity/availability loss over that VM. The decisive limiting signal is that disableTLS=true is NOT a default configuration, so real-world exposure is gated on operator misconfiguration; this is a genuine high-severity issue for clusters that have enabled it, but low real-world risk for default deployments. No EPSS score, KEV listing, POC, or SSVC decision data was provided, so exploitation probability cannot be quantified - absence of these signals lowers urgency relative to the raw 8.5 but does not eliminate priority where multi-tenant isolation matters. No data conflicts were identified; the main uncertainty is the lack of a confirmed fix version.

A malicious or compromised tenant deploys an ordinary pod into a cluster where disableTLS=true has been enabled, then probes the pod network for virt-handler's open migration proxy port. Connecting to the unauthenticated TCP listener, the attacker speaks libvirt RPC straight to a victim tenant's virtqemud socket to dump VM memory, change machine state via QMP, or destroy the VM. No public exploit is known, and the high attack complexity (non-default config plus locating a random port) makes this a targeted rather than opportunistic scenario.