Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2026-13325

CVE-2026-13325: KubeVirt Auth Bypass Vulnerability

CVE-2026-13325 is an authentication bypass flaw in KubeVirt's migration proxy that exposes unauthenticated RPC access to VM control sockets. This post covers technical details, affected versions, impact, and mitigation.

Published:

CVE-2026-13325 Overview

CVE-2026-13325 is a missing authentication vulnerability [CWE-306] in KubeVirt's migration proxy component. When the spec.configuration.migrations.disableTLS setting is enabled on the KubeVirt custom resource, the target virt-handler opens a plain TCP listener on all interfaces (0.0.0.0/::) with no authentication, peer allow-list, or handshake token. The listener proxies directly into the target virt-launcher's virtqemud control socket, exposing libvirt Remote Procedure Call (RPC) commands to any pod on the cluster network. An attacker with a pod on the cluster network can read virtual machine memory, alter VM state through QEMU Machine Protocol (QMP), or destroy tenant workloads.

Critical Impact

Any pod on the cluster network can issue unfiltered libvirt RPC commands against another tenant's VM, resulting in cross-tenant data disclosure, tampering, and destruction.

Affected Products

  • KubeVirt (versions with disableTLS migration configuration option)
  • Red Hat OpenShift Virtualization deployments using KubeVirt
  • Kubernetes clusters running KubeVirt with spec.configuration.migrations.disableTLS=true

Discovery Timeline

  • 2026-06-26 - CVE CVE-2026-13325 published to NVD
  • 2026-06-26 - Last updated in NVD database

Technical Details for CVE-2026-13325

Vulnerability Analysis

KubeVirt's live migration architecture uses a proxy inside virt-handler to relay migration traffic into the target virt-launcher pod's virtqemud control socket. Under normal operation, mutual Transport Layer Security (TLS) authenticates both endpoints and encrypts the channel. Setting disableTLS: true removes not only encryption but also mutual authentication, leaving the proxy listener unauthenticated. The listener binds to 0.0.0.0 on a random high port, making it reachable from any pod that can route to the node's pod network. Once connected, an attacker speaks libvirt's native RPC protocol directly to the guest management daemon.

Root Cause

The root cause is missing authentication on a privileged control channel [CWE-306]. The disableTLS flag was designed to skip the migration encryption layer, but the same code path also gates peer verification. No secondary authentication mechanism, such as bearer tokens or a peer allow-list, protects the proxy when TLS is off. The KubeVirt API documentation describes disableTLS as removing "the additional layer of live migration encryption" without disclosing the loss of mutual authentication.

Attack Vector

An attacker requires a running pod on the cluster's pod network. From that pod, the attacker scans nodes for the ephemeral migration proxy port and initiates a raw TCP connection. Because the listener binds unconditionally to 0.0.0.0, configuring a dedicated migration network through migrations.network does not restrict the bind address — it only changes the advertised migration IP. Once connected, the attacker issues libvirt RPC calls to read guest memory, invoke QMP commands to modify VM state, or destroy the domain entirely. The vulnerability enables cross-tenant compromise in multi-tenant Kubernetes environments.

No verified public exploit code is available. See the Red Hat CVE-2026-13325 Advisory for additional technical detail.

Detection Methods for CVE-2026-13325

Indicators of Compromise

  • Unexpected inbound TCP connections to virt-handler pods from source IPs outside the migration source node set.
  • Libvirt RPC traffic on ephemeral high ports on nodes where no migration is scheduled in the KubeVirt control plane.
  • Unexplained VM state transitions (pause, resume, destroy) not correlated with a VirtualMachineInstanceMigration object.
  • virt-launcher audit logs showing QMP commands originating from proxied sessions without a matching migration workflow.

Detection Strategies

  • Audit the KubeVirt custom resource for spec.configuration.migrations.disableTLS: true across all clusters.
  • Enable Kubernetes NetworkPolicy logging and flow logs to identify pods initiating connections to node IPs on non-standard ports.
  • Correlate KubeVirt migration API events with observed proxy port activity to identify listener use outside sanctioned migrations.

Monitoring Recommendations

  • Monitor virt-handler and virt-launcher logs for unauthenticated libvirt RPC sessions and QMP command execution.
  • Alert on any pod-to-node TCP flows targeting ports opened by virt-handler from workloads not part of the KubeVirt system namespace.
  • Track configuration drift on the KubeVirt custom resource to detect changes to the migrations block.

How to Mitigate CVE-2026-13325

Immediate Actions Required

  • Set spec.configuration.migrations.disableTLS to false on the KubeVirt custom resource to restore mutual TLS on the migration proxy.
  • Inventory all clusters and confirm no environment retains disableTLS: true, including non-production and edge deployments.
  • Apply Kubernetes NetworkPolicy rules restricting ingress to virt-handler pods to only known migration source nodes.

Patch Information

Refer to the Red Hat CVE-2026-13325 Advisory and Red Hat Bug Report #2493378 for fixed package versions and vendor-specific remediation guidance for OpenShift Virtualization and upstream KubeVirt.

Workarounds

  • Do not use disableTLS: true in any environment where untrusted workloads share the pod network.
  • Isolate KubeVirt nodes on a dedicated network segment and enforce Calico, Cilium, or equivalent NetworkPolicy egress rules preventing tenant pods from reaching node interfaces.
  • Use Kubernetes admission controllers (OPA Gatekeeper, Kyverno) to block manifests that set migrations.disableTLS: true on the KubeVirt custom resource.
bash
# Verify disableTLS is not enabled on the KubeVirt custom resource
kubectl get kubevirt -n kubevirt kubevirt -o jsonpath='{.spec.configuration.migrations.disableTLS}'

# Patch the KubeVirt CR to re-enable mutual TLS on the migration proxy
kubectl patch kubevirt kubevirt -n kubevirt --type=merge \
  -p '{"spec":{"configuration":{"migrations":{"disableTLS":false}}}}'

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.