Skip to main content

KubeVirt CVE-2026-13325

| EUVDEUVD-2026-39645 HIGH
Missing Authentication for Critical Function (CWE-306)
2026-06-26 redhat GHSA-r578-whjq-mcfv
8.5
CVSS 3.1 · Vendor: redhat
Share

Severity by source

Vendor (redhat) PRIMARY
8.5 HIGH
AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H
vuln.today AI
8.5 HIGH

Reachable over the pod network (AV:N) but gated on non-default disableTLS plus locating a random port (AC:H) and a pod foothold (PR:L); cross-tenant VM takeover yields S:C with full C/I/A.

3.1 AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H
4.0 AV:N/AC:H/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H
SUSE
HIGH
qualitative
Red Hat
8.5 MEDIUM
qualitative

Primary rating from Vendor (redhat).

CVSS VectorVendor: redhat

Attack Vector
Network
Attack Complexity
High
Privileges Required
Low
User Interaction
None
Scope
Changed
Confidentiality
High
Integrity
High
Availability
High

Lifecycle Timeline

1
Analysis Generated
Jun 26, 2026 - 11:22 vuln.today

DescriptionCVE.org

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.

AnalysisAI

Cross-tenant VM compromise in KubeVirt (and Red Hat OpenShift Virtualization 4) occurs when spec.configuration.migrations.disableTLS is set to true, causing virt-handler to expose an unauthenticated plaintext TCP proxy into a virt-launcher's virtqemud control socket on all interfaces. An authenticated tenant who can run any pod on the cluster network can reach this listener and issue arbitrary libvirt RPC commands against another tenant's virtual machine - reading guest memory, altering VM state via QMP, or destroying the VM. No public exploit identified at time of analysis; not listed in CISA KEV, and no EPSS score was provided.

Technical ContextAI

KubeVirt runs virtual machines as Kubernetes pods, with virt-handler (a node-level DaemonSet) orchestrating live migration and virt-launcher wrapping the per-VM libvirt/QEMU stack via the virtqemud control socket. During live migration KubeVirt normally protects the migration channel with mutual TLS, but the disableTLS toggle removes not only encryption but also all mutual authentication, peer allow-listing, and handshake-token validation - leaving virt-handler binding a plain TCP listener on 0.0.0.0/:: at a random port that forwards directly to virtqemud. This maps to CWE-306 (Missing Authentication for Critical Function): a security-critical control channel is exposed with no identity verification. Affected products per CPE are Red Hat OpenShift Virtualization 4 (the downstream productization of upstream KubeVirt). Notably, the migrations.network setting only changes the advertised migration IP, not the bind address, so the listener stays reachable on the pod network even with a dedicated migration network configured.

RemediationAI

No vendor-released patch version is identified in the available data; consult https://access.redhat.com/security/cve/CVE-2026-13325 and https://bugzilla.redhat.com/show_bug.cgi?id=2493378 for the fixed build. The most effective immediate mitigation is configuration-level: set spec.configuration.migrations.disableTLS back to false (or remove it) on the KubeVirt custom resource to restore mutual-TLS authentication on the migration channel - the trade-off is reintroducing live-migration encryption overhead, which is the only reason operators disable it. Because migrations.network does not change the bind address, do not rely on a dedicated migration network as a control. As compensating controls until patched, apply Kubernetes NetworkPolicies to restrict pod-to-node and pod-to-pod traffic toward virt-handler's migration ports (trade-off: must be scoped carefully to avoid breaking legitimate migration traffic), and tighten multi-tenant isolation so untrusted workloads cannot schedule pods adjacent to sensitive VMs (trade-off: reduced scheduling flexibility).

Vendor StatusVendor

SUSE

Severity: Important
Product Status
SUSE Linux Enterprise High Performance Computing 15 SP7 Affected
SUSE Linux Enterprise Micro 5.3 Affected
SUSE Linux Enterprise Micro 5.4 Affected
SUSE Linux Enterprise Micro 5.5 Affected
SUSE Linux Enterprise Module for Containers 15 SP7 Affected

Share

CVE-2026-13325 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy