{"id":"CVE-2023-26484","aliases":["AZL-25673","AZL-34902","EUVD-2023-0987","GHSA-cp96-jpmq-xrr2","SUSE-SU-2023:1967-1","openSUSE-SU-2024:12792-1","openSUSE-SU-2026:11057-1","openSUSE-SU-2026:11091-1"],"status":"published","title":"On a compromised KubeVirt node, the virt-handler service account can be used to modify all node specs","description":"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.","severity":{"version":"3.1","score":8.2,"vector":"CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N","level":"high","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-09","score":0.00611,"percentile":0.49578,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-863"],"published":"2023-03-15T20:40:17Z","modified":"2026-10-28T02:30:20Z","fixes":[{"ecosystem":"Azure Linux:2","package":"kubevirt","fixed_in":["0.59.0-20"],"sources":["osv"]},{"ecosystem":"Azure Linux:3","package":"kubevirt","fixed_in":["1.2.0-1"],"sources":["osv"]},{"ecosystem":"SUSE:Linux Enterprise Micro 5.3","package":"kubevirt","fixed_in":["0.54.0-150400.3.13.1"],"sources":["osv"]},{"ecosystem":"SUSE:Linux Enterprise Micro 5.4","package":"kubevirt","fixed_in":["0.54.0-150400.3.13.1"],"sources":["osv"]},{"ecosystem":"SUSE:Linux Enterprise Module for Containers 15 SP4","package":"kubevirt","fixed_in":["0.54.0-150400.3.13.1"],"sources":["osv"]},{"ecosystem":"openSUSE:Leap Micro 5.3","package":"kubevirt","fixed_in":["0.54.0-150400.3.13.1"],"sources":["osv"]},{"ecosystem":"openSUSE:Leap 15.4","package":"kubevirt","fixed_in":["0.54.0-150400.3.13.1"],"sources":["osv"]},{"ecosystem":"openSUSE:Tumbleweed","package":"kubevirt","fixed_in":["0.59.0-2.1"],"sources":["osv"]}],"affected":[{"source":"ghsa","ecosystem":"Go","package":"kubevirt.io/kubevirt","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"last_affected":"0.59.0"}]}]},{"source":"osv","ecosystem":"Azure Linux:2","package":"kubevirt","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.59.0-20"}]}]},{"source":"osv","ecosystem":"Azure Linux:3","package":"kubevirt","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.2.0-1"}]}]},{"source":"osv","ecosystem":"Go","package":"kubevirt.io/kubevirt","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"last_affected":"0.59.0"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Micro 5.3","package":"kubevirt","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.54.0-150400.3.13.1"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Micro 5.4","package":"kubevirt","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.54.0-150400.3.13.1"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Module for Containers 15 SP4","package":"kubevirt","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.54.0-150400.3.13.1"}]}]},{"source":"osv","ecosystem":"openSUSE:Leap Micro 5.3","package":"kubevirt","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.54.0-150400.3.13.1"}]}]},{"source":"osv","ecosystem":"openSUSE:Leap 15.4","package":"kubevirt","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.54.0-150400.3.13.1"}]}]},{"source":"osv","ecosystem":"openSUSE:Tumbleweed","package":"kubevirt","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.59.0-2.1"}]}]},{"source":"osv","ecosystem":"openSUSE:Tumbleweed","package":"kubevirt-1.8","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.8.3-1.1"}]}],"bundled":9},{"source":"osv","ecosystem":"openSUSE:Tumbleweed","package":"kubevirt1.8","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.8.3-1.1"}]}],"bundled":9}],"products":[{"vendor":"kubevirt","product":"kubevirt"}],"references":[{"url":"https://github.com/kubevirt/kubevirt/security/advisories/GHSA-cp96-jpmq-xrr2","tags":["x_refsource_CONFIRM","x_transferred","Mitigation","Vendor Advisory","advisory","web"]},{"url":"https://github.com/kubevirt/kubevirt/issues/9109","tags":["x_refsource_MISC","x_transferred","Issue Tracking","Third Party Advisory","report","web"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2023-26484","tags":["web","advisory"]},{"url":"https://github.com/advisories/GHSA-cp96-jpmq-xrr2"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2023/26xxx/CVE-2023-26484.json","tags":["advisory"]},{"url":"https://github.com/kubevirt/kubevirt","tags":["package"]},{"url":"https://www.suse.com/support/update/announcement/2023/suse-su-20231967-1/","tags":["advisory"]},{"url":"https://bugzilla.suse.com/1208916","tags":["report"]},{"url":"https://bugzilla.suse.com/1209359","tags":["report"]},{"url":"https://www.suse.com/security/cve/CVE-2023-26484","tags":["web"]},{"url":"","tags":["advisory"]},{"url":"https://www.suse.com/security/cve/CVE-2021-43565","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2023-44487","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2024-33394","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-22872","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-64433","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-64437","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-33186","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-9804","tags":["web"]}],"sources":{"cve":[{"id":"CVE-2023-26484","title":"On a compromised KubeVirt node, the virt-handler service account can be used to modify all node specs","description":"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.","status":"published","published":"2023-03-15T20:40:17.424Z","modified":"2025-02-25T14:56:59.739Z","cvss":[{"version":"3.1","score":8.2,"vector":"CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N","level":"high","assessor":"cna"}],"cwes":["CWE-863"],"updated_at":"2026-11-02T14:35:15.779187Z"}],"euvd":[{"id":"EUVD-2023-0987","description":"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.","status":"published","published":"2023-03-15T20:40:17Z","modified":"2025-02-25T14:56:59Z","cvss":[{"version":"3.1","score":8.2,"vector":"CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N","level":"high"}],"updated_at":"2026-11-02T20:53:24.646946Z"}],"ghsa":[{"id":"GHSA-cp96-jpmq-xrr2","title":"On a compromised node, the virt-handler service account can be used to modify all node specs","description":"### Impact\n\nIf 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.\n\nThis 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.\n\nThe 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.\n\nSince this requires a node to be compromised first, the severity of this finding is considered Medium.\n\n### Patches\n\nNot yet available.\n\n### Workarounds\nGatekeeper users can add a webhook which will block the `virt-handler` service account to modify the spec of a node.\n\nAn example policy, preventing virt-handler from changing the node spec may look like this:\n\n```yaml\napiVersion: templates.gatekeeper.sh/v1\nkind: ConstraintTemplate\nmetadata:\n  name: virthandlerrestrictions\nspec:\n[...]\n  targets:\n    - libs:\n        - |         \n[...]          \n          is_virt_handler(username) {\n              username == \"system:serviceaccount:kubevirt:virt-handler\"\n          }\n          mutates_node_in_unintended_way {\n            # TODO\n            # only allow kubevirt.io/ prefixed metadata node changes\n          }\n      rego: |\n[...]\n        \n        violation[{\"msg\": msg}] {\n          is_virt_handler(username)\n          mutates_node_in_unintended_way(input.review.object, input.review.oldObject)\n          msg := sprintf(\"virt-handler tries to modify node \u003c%v\u003e in an unintended way.\", [input.review.object.name])\n        }\n```\n\nand applying this template to node modifications.\n\n\n### Credits\n\nSpecial thanks to the discoverers of this issue:\n\nNanzi Yang (nzyang@stu.xidian.edu.cn)\nXin Guo (guox@stu.xidian.edu.cn)\nJietao Xiao (jietaoXiao@stu.xidian.edu.cn)\nWenbo Shen (shenwenbo@zju.edu.cn)\nJinku Li (jkli@xidian.edu.cn)\n\n### References\n\nhttps://github.com/kubevirt/kubevirt/issues/9109","status":"published","published":"2023-03-16T16:04:42Z","modified":"2023-03-27T22:24:36Z","cvss":[{"version":"3.1","score":8.2,"vector":"CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N","level":"high"}],"cwes":["CWE-863"],"updated_at":"2026-11-02T14:36:48.905887Z"}],"nvd":[{"id":"CVE-2023-26484","description":"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.","status":"published","published":"2023-03-15T21:15:08.857Z","modified":"2026-06-17T05:43:26.28Z","cvss":[{"version":"3.1","score":8.2,"vector":"CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N","level":"high","assessor":"secondary"},{"version":"3.1","score":8.2,"vector":"CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N","level":"high","assessor":"primary"}],"cwes":["CWE-863"],"updated_at":"2026-11-02T14:07:49.031498Z"}],"osv":[{"id":"AZL-25673","title":"CVE-2023-26484 affecting package kubevirt for versions less than 0.59.0-20","description":"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.","status":"published","published":"2023-03-15T21:15:08Z","modified":"2026-04-21T04:23:11.345495Z","cvss":[{"version":"3.1","score":8.2,"vector":"CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N","level":"high"}],"updated_at":"2026-11-02T15:28:03.093433Z"},{"id":"AZL-34902","title":"CVE-2023-26484 affecting package kubevirt for versions less than 1.2.0-1","description":"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.","status":"published","published":"2023-03-15T21:15:08Z","modified":"2026-04-21T04:47:26.762759Z","cvss":[{"version":"3.1","score":8.2,"vector":"CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N","level":"high"}],"updated_at":"2026-11-02T15:28:03.821827Z"},{"id":"CVE-2023-26484","title":"On a compromised KubeVirt node, the virt-handler service account can be used to modify all node specs","description":"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.","status":"published","published":"2023-03-15T20:40:17.424Z","modified":"2026-10-28T02:30:20.676294465Z","cvss":[{"version":"3.1","score":8.2,"vector":"CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N","level":"high"}],"cwes":["CWE-863"],"updated_at":"2026-11-02T15:44:31.135751Z"},{"id":"GHSA-cp96-jpmq-xrr2","title":"On a compromised node, the virt-handler service account can be used to modify all node specs","description":"### Impact\n\nIf 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.\n\nThis 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.\n\nThe 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.\n\nSince this requires a node to be compromised first, the severity of this finding is considered Medium.\n\n### Patches\n\nNot yet available.\n\n### Workarounds\nGatekeeper users can add a webhook which will block the `virt-handler` service account to modify the spec of a node.\n\nAn example policy, preventing virt-handler from changing the node spec may look like this:\n\n```yaml\napiVersion: templates.gatekeeper.sh/v1\nkind: ConstraintTemplate\nmetadata:\n  name: virthandlerrestrictions\nspec:\n[...]\n  targets:\n    - libs:\n        - |         \n[...]          \n          is_virt_handler(username) {\n              username == \"system:serviceaccount:kubevirt:virt-handler\"\n          }\n          mutates_node_in_unintended_way {\n            # TODO\n            # only allow kubevirt.io/ prefixed metadata node changes\n          }\n      rego: |\n[...]\n        \n        violation[{\"msg\": msg}] {\n          is_virt_handler(username)\n          mutates_node_in_unintended_way(input.review.object, input.review.oldObject)\n          msg := sprintf(\"virt-handler tries to modify node \u003c%v\u003e in an unintended way.\", [input.review.object.name])\n        }\n```\n\nand applying this template to node modifications.\n\n\n### Credits\n\nSpecial thanks to the discoverers of this issue:\n\nNanzi Yang (nzyang@stu.xidian.edu.cn)\nXin Guo (guox@stu.xidian.edu.cn)\nJietao Xiao (jietaoXiao@stu.xidian.edu.cn)\nWenbo Shen (shenwenbo@zju.edu.cn)\nJinku Li (jkli@xidian.edu.cn)\n\n### References\n\nhttps://github.com/kubevirt/kubevirt/issues/9109","status":"published","published":"2023-03-16T16:04:42Z","modified":"2023-11-08T04:12:02.02301Z","cvss":[{"version":"3.1","score":8.2,"vector":"CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N","level":"high"}],"cwes":["CWE-863"],"updated_at":"2026-11-02T15:46:45.28161Z"},{"id":"openSUSE-SU-2024:12792-1","title":"kubevirt-container-disk-0.59.0-2.1 on GA media","description":"These are all security issues fixed in the kubevirt-container-disk-0.59.0-2.1 package on the GA media of openSUSE Tumbleweed.","status":"published","published":"2024-06-15T00:00:00Z","modified":"2025-05-07T18:14:47.781963Z","updated_at":"2026-11-02T16:58:35.751245Z"},{"id":"openSUSE-SU-2026:11057-1","title":"kubevirt-1.8-container-disk-1.8.3-1.1 on GA media","description":"These are all security issues fixed in the kubevirt-1.8-container-disk-1.8.3-1.1 package on the GA media of openSUSE Tumbleweed.","status":"published","published":"2026-06-18T00:00:00Z","modified":"2026-06-19T08:15:07.166276407Z","updated_at":"2026-11-02T16:58:38.95195Z"},{"id":"openSUSE-SU-2026:11091-1","title":"kubevirt1.8-container-disk-1.8.3-1.1 on GA media","description":"These are all security issues fixed in the kubevirt1.8-container-disk-1.8.3-1.1 package on the GA media of openSUSE Tumbleweed.","status":"published","published":"2026-06-22T00:00:00Z","modified":"2026-06-24T09:00:22.313870064Z","updated_at":"2026-11-02T16:58:38.95195Z"},{"id":"SUSE-SU-2023:1967-1","title":"Security update for kubevirt, virt-api-container, virt-controller-container, virt-handler-container, virt-launcher-container, virt-libguestfs-tools-container, virt-operator-container","description":"This update for kubevirt, virt-api-container, virt-controller-container, virt-handler-container, virt-launcher-container, virt-libguestfs-tools-container, virt-operator-container fixes the following issues:\n\n- CVE-2023-26484: Limit operator secrets permission. (bsc#1209359)\n\nkubevirt is also rebuilt with a supported GO compiler (bsc#1208916)\n","status":"published","published":"2023-04-24T13:19:09Z","modified":"2026-02-04T03:24:59.548885Z","updated_at":"2026-11-02T15:53:52.350754Z"}]}}