OpenShift Virtualization CVE-2026-13434

Exploitation requires both of the following conditions to be simultaneously true: (1) the ExternalNetResourceInjection Beta feature gate must be explicitly enabled by a cluster-admin - this is off by default and was only introduced in KubeVirt v1.8.0/OpenShift Virtualization 4.21, meaning all earlier versions and all default-configuration deployments of any version are not exploitable; (2) the attacker must hold kubevirt.io:edit permissions on the targeted namespace, which is a legitimate tenant role explicitly granted by cluster administrators. Clusters running OpenShift Virtualization below 4.21, or any version with ExternalNetResourceInjection disabled, are fully protected regardless of tenant privilege levels. Exploitation is further limited by the need for the attacker to know or enumerate valid NAD names in target namespaces, which may require additional reconnaissance. Authentication is required (PR:L per CVSS vector); unauthenticated exploitation is not possible.

The CVSS 3.1 score of 4.9 with vector AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:N accurately reflects the risk profile: network-reachable via the Kubernetes API, but constrained by high attack complexity (AC:H) due to the non-default ExternalNetResourceInjection feature gate prerequisite, and requiring low-privilege authenticated access (PR:L, kubevirt.io:edit role). The Scope:Changed designation is warranted because successful exploitation crosses namespace boundaries and affects network segments outside the tenant's authorized scope. No KEV listing exists, and no public POC has been reported, making this a theoretical risk at present. The real-world exposed population is narrow: only OpenShift Virtualization 4.21+ clusters where a cluster-admin has explicitly opted into a Beta feature gate are exploitable. For the vast majority of deployments using the default configuration, this vulnerability is not reachable regardless of tenant permissions. Priority should be elevated for clusters that have enabled ExternalNetResourceInjection for operational reasons, where trusted-tenant assumptions may be weaker.

A tenant holding kubevirt.io:edit permissions on a cluster where ExternalNetResourceInjection is enabled submits a VirtualMachineInstance manifest with the Multus networkName field set to a JSON NetworkSelectionElement array, specifying an administrative-namespace NAD and a spoofed IP and MAC address matching a privileged host. The API server admits the VMI (only the empty-string check fires), the launcher pod is created carrying the injected annotation, and Multus on the node parses it and attaches the pod to the targeted network segment - granting the tenant traffic visibility and impersonation capability on a network normally inaccessible to tenant workloads. No public proof-of-concept code has been identified, but the attack requires only familiarity with Multus CNI annotation syntax and knowledge of target NAD names.