Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-09-29T17:17:06.843Z",
  "pubdate": "2026-09-29T17:17:06.843Z",
  "executiveSummary": "A critical availability vulnerability has been identified in KubeVirt concerning improper input validation within the virt-controller component. The vulnerability allows an authenticated user with permissions to create Virtual Machine Instances (VMIs) to trigger a persistent Denial of Service (DoS) condition.\nThe flaw manifests when a VMI definition containing an empty ephemeral volume is processed by the controller. Due to the lack of sufficient validation logic, the virt-controller encounters an unhandled exception, resulting in an immediate application crash. Because the malicious configuration persists within the Kubernetes cluster's state, the controller enters a recurring crash loop upon restart, effectively halting all virtual machine lifecycle management operations for the environment.\nThe risk implication is high, as a single malicious actor with restricted VMI creation privileges can disrupt administrative and user-facing cloud infrastructure operations. Exploitation is straightforward, requiring only the submission of a specifically malformed VMI manifest. No complex post-exploitation movement is required for the primary impact; the vulnerability serves as a primitive for cluster-wide infrastructure instability.",
  "technicalDetails": "The vulnerability originates in the virt-controller, the primary component responsible for managing the lifecycle of KubeVirt resources. Specifically, the component fails to perform adequate schema or semantic validation on VMI volume definitions before attempting to reconcile the resource state.\nThe root cause is an unhandled exception within the controller's logic when processing ephemeral volumes that lack necessary parameters. When the controller attempts to access or initialize an empty ephemeral volume structure, the code does not account for the null or missing reference, triggering an unhandled exception that propagates to the process level.\nThe attack flow follows a sequential path: First, an authenticated attacker with standard VMI creation permissions submits a crafted VMI manifest to the Kubernetes API server. This manifest contains a volume configuration defining an ephemeral volume without the required fields. Second, the API server accepts the valid-schema yet semantically invalid object and persists it into the etcd data store. Third, the virt-controller retrieves the new VMI object during its reconciliation loop. Fourth, the controller attempts to parse the volume configuration, encounters the logic error, and crashes. Finally, the Kubernetes deployment controller observes the crashed virt-controller pod and initiates a restart. Upon the new pod coming online, it immediately re-fetches the offending VMI object from etcd, re-triggers the exception, and continues the crash loop cycle indefinitely.\nThe impact is a total denial of service for the virt-controller. Because this component is the central orchestrator for all VMI states, its failure prevents the creation, deletion, or modification of any existing virtual machines in the cluster. Furthermore, the persistent nature of the object in the cluster state ensures that even after a controller restart, the environment remains in a failed state until the malicious object is manually removed by a cluster administrator. No specific network access or elevated cluster privileges beyond VMI creation are required, making this an accessible vector for any user with the ability to manage VMIs."
}