CVE-2023-26484

{"cve": {"data_type": "CVE", "references": {"reference_data": [{"url": "https://github.com/kubevirt/kubevirt/issues/9109", "name": "https://github.com/kubevirt/kubevirt/issues/9109", "tags": [], "refsource": "MISC"}, {"url": "https://github.com/kubevirt/kubevirt/security/advisories/GHSA-cp96-jpmq-xrr2", "name": "https://github.com/kubevirt/kubevirt/security/advisories/GHSA-cp96-jpmq-xrr2", "tags": [], "refsource": "MISC"}]}, "data_format": "MITRE", "description": {"description_data": [{"lang": "en", "value": "KubeVirt is a virtual machine management add-on for Kubernetes. In versions 0.59.0 and prior, if a malicious user has taken over a Kubernetes node where virt-handler (the KubeVirt node-daemon) is running, the virt-handler service account can be used to modify all node specs. This can be misused to lure-in system-level-privileged components which can, for instance, read all secrets on the cluster, or can exec into pods on other nodes. This way, a compromised node can be used to elevate privileges beyond the node until potentially having full privileged access to the whole cluster. The simplest way to exploit this, once a user could compromise a specific node, is to set with the virt-handler service account all other nodes to unschedulable and simply wait until system-critical components with high privileges appear on its node. No patches are available as of time of publication. As a workaround, gatekeeper users can add a webhook which will block the `virt-handler` service account to modify the spec of a node."}]}, "problemtype": {"problemtype_data": [{"description": [{"lang": "en", "value": "CWE-863"}]}]}, "data_version": "4.0", "CVE_data_meta": {"ID": "CVE-2023-26484", "ASSIGNER": "security-advisories@github.com"}}, "impact": {}, "publishedDate": "2023-03-15T21:15Z", "configurations": {"nodes": [], "CVE_data_version": "4.0"}, "lastModifiedDate": "2023-03-16T12:56Z"}