KubeVirt VMI Denial-of-Service (DoS) Using Pod Impersonation
Date: 2025-11
Affected: go/kubevirt.io/kubevirt
Attack vector: deepfake
Category: vulnerability-disclosure
Severity: Medium
CVE: CVE-2025-64435
CWE: CWE-703
CVSS: 5.3 (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H)

### Summary _Short summary of the problem. Make the impact and severity as clear as possible. A logic flaw in the `virt-controller` allows an attacker to disrupt the control over a running VMI by creating a pod with the same labels as the legitimate `virt-launcher` pod associated with the VMI. This can mislead the `virt-controller` into associating the fake pod with the VMI, resulting in incorrect status updates and potentially causing a DoS (Denial-of-Service). ### Details _Give all details on the vulnerability. Pointing to the incriminated source code is very helpful for the maintainer._ A vulnerability has been identified in the logic responsible for reconciling the state of VMI. Specifically, it is possible to associate a malicious attacker-controlled pod with an existing VMI running within the same namespace as the pod, thereby replacing the legitimate `virt-launcher` pod associated with the VMI. The `virt-launcher` pod is critical for enforcing the isolation mechanisms applied to the QEMU process that runs the virtual machine. It also serves, along with `virt-handler`, as a management interface that allows cluster users, operators, or administrators to control the lifecycle of the VMI (e.g., starting, stopping, or migrating it). When `virt-controller` receives a notification about a change in a VMI's state, it attempts to identify the corresponding `virt-launcher` pod. This is necessary in several scenarios, including: - When hardware devices are requested to be


Mitigations:

Architectural layers (MAESTRO):