<Vulnerability name="CVE-2026-13201">
    <DocumentDistribution xml:lang="en">Copyright © 2012 Red Hat, Inc. All rights reserved.</DocumentDistribution>
    <ThreatSeverity>Moderate</ThreatSeverity>
    <PublicDate>2026-06-24T00:00:00</PublicDate>
    <Bugzilla id="2492203" url="https://bugzilla.redhat.com/show_bug.cgi?id=2492203" xml:lang="en:us">
kubevirt: virt-handler-rhel9: kubevirt: safepath symlink following in virt-handler enables notify socket hijacking and node-level VM disruption
    </Bugzilla>
    <CVSS3 status="draft">
        <CVSS3BaseScore>7.3</CVSS3BaseScore>
        <CVSS3ScoringVector>CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:L/A:H</CVSS3ScoringVector>
    </CVSS3>
    <CWE>CWE-61</CWE>
    <Details xml:lang="en:us" source="Mitre">
A flaw was found in KubeVirt's safepath package used by virt-handler. The OpenAtNoFollow function uses O_PATH|O_NOFOLLOW to obtain a file descriptor to a path leaf, but downstream operations resolve the path via /proc/self/fd/N using link-following syscalls. When the leaf is a symlink, the kernel dereferences it, defeating the intended no-follow protection. An attacker with access to a virt-launcher pod can exploit this to redirect virt-handler's IPC socket connections, including the notify socket used for VM domain lifecycle events. By hijacking this socket, the attacker can inject arbitrary domain events into virt-handler, causing it to take incorrect lifecycle actions, corrupt VM state in the Kubernetes API, or crash — resulting in sustained denial of VM management services for all virtual machines on the affected node. Additionally, the same symlink following flaw allows virt-handler to apply file ownership or permission changes to unintended host paths.
    </Details>
    <Details xml:lang="en:us" source="Red Hat">
A flaw was found in KubeVirt's safepath package used by virt-handler. The OpenAtNoFollow function uses O_PATH|O_NOFOLLOW to obtain a file descriptor to a path leaf, but downstream operations resolve the path via /proc/self/fd/N using link-following syscalls. When the leaf is a symlink, the kernel dereferences it, defeating the intended no-follow protection. An attacker with access to a virt-launcher pod can exploit this to redirect virt-handler's IPC socket connections, including the notify socket used for VM domain lifecycle events. By hijacking this socket, the attacker can inject arbitrary domain events into virt-handler, causing it to take incorrect lifecycle actions, corrupt VM state in the Kubernetes API, or crash — resulting in sustained denial of VM management services for all virtual machines on the affected node. Additionally, the same symlink following flaw allows virt-handler to apply file ownership or permission changes to unintended host paths.
    </Details>
    <Statement xml:lang="en:us">
A flaw was found in KubeVirt's safepath package where OpenAtNoFollow obtains a file descriptor to a leaf symlink using O_PATH|O_NOFOLLOW, then downstream operations resolve the path via /proc/self/fd/N which dereferences the symlink, defeating the intended no-follow protection.

The primary impact is through notify socket hijacking: virt-handler uses safepath to resolve the path to the notify socket inside each virt-launcher pod. A namespace-level tenant with pod access can replace this socket path with a symlink to an attacker-controlled socket, enabling injection of arbitrary VM domain lifecycle events. Since virt-handler treats this as a trusted IPC channel, injected events are processed without validation and propagated to the Kubernetes API as VMI status updates. This allows the attacker to trigger incorrect VM lifecycle actions (shutdowns, restarts, migrations), corrupt VMI resource state, or crash the virt-handler process through malformed events. Because virt-handler is a single DaemonSet pod per node, a sustained crash loop denies VM management services — including console access, live migration, and lifecycle operations — for all virtual machines on that node.

A secondary impact exists through the chown/chmod path: virt-handler (running as root on the node) can be tricked into applying file ownership or permission changes to arbitrary host files with hardcoded values. This modification is blind — the attacker cannot read or write file contents and remains confined to the container. In default OpenShift Virtualization deployments, SELinux mandatory access controls and RHCOS immutable filesystem layers limit the set of targetable host files.
    </Statement>
    <Acknowledgement xml:lang="en:us">
This issue was discovered by Huzaifa Sidhpurwala (Red Hat).
    </Acknowledgement>
    <Mitigation xml:lang="en:us">
The following measures reduce the attacker pool and limit secondary impact:

Review RBAC policies to restrict pods/exec permissions on virt-launcher pods to only those users who strictly require it. This reduces the number of identities that can place symlinks in the launcher filesystem.
Ensure SELinux is in enforcing mode (default in OpenShift). While SELinux does not prevent the notify socket hijacking path, it restricts the set of host files targetable through the chown/chmod path by blocking operations on files with protected security labels.
RHCOS immutable filesystem layers prevent modification of core OS files through the chown/chmod path.
Note: no mitigation currently addresses the notify socket hijacking vector. The attacker's ability to inject domain events into virt-handler is not constrained by SELinux or filesystem immutability.
    </Mitigation>
    <PackageState cpe="cpe:/a:redhat:container_native_virtualization:4">
        <ProductName>Red Hat OpenShift Virtualization 4</ProductName>
        <FixState>Affected</FixState>
        <PackageName>container-native-virtualization/virt-handler</PackageName>
    </PackageState>
    <PackageState cpe="cpe:/a:redhat:container_native_virtualization:4">
        <ProductName>Red Hat OpenShift Virtualization 4</ProductName>
        <FixState>Affected</FixState>
        <PackageName>container-native-virtualization/virt-handler-rhel9</PackageName>
    </PackageState>
    <References xml:lang="en:us">
https://www.cve.org/CVERecord?id=CVE-2026-13201
https://nvd.nist.gov/vuln/detail/CVE-2026-13201
    </References>
</Vulnerability>