KubeVirt CVE-2026-9804

Attacker must hold namespace-level Kubernetes access sufficient to (a) write files into a filesystem-mode Persistent Volume Claim that will be exported (i.e., mount the PVC from a pod or otherwise stage a symlink within it) and (b) create or trigger a VirtualMachineExport custom resource targeting that PVC on a cluster running KubeVirt / Red Hat OpenShift Virtualization 4 with the virt-exportserver enabled. Exploitation is limited to filesystem-type PVC exports (block-mode PVCs and non-export workflows are not in scope per the description), requires the VMExport directory endpoint to be reachable by the attacker, and yields only file-read primitives (CVSS I:N/A:N) - no code execution or write. The CVSS PR:L confirms low privileges are required rather than full cluster-admin, but unauthenticated or cross-namespace exploitation is not indicated by the available data.

The CVSS 3.1 vector AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N indicates a network-reachable, low-complexity attack requiring only low-privilege namespace access, with scope change reflecting that data outside the vulnerable PVC boundary (the exporter pod) can be read - this is consistent with the 7.7 base score and the confidentiality-only impact (C:H, I:N, A:N) described. EPSS and KEV data were not provided in the intelligence set, and no public exploit identified at time of analysis, so likelihood of opportunistic exploitation is currently unmeasured; however, the prerequisite is realistic in any multi-tenant OpenShift Virtualization cluster where namespace edit rights are routinely granted to developers or platform tenants. Treat as a meaningful priority for shared/multi-tenant clusters and lower priority for single-tenant lab environments - note that 'specific namespace-level access' in the description is not further enumerated, so the exact RBAC verbs required should be verified against the Red Hat advisory before scoping internal exposure.

A tenant with edit rights in a namespace on a shared OpenShift Virtualization cluster mounts a filesystem PVC, plants a symbolic link such as 'leak -> /var/run/secrets/kubernetes.io/serviceaccount/token' inside it, then creates a VirtualMachineExport pointing at that PVC and retrieves the exported directory over the network. The exporter pod follows the symlink and returns the contents of files from its own filesystem - service account tokens, mounted secrets, or TLS material - enabling further lateral movement. No public exploit identified at time of analysis, but the attack is straightforward to script given namespace access.