CVE-2026-13622: 
Linux openSUSE vulnerability analysis and mitigation

CVE-2026-13622 is a symlink following vulnerability in KubeVirt's virt-handler migration proxy that enables authenticated attackers to escape container boundaries and achieve full node compromise. During live VM migration, virt-handler dials Unix sockets inside the target virt-launcher pod via /proc/<pid>/root/ paths using net.Dial() without symlink protection, allowing an attacker to redirect those connections to the host CRI-O socket. The vulnerability was reported on June 29, 2026 (via Red Hat Bugzilla) and publicly disclosed on August 12, 2026. Affected products include Red Hat Container Native Virtualization (OpenShift Virtualization) versions 4.12 through 4.20 and later. It carries a CVSS v3.1 base score of 8.8 (High) (Red Hat CVE, GitHub Advisory).

The root cause is classified as CWE-22 (Improper Limitation of a Pathname to a Restricted Directory / Path Traversal), specifically a symlink following weakness. During live migration, virt-handler — a privileged DaemonSet running as root in the host mount namespace — calls net.Dial("unix", "/proc/<pid>/root/...") to connect to Unix sockets inside the target virt-launcher pod. Because this call does not validate or restrict symlinks, and because virt-handler operates in the host mount namespace, absolute symlink targets resolve against the host root filesystem rather than the container's filesystem. The socket directories (/var/run/kubevirt/migrationproxy/, /var/run/libvirt/) are owned by the qemu user and are writable from within the container. An attacker with namespace edit and pods/exec RBAC permissions can exec into the target virt-launcher pod during migration, replace a migration proxy socket with a symlink pointing to the host CRI-O socket, and then use the bidirectional io.Copy proxy in virt-handler to relay arbitrary CRI gRPC commands to the container runtime (Red Hat CVE, Red Hat Bugzilla).

Successful exploitation results in complete node compromise — full confidentiality, integrity, and availability impact on the underlying Kubernetes compute node. By relaying attacker-controlled bytes to the CRI-O container runtime socket, an attacker can bypass all Kubernetes admission controls, create or modify containers at the host level, access secrets and sensitive data on the node, and potentially pivot to other nodes in the cluster. Red Hat has rated this vulnerability as Important impact, noting that the attack path enables a container-to-host escape via the privileged virt-handler component (Red Hat CVE).

No public proof-of-concept exploit code is known to exist, and there is no evidence of in-the-wild exploitation at the time of disclosure (Red Hat CVE, GitHub Advisory). Exploitation requires an authenticated user with kubevirt.io:edit namespace-level permissions and pods/exec access — permissions that are standard for VM operators in KubeVirt environments, making the attack surface non-trivial but realistic in multi-tenant clusters. CISA's SSVC assessment (as of August 13, 2026) classifies exploitation as "none" and automation as "no", though technical impact is rated "total" (Red Hat CVE). The EPSS score is approximately 0.14–0.16%, indicating a low but non-zero probability of exploitation in the near term (GitHub Advisory). The vulnerability is not currently listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The vulnerability was discovered internally by Huzaifa Sidhpurwala of Red Hat (Red Hat CVE).

1. Reconnaissance: Identify a KubeVirt-enabled OpenShift/Kubernetes cluster running an unpatched version of virt-handler (Red Hat Container Native Virtualization 4.12–4.20). Confirm that your account holds kubevirt.io:edit namespace permissions and pods/exec access on a namespace running virtual machines.
2. Trigger live migration: Initiate a live migration of a virtual machine in the target namespace using the KubeVirt API (e.g., kubectl create -f vmim.yaml). This causes virt-handler on the destination node to begin dialing Unix sockets inside the target virt-launcher pod via /proc/<pid>/root/ paths.
3. Exec into target virt-launcher: While migration is in progress, use kubectl exec to gain a shell inside the target virt-launcher pod: kubectl exec -it <virt-launcher-pod> -- /bin/bash.
4. Replace migration proxy socket with symlink: Inside the container, navigate to the writable migration proxy socket directory (e.g., /var/run/kubevirt/migrationproxy/ or /var/run/libvirt/) and replace the active Unix socket file with a symlink pointing to the host CRI-O socket: rm <socket-file> && ln -s /run/crio/crio.sock <socket-file>.
5. Relay CRI gRPC commands: Because virt-handler runs as root in the host mount namespace, the absolute symlink resolves to the host's CRI-O socket. The bidirectional io.Copy proxy in virt-handler now relays attacker-controlled bytes to the container runtime. Send crafted CRI gRPC requests (e.g., RunPodSandbox, CreateContainer) through the proxy to create privileged containers or execute commands at the host level, achieving full node compromise (Red Hat CVE, Red Hat Bugzilla).

• Logs: Kubernetes audit logs showing kubectl exec commands targeting virt-launcher pods, especially during or immediately after live migration events; unexpected CRI-O gRPC calls originating from virt-handler processes that do not correspond to normal migration activity.
• File System: Symlinks in /var/run/kubevirt/migrationproxy/ or /var/run/libvirt/ inside virt-launcher pods pointing to host socket paths (e.g., /run/crio/crio.sock) instead of regular Unix socket files.
• Process: Unexpected container creation or privileged pod launches on a node shortly after a live migration event; virt-handler process making connections to the host CRI-O socket (/run/crio/crio.sock) outside of normal operational patterns.
• Network: Unusual CRI gRPC traffic patterns on the node's Unix socket layer; unexpected new containers or sandboxes appearing in crictl ps output without corresponding Kubernetes API objects.

Red Hat has released patched images for all affected versions of Red Hat Container Native Virtualization (OpenShift Virtualization) 4.12 through 4.20 via multiple security advisories (RHSA-2026:51031, RHSA-2026:53655, RHSA-2026:53671, RHSA-2026:53684, RHSA-2026:53721, RHSA-2026:53728, RHSA-2026:53763, RHSA-2026:53797, RHSA-2026:53826, RHSA-2026:53838, and RHEA-2026:53670). Updating to the patched virt-handler container images is the primary recommended remediation. As an immediate workaround, remove pods/exec permissions from VM operator RBAC roles in namespaces running virtual machines — this permission is required for the attack and its removal prevents exploitation. Additionally, enable Kubernetes audit logging and monitor for kubectl exec commands targeting virt-launcher pods, particularly during live migration events (Red Hat CVE, GitHub Advisory). SUSE has also released an update (SUSE-SU-2026:3604-1) for affected SUSE Linux Enterprise packages.

Red Hat rated the vulnerability as Important and was the CNA for this CVE; the issue was discovered internally by Red Hat security researcher Huzaifa Sidhpurwala (Red Hat CVE). SUSE issued its own security update (SUSE-SU-2026:3604-1) for affected packages, and the German Linux news site pro-linux.de covered the vulnerability in the context of KubeVirt security. RedPacketSecurity noted the CVE on Mastodon, and AusCERT published a bulletin (ESB-2026.9662). Community reaction has been moderate, consistent with a vulnerability requiring authenticated access in a specialized virtualization environment.