Skip to main content

KubeVirt virt-handler CVE-2026-13622

| EUVDEUVD-2026-57615 HIGH
Path Traversal (CWE-22)
2026-08-12 redhat GHSA-4336-pf6g-hp94
8.8
CVSS 3.1 · Vendor: redhat
Share

Severity by source

Vendor (redhat) PRIMARY
8.8 HIGH
AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
vuln.today AI
8.8 HIGH

AV:L reflects cluster-local RBAC prerequisite; PR:L for namespace edit plus pods/exec; S:C and full C/I/A because the host node container runtime is fully compromised.

3.1 AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
4.0 AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H
SUSE
HIGH
qualitative
Red Hat
8.8 HIGH
qualitative

Primary rating from Vendor (redhat).

CVSS VectorVendor: redhat

Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Changed
Confidentiality
High
Integrity
High
Availability
High

Lifecycle Timeline

2
Analysis Generated
Aug 12, 2026 - 21:36 vuln.today
CVE Published
Aug 12, 2026 - 20:46 nvd
HIGH 8.8

DescriptionCVE.org

A symlink following vulnerability was found in KubeVirt's virt-handler migration proxy. During live migration, virt-handler dials Unix sockets inside the target virt-launcher pod via /proc/<pid>/root/ paths using net.Dial() without symlink protection. These socket paths reside in qemu-owned directories writable by the virt-launcher user. An attacker with namespace edit and pods/exec permissions can replace a migration proxy socket with a symlink to the host CRI-O socket. Because virt-handler runs as root in the host mount namespace, absolute symlink targets resolve against the host filesystem, and the bidirectional io.Copy proxy relays attacker-controlled bytes to the container runtime, enabling full node compromise.

AnalysisAI

Symlink following in KubeVirt's virt-handler migration proxy enables a low-privileged Kubernetes user holding namespace edit and pods/exec permissions to achieve full node compromise by redirecting a migration Unix socket to the host CRI-O container runtime socket. Because virt-handler runs as root within the host mount namespace and resolves socket paths through /proc/<pid>/root/ using net.Dial() without symlink validation, an attacker-controlled symlink placed in a qemu-writable directory causes virt-handler to transparently proxy arbitrary bytes into the container runtime, yielding complete control over the underlying Kubernetes node. No public exploit has been identified at time of analysis, but the scope change from container to host and the full CIA triad impact make this a critical remediation priority for all OpenShift Virtualization 4 deployments.

Technical ContextAI

KubeVirt is the open-source project underpinning Red Hat OpenShift Virtualization 4 (CPE: cpe:2.3:a:red_hat:red_hat_openshift_virtualization_4), which enables running virtual machines as Kubernetes workloads. During live migration, virt-handler acts as a migration proxy by dialing Unix domain sockets located inside the target virt-launcher pod. It accesses these sockets using /proc/<pid>/root/ path construction - a Linux mechanism that resolves relative to the filesystem root of another process - and invokes net.Dial() without any symlink-awareness guard. CWE-22 (Improper Limitation of a Pathname to a Restricted Directory) covers this class: the /proc/<pid>/root/ traversal effectively escapes the expected socket directory boundary. Because virt-handler runs as root in the host mount namespace, any absolute symlink found along the resolved path is followed against the host filesystem rather than the container's, allowing a crafted symlink to redirect the dial to the host-level CRI-O Unix socket at /run/crio/crio.sock. The bidirectional io.Copy relay then makes virt-handler an unwitting transparent proxy for attacker-supplied CRI-O API commands.

RemediationAI

Consult the Red Hat security advisory at https://access.redhat.com/security/cve/CVE-2026-13622 for the official patched build of OpenShift Virtualization 4; no specific fixed version number was provided in the available intelligence data, so administrators should check the advisory directly for the exact errata package version and apply it via the OpenShift update channel. While awaiting a patch, the most actionable compensating control is to audit and restrict pods/exec RBAC permissions within namespaces running virtual machines: removing pods/exec from developer-tier roles directly breaks the attacker's ability to manipulate sockets inside virt-launcher pods. Additionally, enforcing namespace-level network policies and admission controls (such as requiring privileged pod annotations only for system namespaces) reduces the attack surface. Restricting live migration to maintenance windows with heightened monitoring provides detection opportunity. Note that restricting pods/exec may impact legitimate debugging workflows and should be weighed against operational requirements. Do not rely on pod security standards alone, as the privilege escalation path exploits virt-handler's root-in-host-namespace design rather than container escape via pod security misconfigurations.

Vendor StatusVendor

SUSE

Severity: Important
Product Status
SUSE Linux Enterprise High Performance Computing 15 SP7 SUSE Linux Enterprise Module for Containers 15 SP7 SUSE Linux Enterprise Server 15 SP7 SUSE Linux Enterprise Server for SAP Applications 15 SP7 Fixed
SUSE Linux Enterprise Module for Containers 15 SP7 Affected
SUSE Linux Enterprise Server 15 SP7 Affected
SUSE Linux Enterprise Server for SAP Applications 15 SP7 Affected
SUSE Linux Enterprise High Performance Computing 15 SP7 Affected

Share

CVE-2026-13622 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy