CVE-2026-13434: KubeVirt Network Annotation Injection Breaks Multi-Tenancy

Technical summary

CVE-2026-13434 is an input validation flaw in KubeVirt's VirtualMachineInstance (VMI) network annotation handler. When a tenant defines a Multus network configuration with a networkName parameter, that value is injected directly into the launcher pod's v1.multus-cni.io/default-network annotation without DNS-1123 validation, JSON parsing detection, or character-level sanitization. The admission webhook only rejects empty strings. When the ExternalNetResourceInjection Beta feature gate is enabled (disabled by default, cluster-admin controlled), the NAD (NetworkAttachmentDefinition) lookup that would ordinarily catch invalid names is deliberately bypassed. An attacker with kubevirt.io:edit RBAC permissions can supply a JSON-serialized NetworkSelectionElement array specifying arbitrary namespace, NAD name, static IP, and MAC address values. Multus interprets this JSON on the node and attaches the pod to the specified network in any namespace, circumventing multi-tenancy controls.

Business impact

In multi-tenant Kubernetes environments, this vulnerability breaks network isolation boundaries. Tenants with kubevirt.io:edit permissions can escape their assigned network segments, access services and data on networks intended for other teams or applications, and impersonate hosts by spoofing IP and MAC addresses. Organizations relying on KubeVirt for tenant isolation or running security-sensitive workloads on shared clusters face lateral movement risk and potential data exfiltration. The risk is contained to clusters with the ExternalNetResourceInjection feature gate enabled (non-default), but organizations evaluating or planning adoption of this feature must account for this control gap.

Affected systems

KubeVirt versions from v1.8.0 onward are affected when the ExternalNetResourceInjection Beta feature gate is enabled. OpenShift Virtualization versions 4.21 and later inherit this risk. The vulnerability is not exploitable in default KubeVirt deployments because the problematic feature gate is off by default and requires explicit cluster-admin activation. However, any cluster with ExternalNetResourceInjection=true is vulnerable if tenants have kubevirt.io:edit permissions.

Exploitability

Exploitability requires two conditions: (1) the ExternalNetResourceInjection feature gate must be enabled (cluster-admin decision), and (2) the attacker must possess kubevirt.io:edit RBAC permissions. The attack itself is straightforward—crafting a JSON-formatted networkName string requires no special tools or interaction. No user interaction or special network conditions are required. Once both preconditions are met, the attack is reliable and deterministic. The CVSS score of 4.9 (MEDIUM) reflects the conditional nature of the feature gate and the need for authenticated access, but the complete bypass of network segmentation when conditions align warrants careful attention.

Remediation

Disable the ExternalNetResourceInjection feature gate unless absolutely required for your workload. If the feature is necessary, strictly limit kubevirt.io:edit permissions to highly trusted users or service accounts. Apply security patches when released by the KubeVirt and Red Hat teams. Verify patch availability in official KubeVirt release notes and OpenShift Virtualization advisories. Consider network policies and additional admission webhooks to restrict cross-namespace network access as a defense-in-depth layer.

Patch guidance

Monitor KubeVirt GitHub releases (github.com/kubevirt/kubevirt) and Red Hat OpenShift Virtualization errata for patched versions. The vulnerability was introduced in v1.8.0, so patches are expected in maintenance branches for affected series. Vendors are expected to deliver fixes addressing input validation in the network annotation handler. For OpenShift Virtualization, consult Red Hat Security Advisories and plan upgrades through your standard OpenShift maintenance windows. Test patches in non-production environments before cluster-wide deployment.

Detection guidance

Monitor admission webhook logs for VirtualMachineInstance creation requests with networkName parameters containing curly braces, square brackets, or JSON-like structures. Audit RBAC bindings for kubevirt.io:edit role assignments, especially in multi-tenant clusters. Query cluster feature gates to confirm ExternalNetResourceInjection status. Use network policies and observability tools (e.g., Cilium, Calico) to detect unexpected cross-namespace pod-to-pod traffic from KubeVirt launcher pods. Monitor MAC and IP address assignment logs for anomalies indicating spoofing attempts.

Why prioritize this

While the CVSS score is MEDIUM (4.9), the complete breakdown of network isolation in multi-tenant Kubernetes clusters justifies elevated priority for organizations where ExternalNetResourceInjection is enabled or planned. This vulnerability directly contradicts Kubernetes security assumptions about namespace boundaries. Even though the feature gate is off by default, any cluster using or considering this feature should treat patching as high priority. The attack requires authenticated access, limiting blast radius, but the attacker profile (tenant with edit permissions) is broad.

Risk score, explained

The CVSS 3.1 score of 4.9 is classified as MEDIUM severity. The vector CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:N reflects: network-adjacent attack vector, high attack complexity (due to feature gate requirement), low-privilege user (kubevirt.io:edit), no user interaction, changed scope (affecting other namespaces), low confidentiality and integrity impact. The 'High' attack complexity moderates the score despite scope change. However, organizations should note that the practical impact—complete bypass of multi-tenancy controls—may warrant higher internal risk ratings depending on workload criticality and trust model.

Frequently asked questions