CVE-2026-7374: KubeVirt Privilege Escalation Vulnerability

CVE-2026-7374 Overview

CVE-2026-7374 is a critical symlink validation flaw in KubeVirt's virt-handler component, shipped with Red Hat OpenShift Virtualization. An authenticated OpenShift user with edit permissions in a single namespace can replace a virtual machine console socket with a symbolic link pointing to the host's CRI-O container runtime socket. When virt-handler connects to the expected console socket, it follows the symlink and binds its privileged session to the CRI-O socket instead. The attacker hijacks this privileged connection to issue container runtime commands directly on the node. The flaw is classified under CWE-59: Improper Link Resolution Before File Access.

Critical Impact

A namespace-scoped tenant can escalate to full cluster administrator by hijacking virt-handler's privileged Unix socket connection, gaining control over CRI-O and every node in the cluster.

Affected Products

• Red Hat OpenShift Virtualization (KubeVirt downstream distributions)
• KubeVirt virt-handler component
• OpenShift clusters running affected KubeVirt versions referenced in Red Hat advisories RHSA-2026:20720 through RHSA-2026:20975

Discovery Timeline

• 2026-05-26 - CVE-2026-7374 published to the National Vulnerability Database
• 2026-05-28 - Last updated in NVD database

Technical Details for CVE-2026-7374

Vulnerability Analysis

KubeVirt runs virt-handler as a privileged DaemonSet on every node hosting virtual machines. The component exposes console access by connecting to per-VM Unix sockets located in tenant-controlled directories. The flaw stems from virt-handler opening these socket paths without verifying that the final resolved path remains inside the expected directory. An authenticated tenant with edit rights in a namespace where a VM is running can delete the legitimate console socket and create a symbolic link of the same name that points to /var/run/crio/crio.sock on the host. The next console connection from virt-handler follows the symlink and attaches the privileged process to the CRI-O API socket. Because virt-handler proxies the byte stream back to the caller, the attacker holds an authenticated channel to the container runtime and can create privileged containers, mount the host filesystem, or extract service account tokens. This results in node takeover and lateral movement to cluster-wide compromise.

Root Cause

The root cause is improper link resolution before file access in virt-handler's console socket connection logic. The component trusts that paths under the VM's runtime directory resolve to regular sockets, and it does not call O_NOFOLLOW, perform realpath validation, or compare the resolved inode against the expected target before dialing.

Attack Vector

The attack requires only a low-privilege OpenShift account with edit permissions on a single namespace that hosts a KubeVirt VM. The attacker writes into the shared socket directory, swaps the console socket for a symlink to /var/run/crio/crio.sock, and triggers a console connection through the standard virtctl console or API call. virt-handler follows the link with its root-equivalent service account, granting the attacker direct CRI-O access and a path to cluster-wide privilege escalation. The scope-changed CVSS vector reflects this cross-tenant blast radius.

No verified public exploit code is available. See the Red Hat CVE Analysis for CVE-2026-7374 for additional technical context.

Detection Methods for CVE-2026-7374

Indicators of Compromise

• Symbolic links inside KubeVirt VM runtime directories (typically under /var/run/kubevirt/ or /var/lib/kubelet/pods/<uid>/volumes/) that resolve to /var/run/crio/crio.sock or any host socket outside the VM scope.
• Unexpected CRI-O API requests originating from the virt-handler process, especially CreateContainer or RunPodSandbox calls not tied to legitimate kubelet activity.
• Audit log entries showing namespace-scoped users with edit role invoking virtualmachineinstances/console against VMs whose console sockets were recently recreated.

Detection Strategies

• Monitor file events under VM runtime directories for symlink or rename syscalls that produce links targeting paths outside the pod sandbox.
• Correlate virt-handler socket connections with the expected inode of each VM's console socket and alert on mismatches.
• Inspect CRI-O audit logs for container creation requests whose caller credentials match virt-handler but whose payloads include host path mounts or privileged security contexts.

Monitoring Recommendations

• Enable Kubernetes audit logging at the RequestResponse level for virtualmachineinstances/console subresources and stream events to a central SIEM.
• Track RoleBinding and ClusterRoleBinding changes that grant edit or kubevirt.io:edit rights in VM-hosting namespaces.
• Baseline the set of Unix sockets opened by virt-handler per node and alert on connections to runtime sockets such as crio.sock, containerd.sock, or docker.sock.

How to Mitigate CVE-2026-7374

Immediate Actions Required

• Apply the fixed KubeVirt and OpenShift Virtualization packages distributed in Red Hat advisories RHSA-2026:20720, RHSA-2026:20736, RHSA-2026:20763, RHSA-2026:20767, RHSA-2026:20782, RHSA-2026:20825, RHSA-2026:20866, RHSA-2026:20886, RHSA-2026:20890, and RHSA-2026:20975.
• Audit RoleBindings to remove unnecessary edit permissions in namespaces that host KubeVirt VirtualMachineInstances.
• Review recent virtualmachineinstances/console activity for suspicious patterns and rotate node and service account credentials if hijack indicators are present.

Patch Information

Red Hat has released patched builds across multiple OpenShift Virtualization streams. Refer to the Red Hat Security Advisory RHSA-2026:20720 and the consolidated Red Hat CVE Analysis for CVE-2026-7374 for the complete list of fixed versions and the Red Hat Bugzilla Report #2463728 for tracking details.

Workarounds

• Restrict the kubevirt.io:edit and built-in edit cluster roles in namespaces that host VirtualMachineInstances until patches are applied.
• Use admission controls (OPA/Gatekeeper or Kyverno) to deny user-created symbolic links inside KubeVirt-managed PersistentVolumes and emptyDir mounts shared with virt-handler.
• Disable interactive console access for untrusted tenants by gating the virtualmachineinstances/console subresource through RBAC until upgrades complete.

# Example RBAC patch to remove console access from a tenant role
kubectl patch clusterrole tenant-edit --type=json -p='[
  {"op":"remove","path":"/rules","value":{"apiGroups":["subresources.kubevirt.io"],"resources":["virtualmachineinstances/console"],"verbs":["get","update"]}}
]'

# Verify no tenant role retains console verbs
kubectl get clusterrole -o json | jq '.items[] | select(.rules[]?.resources[]? | test("virtualmachineinstances/console")) | .metadata.name'