{"dataType": "CVE_RECORD", "dataVersion": "5.1", "cveMetadata": {"cveId": "CVE-2023-26484", "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa", "state": "PUBLISHED", "assignerShortName": "GitHub_M", "dateReserved": "2023-02-23T23:22:58.575Z", "datePublished": "2023-03-15T20:40:17.424Z", "dateUpdated": "2024-08-02T11:53:54.297Z"}, "containers": {"cna": {"title": "On a compromised KubeVirt node, the virt-handler service account can be used to modify all node specs", "problemTypes": [{"descriptions": [{"cweId": "CWE-863", "lang": "en", "description": "CWE-863: Incorrect Authorization", "type": "CWE"}]}], "metrics": [{"cvssV3_1": {"attackComplexity": "HIGH", "attackVector": "NETWORK", "availabilityImpact": "NONE", "baseScore": 8.2, "baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "LOW", "scope": "CHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N", "version": "3.1"}}], "references": [{"name": "https://github.com/kubevirt/kubevirt/security/advisories/GHSA-cp96-jpmq-xrr2", "tags": ["x_refsource_CONFIRM"], "url": "https://github.com/kubevirt/kubevirt/security/advisories/GHSA-cp96-jpmq-xrr2"}, {"name": "https://github.com/kubevirt/kubevirt/issues/9109", "tags": ["x_refsource_MISC"], "url": "https://github.com/kubevirt/kubevirt/issues/9109"}], "affected": [{"vendor": "kubevirt", "product": "kubevirt", "versions": [{"version": "<= 0.59.0", "status": "affected"}]}], "providerMetadata": {"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa", "shortName": "GitHub_M", "dateUpdated": "2023-03-15T20:40:17.424Z"}, "descriptions": [{"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."}], "source": {"advisory": "GHSA-cp96-jpmq-xrr2", "discovery": "UNKNOWN"}}, "adp": [{"providerMetadata": {"orgId": "af854a3a-2127-422b-91ae-364da2661108", "shortName": "CVE", "dateUpdated": "2024-08-02T11:53:54.297Z"}, "title": "CVE Program Container", "references": [{"name": "https://github.com/kubevirt/kubevirt/security/advisories/GHSA-cp96-jpmq-xrr2", "tags": ["x_refsource_CONFIRM", "x_transferred"], "url": "https://github.com/kubevirt/kubevirt/security/advisories/GHSA-cp96-jpmq-xrr2"}, {"name": "https://github.com/kubevirt/kubevirt/issues/9109", "tags": ["x_refsource_MISC", "x_transferred"], "url": "https://github.com/kubevirt/kubevirt/issues/9109"}]}]}}

{}

{"configurations": [{"nodes": [{"cpeMatch": [{"criteria": "cpe:2.3:a:kubevirt:kubevirt:*:*:*:*:*:kubernetes:*:*", "matchCriteriaId": "B0C470F6-1D95-437E-9A57-D0075ED16482", "versionEndIncluding": "0.59.0", "vulnerable": true}], "negate": false, "operator": "OR"}]}], "cveTags": [], "descriptions": [{"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."}], "id": "CVE-2023-26484", "lastModified": "2023-03-27T16:58:06.613", "metrics": {"cvssMetricV31": [{"cvssData": {"attackComplexity": "HIGH", "attackVector": "NETWORK", "availabilityImpact": "NONE", "baseScore": 8.2, "baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "LOW", "scope": "CHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N", "version": "3.1"}, "exploitabilityScore": 1.8, "impactScore": 5.8, "source": "nvd@nist.gov", "type": "Primary"}, {"cvssData": {"attackComplexity": "HIGH", "attackVector": "NETWORK", "availabilityImpact": "NONE", "baseScore": 8.2, "baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "LOW", "scope": "CHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N", "version": "3.1"}, "exploitabilityScore": 1.8, "impactScore": 5.8, "source": "security-advisories@github.com", "type": "Secondary"}]}, "published": "2023-03-15T21:15:08.857", "references": [{"source": "security-advisories@github.com", "tags": ["Issue Tracking", "Third Party Advisory"], "url": "https://github.com/kubevirt/kubevirt/issues/9109"}, {"source": "security-advisories@github.com", "tags": ["Mitigation", "Vendor Advisory"], "url": "https://github.com/kubevirt/kubevirt/security/advisories/GHSA-cp96-jpmq-xrr2"}], "sourceIdentifier": "security-advisories@github.com", "vulnStatus": "Analyzed", "weaknesses": [{"description": [{"lang": "en", "value": "CWE-863"}], "source": "security-advisories@github.com", "type": "Primary"}]}

{"bugzilla": {"description": "kubevirt: Incorrect Authorization", "id": "2179728", "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2179728"}, "csaw": false, "cvss3": {"cvss3_base_score": "8.2", "cvss3_scoring_vector": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N", "status": "draft"}, "cwe": "CWE-863", "details": ["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.", "A flaw was found in the Kubevirt package. KubeVirt could allow a remote authenticated attacker to bypass security restrictions caused by improper authorization validation. An attacker can modify all node specs by sending a specially-crafted request using the virt-handler service account."], "name": "CVE-2023-26484", "package_state": [{"cpe": "cpe:/a:redhat:container_native_virtualization:4", "fix_state": "Not affected", "package_name": "container-native-virtualization/cluster-network-addons-operator-rhel9", "product_name": "Red Hat OpenShift Virtualization 4"}, {"cpe": "cpe:/a:redhat:container_native_virtualization:4", "fix_state": "Not affected", "package_name": "container-native-virtualization/kubemacpool", "product_name": "Red Hat OpenShift Virtualization 4"}, {"cpe": "cpe:/a:redhat:container_native_virtualization:4", "fix_state": "Not affected", "package_name": "container-native-virtualization/kubemacpool-rhel9", "product_name": "Red Hat OpenShift Virtualization 4"}, {"cpe": "cpe:/a:redhat:container_native_virtualization:4", "fix_state": "Will not fix", "package_name": "kubevirt", "product_name": "Red Hat OpenShift Virtualization 4"}], "public_date": "2023-03-15T00:00:00Z", "references": ["https://www.cve.org/CVERecord?id=CVE-2023-26484\nhttps://nvd.nist.gov/vuln/detail/CVE-2023-26484\nhttps://github.com/kubevirt/kubevirt/issues/9109\nhttps://github.com/kubevirt/kubevirt/security/advisories/GHSA-cp96-jpmq-xrr2"], "statement": "To exploit this, once a user could compromise a specific node, is to set the virt-handler service account to all other nodes to unschedulable, and simply wait until system-critical components with high privileges appear on its node. Since this requires a node to be compromised first, the impact of this issue is considered Moderate.", "threat_severity": "Moderate"}