Every CVE Search/ Get API key

CVE-2023-26484

On a compromised KubeVirt node, the virt-handler service account can be used to modify all node specs

8.2 HighFix available

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.

Attack profile

How easy it is to exploit

Attack vector
Network
Complexity
High
Privileges needed
Low
User interaction
None

What an attacker can affect

Confidentiality
High
Integrity
High
Availability
None

Exploit likelihood

0.61%Up 0.6 points since Mar 16, 2023
90%50%10%1%

What each source reports

CVE List Score used 8.2

On a compromised KubeVirt node, the virt-handler service account can be used to modify all node specs

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.

Record
CVE-2023-26484
CVSS 3.1
8.2 HighCVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N
Weakness
CWE-863
Updated
2026-11-02
EUVDEUVD-2023-0987 8.2

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.

Record
EUVD-2023-0987
CVSS 3.1
8.2 HighCVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N
Updated
2026-11-02
GitHub AdvisoriesGHSA-cp96-jpmq-xrr2 8.2

On a compromised node, the virt-handler service account can be used to modify all node specs

Impact

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.

Since this requires a node to be compromised first, the severity of this finding is considered Medium.

Patches

Not yet available.

Workarounds

Gatekeeper users can add a webhook which will block the virt-handler service account to modify the spec of a node.

An example policy, preventing virt-handler from changing the node spec may look like this:

apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: virthandlerrestrictions
spec:
[...]
  targets:
    - libs:
        - |         
[...]          
          is_virt_handler(username) {
              username == "system:serviceaccount:kubevirt:virt-handler"
          }
          mutates_node_in_unintended_way {
            # TODO
            # only allow kubevirt.io/ prefixed metadata node changes
          }
      rego: |
[...]
        
        violation[{"msg": msg}] {
          is_virt_handler(username)
          mutates_node_in_unintended_way(input.review.object, input.review.oldObject)
          msg := sprintf("virt-handler tries to modify node <%v> in an unintended way.", [input.review.object.name])
        }

and applying this template to node modifications.

Credits

Special thanks to the discoverers of this issue:

Nanzi Yang ([email protected]) Xin Guo ([email protected]) Jietao Xiao ([email protected]) Wenbo Shen ([email protected]) Jinku Li ([email protected])

References

https://github.com/kubevirt/kubevirt/issues/9109

Record
GHSA-cp96-jpmq-xrr2
CVSS 3.1
8.2 HighCVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N
Weakness
CWE-863
Updated
2026-11-02
NVD 8.2

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.

Record
CVE-2023-26484
CVSS 3.1
8.2 HighCVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N
Weakness
CWE-863
Updated
2026-11-02
OSVAZL-25673 8.2

CVE-2023-26484 affecting package kubevirt for versions less than 0.59.0-20

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.

Record
AZL-25673
CVSS 3.1
8.2 HighCVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N
Updated
2026-11-02
OSVAZL-34902 8.2

CVE-2023-26484 affecting package kubevirt for versions less than 1.2.0-1

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.

Record
AZL-34902
CVSS 3.1
8.2 HighCVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N
Updated
2026-11-02
Show 6 moreShow less
OSV 8.2

On a compromised KubeVirt node, the virt-handler service account can be used to modify all node specs

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.

Record
CVE-2023-26484
CVSS 3.1
8.2 HighCVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N
Weakness
CWE-863
Updated
2026-11-02
OSVGHSA-cp96-jpmq-xrr2 8.2

On a compromised node, the virt-handler service account can be used to modify all node specs

Impact

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.

Since this requires a node to be compromised first, the severity of this finding is considered Medium.

Patches

Not yet available.

Workarounds

Gatekeeper users can add a webhook which will block the virt-handler service account to modify the spec of a node.

An example policy, preventing virt-handler from changing the node spec may look like this:

apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: virthandlerrestrictions
spec:
[...]
  targets:
    - libs:
        - |         
[...]          
          is_virt_handler(username) {
              username == "system:serviceaccount:kubevirt:virt-handler"
          }
          mutates_node_in_unintended_way {
            # TODO
            # only allow kubevirt.io/ prefixed metadata node changes
          }
      rego: |
[...]
        
        violation[{"msg": msg}] {
          is_virt_handler(username)
          mutates_node_in_unintended_way(input.review.object, input.review.oldObject)
          msg := sprintf("virt-handler tries to modify node <%v> in an unintended way.", [input.review.object.name])
        }

and applying this template to node modifications.

Credits

Special thanks to the discoverers of this issue:

Nanzi Yang ([email protected]) Xin Guo ([email protected]) Jietao Xiao ([email protected]) Wenbo Shen ([email protected]) Jinku Li ([email protected])

References

https://github.com/kubevirt/kubevirt/issues/9109

Record
GHSA-cp96-jpmq-xrr2
CVSS 3.1
8.2 HighCVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N
Weakness
CWE-863
Updated
2026-11-02
OSVopenSUSE-SU-2024:12792-1 No score

kubevirt-container-disk-0.59.0-2.1 on GA media

These are all security issues fixed in the kubevirt-container-disk-0.59.0-2.1 package on the GA media of openSUSE Tumbleweed.

Record
openSUSE-SU-2024:12792-1
Updated
2026-11-02
OSVopenSUSE-SU-2026:11057-1 No score

kubevirt-1.8-container-disk-1.8.3-1.1 on GA media

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.

Record
openSUSE-SU-2026:11057-1
Updated
2026-11-02
OSVopenSUSE-SU-2026:11091-1 No score

kubevirt1.8-container-disk-1.8.3-1.1 on GA media

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.

Record
openSUSE-SU-2026:11091-1
Updated
2026-11-02
OSVSUSE-SU-2023:1967-1 No score

Security update for kubevirt, virt-api-container, virt-controller-container, virt-handler-container, virt-launcher-container, virt-libguestfs-tools-container, virt-operator-container

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:

  • CVE-2023-26484: Limit operator secrets permission. (bsc#1209359)

kubevirt is also rebuilt with a supported GO compiler (bsc#1208916)

Record
SUSE-SU-2023:1967-1
Updated
2026-11-02

Affected products

Affected packages

Affected packages
PackageAffectedFixed
kubevirt.io/kubevirt
Go
through 0.59.0 None known
kubevirt
Azure Linux:2
before 0.59.0-20
0.59.0-20
kubevirt
Azure Linux:3
before 1.2.0-1
1.2.0-1
kubevirt
SUSE:Linux Enterprise Micro 5.3
before 0.54.0-150400.3.13.1
0.54.0-150400.3.13.1
kubevirt
SUSE:Linux Enterprise Micro 5.4
before 0.54.0-150400.3.13.1
0.54.0-150400.3.13.1
kubevirt
SUSE:Linux Enterprise Module for Containers 15 SP4
before 0.54.0-150400.3.13.1
0.54.0-150400.3.13.1
kubevirt
openSUSE:Leap Micro 5.3
before 0.54.0-150400.3.13.1
0.54.0-150400.3.13.1
kubevirt
openSUSE:Leap 15.4
before 0.54.0-150400.3.13.1
0.54.0-150400.3.13.1
kubevirt
openSUSE:Tumbleweed
before 0.59.0-2.1
0.59.0-2.1
kubevirt-1.8
openSUSE:Tumbleweed
From an advisory covering 9 CVEs
before 1.8.3-1.1
1.8.3-1.1
kubevirt1.8
openSUSE:Tumbleweed
From an advisory covering 9 CVEs
before 1.8.3-1.1
1.8.3-1.1

History

History
RecordedChangedSources
affected, facts
first indexedCVE List, EUVD, GitHub Advisories, NVD, OSV

Dates are when Every CVE recorded each change. Upstream dates may differ.

In short

CVE-2023-26484 is a high vulnerability (CVSS 8.2) in Kubevirt, published March 15, 2023. No source lists public exploit code. EPSS puts the chance of exploitation in the next 30 days at 0.61%, the 49th percentile. Fixed in kubevirt 0.59.0-20.

References

Show 12 moreShow less
MoveEnter Open