CVE-2026-102623: Kubevirt: kubevirt: virt-controller nil-pointer dereference via malformed ephemeral volume
A flaw was found in KubeVirt. An authenticated user with permission to create Virtual Machine Instances (VMIs) can cause a Denial of Service (DoS) by submitting a virtual machine definition with an empty ephemeral volume. The virt-controller component fails to properly validate the volume configuration, leading to an unhandled exception and application crash during processing. Because the malformed definition persists in the cluster, the controller enters a continuous crash loop, disrupting virtual machine lifecycle operations across the entire environment.
Other sources
A flaw was found in KubeVirt's virt-controller. A namespace tenant with permission to create VirtualMachineInstance resources can submit a VMI with an empty ephemeral volume specification (ephemeral: {}). The admission webhook validates that the Ephemeral field is non-nil but does not check the inner PersistentVolumeClaim pointer, which defaults to nil as an optional field. When virt-controller processes this VMI, the rendervolumes code dereferences the nil PersistentVolumeClaim pointer, causing a panic. Because the Kubernetes crash handler re-panics by default and the malformed VMI persists in etcd, the controller enters a permanent crash loop, blocking all VM lifecycle operations cluster-wide until an administrator manually deletes the offending VMI.
— Red Hat
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Operational
Manually delete the offending malformed VirtualMachineInstance (VMI) containing the empty ephemeral volume specification to stop the virt-controller crash loop.
Event History
Frequently Asked Questions
Who can exploit this issue?
An authenticated namespace tenant or other user with permission to create VirtualMachineInstance resources can trigger it. No additional interaction is required after submitting the malformed VMI definition.
What malformed configuration triggers the controller crash?
The VMI must contain an empty ephemeral volume specification, represented as ephemeral: {}. The admission webhook accepts it because it checks that the Ephemeral field exists but does not verify the inner PersistentVolumeClaim pointer.
What is the operational impact?
Processing the malformed VMI causes virt-controller to panic. Because the VMI persists in etcd, the controller can repeatedly crash and disrupt virtual machine lifecycle operations across the environment.
How can administrators determine whether they are affected?
Look for VirtualMachineInstance definitions containing an ephemeral volume with no PersistentVolumeClaim configuration, such as ephemeral: {}. Affected environments may also show repeated virt-controller crashes or restart loops while that VMI remains present.