Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
11 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
A flaw was found in KubeVirt's virt-handler component. This vulnerability allows an authenticated OpenShift user with edit permissions in a single namespace to exploit improper symlink validation when connecting to virtual machine console sockets. By replacing the console socket with a symlink to the host's container runtime (CRI-O) socket, an attacker can hijack virt-handler's privileged connection. This enables the attacker to access any Unix socket on the host, potentially leading to full control of the node and the entire cluster.
Recommended action: Upgrade to 1.8.3, 1.7.4 or 1.6.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go kubevirt.io/kubevirt < 1.6.1; >= 1.7.0-alpha.0, < 1.7.0-rc.0
Fixed in
1.6.11.7.0-rc.0· Vendor fix available
Issue
The hostDisk feature in KubeVirt allows mounting a host file or directory owned by the user with UID 107 into a VM. However, the implementation of this feature and more specifically the DiskOrCreate option which creates a file if it doesn't exist, has a logic bug that allows an attacker to read and write arbitrary files owned by more privileged users on the host system. Details The hostDisk feature gate in KubeVirt allows mounting a QEMU RAW image directly from the host into a VM. While similar features, such as mounting disk images from a PVC, enforce ownership-based restrictions (e.g., only allowing files owned by specific UID, this mechanism can be subverted. For a RAW disk image to be readable by the QEMU process running within the virt-launcher pod, it must be owned by a user with UID 107. If this ownership check is considered a security barrier, it can be bypassed. In addition, the ownership of the host files mounted via this feature is changed to the user with UID 107.…
Recommended action: Upgrade to 1.7.0-rc.0 (pre-release) or 1.6.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go kubevirt.io/kubevirt < 1.5.3; >= 1.6.0-alpha.0, < 1.6.1
Fixed in
1.6.11.5.3· Vendor fix available
Issue
Short summary of the problem. Make the impact and severity as clear as possible. It is possible to trick the virt-handler component into changing the ownership of arbitrary files on the host node to the unprivileged user with UID 107 due to mishandling of symlinks when determining the root mount of a virt-launcher pod. Details Give all details on the vulnerability. Pointing to the incriminated source code is very helpful for the maintainer. In the current implementation, the virt-handler does not verify whether the launcher-sock is a symlink or a regular file. This oversight can be exploited, for example, to change the ownership of arbitrary files on the host node to the unprivileged user with UID 107 (the same user used by virt-launcher) thus, compromising the CIA (Confidentiality, Integrity and Availability) of data on the host. To successfully exploit this vulnerability, an attacker should be in control of the file system of the virt-launcher pod. PoC Complete…
Recommended action: Upgrade to 1.6.1 or 1.5.3 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The permissions granted to the virt-handler service account, such as the ability to update VMI and patch nodes, could be abused to force a VMI migration to an attacker-controlled node. Details Following the GitHub security advisory published on March 23 2023, a ValidatingAdmissionPolicy was introduced to impose restrictions on which sections of node resources the virt-handler service account can modify. For instance, the spec section of nodes has been made immutable, and modifications to the labels section are now limited to kubevirt.io-prefixed labels only. This vulnerability could otherwise allow an attacker to mark all nodes as unschedulable, potentially forcing the migration or creation of privileged pods onto a compromised node. However, if a virt-handler service account is compromised, either through the pod itself or the underlying node, an attacker may still modify node labels, both on the compromised node and on other nodes within the cluster. Notably, virt-handler…
Recommended action: Upgrade to 1.7.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Short summary of the problem. Make the impact and severity as clear as possible. A logic flaw in the virt-controller allows an attacker to disrupt the control over a running VMI by creating a pod with the same labels as the legitimate virt-launcher pod associated with the VMI. This can mislead the virt-controller into associating the fake pod with the VMI, resulting in incorrect status updates and potentially causing a DoS (Denial-of-Service). Details Give all details on the vulnerability. Pointing to the incriminated source code is very helpful for the maintainer. A vulnerability has been identified in the logic responsible for reconciling the state of VMI. Specifically, it is possible to associate a malicious attacker-controlled pod with an existing VMI running within the same namespace as the pod, thereby replacing the legitimate virt-launcher pod associated with the VMI. The virt-launcher pod is critical for enforcing the isolation mechanisms applied to the QEMU process…
Recommended action: Upgrade to 1.7.0-beta.0 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go kubevirt.io/kubevirt < 1.5.3; >= 1.6.0-alpha.0, < 1.6.1
Fixed in
1.6.11.5.3· Vendor fix available
Issue
Due to improper TLS certificate management, a compromised virt-handler could impersonate virt-api by using its own TLS credentials, allowing it to initiate privileged operations against another virt-handler. Details Give all details on the vulnerability. Pointing to the incriminated source code is very helpful for the maintainer. Because of improper TLS certificate management, a compromised virt-handler instance can reuse its TLS bundle to impersonate virt-api, enabling unauthorized access to VM lifecycle operations on other virt-handler nodes. The virt-api component acts as a sub-resource server, and it proxies API VM lifecycle requests to virt-handler instances. The communication between virt-api and virt-handler instances is secured using mTLS. The former acts as a client while the latter as the server. The client certificate used by virt-api is defined in the source code as follows and have the following properties: The virt-handler component verifies the signature of…
Recommended action: Upgrade to 1.6.1 or 1.5.3 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go kubevirt.io/kubevirt < 1.5.3; >= 1.6.0-alpha.0, < 1.6.1
Fixed in
1.6.11.5.3· Vendor fix available
Issue
Short summary of the problem. Make the impact and severity as clear as possible. Mounting a user-controlled PVC disk within a VM allows an attacker to read any file present in the virt-launcher pod. This is due to erroneous handling of symlinks defined within a PVC. Details Give all details on the vulnerability. Pointing to the incriminated source code is very helpful for the maintainer. A vulnerability was discovered that allows a VM to read arbitrary files from the virt-launcher pod's file system. This issue stems from improper symlink handling when mounting PVC disks into a VM. Specifically, if a malicious user has full or partial control over the contents of a PVC, they can create a symbolic link that points to a file within the virt-launcher pod's file system. Since libvirt can treat regular files as block devices, any file on the pod's file system that is symlinked in this way can be mounted into the VM and subsequently read. Although a security mechanism exists where…
Recommended action: Upgrade to 1.6.1 or 1.5.3 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Short summary of the problem. Make the impact and severity as clear as possible. A flawed implementation of the Kubernetes aggregation layer's authentication flow could enable bypassing RBAC controls. Details Give all details on the vulnerability. Pointing to the incriminated source code is very helpful for the maintainer. It was discovered that the virt-api component fails to correctly authenticate the client when receiving API requests over mTLS. In particular, it fails to validate the CN (Common Name) field in the received client TLS certificates against the set of allowed values defined in the extension-apiserver-authentication configmap. The Kubernetes API server proxies received client requests through a component called aggregator (part of K8S's API server), and authenticates to the virt-api server using a certificate signed by the CA specified via the --requestheader-client-ca-file CLI flag. This CA bundle is primarily used in the context of aggregated API servers,…
Recommended action: Upgrade to 1.7.0-rc.0 (pre-release), 1.6.1 or 1.5.3 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A flaw was found in kubevirt 0.29 and earlier. Virtual Machine Instances (VMIs) can be used to gain access to the host's filesystem. Successful exploitation allows an attacker to assume the privileges of the VM process on the host system. In worst-case scenarios an attacker can read and modify any file on the system where the VMI is running. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.
Recommended action: Upgrade to 0.30.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Users with the permission to create VMIs can construct VMI specs which allow them to read arbitrary files on the host. There are three main attack vectors: 1. Some path fields on the VMI spec were not properly validated and allowed passing in relative paths which would have been mounted into the virt-launcher pod. The fields are: spec.domain.firmware.kernelBoot.container.kernelPath, spec.domain.firmware.kernelBoot.container.initrdPath as well as spec.volumes[].containerDisk.path. Example: 2. Instead of passing in relative links on the API, using malicious links in the containerDisk itself can have the same effect: 3. KubeVirt allows PVC hotplugging. The hotplugged PVC is under user-control and it is possible to place absolute links there. Since containerDisk and hotplug code use the same mechanism to provide the disk to the virt-launcher pod, it can be used too to do arbitrary host file reads. In all three cases it is then possible to at lest read any host file: Patches…
Recommended action: Upgrade to 0.55.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A flaw was found in the KubeVirt main virt-handler versions before 0.26.0 regarding the access permissions of virt-handler. An attacker with access to create VMs could attach any secret within their namespace, allowing them to read the contents of that secret.
Recommended action: Upgrade to 0.26.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.