A flaw was found in KubeVirt's virt-handler domain notify server (pkg/virt-handler/notify-server/server.go). The gRPC handlers HandleDomainEvent (L54) and HandleK8SEvent (L96) derive the target VMI identity solely from the request body (DomainJSON informer key, EventNamespace/EventName) without validating it against the originating connection. Each virt-launcher connects via a per-VMI domain-notify-pipe.sock, but pipe.go performs a raw io.Copy byte pump with no peer identity tagging. No SO_PEERCRED or per-connection authentication is present on the shared socket.

A compromised virt-launcher can connect to its own pipe socket and send HandleDomainEvent/HandleK8SEvent gRPC messages claiming to be any other VMI on the same node. virt-handler processes these as authoritative, updating the victim VMI's state in the Kubernetes API. This enables cross-tenant denial of service: forced shutdown/restart loops, lifecycle state corruption, and K8s Event forgery.

Upstream fix recommendation: Tag each pipe connection with the VMI UID at accept time (the pipe socket path already encodes it) and pass that identity through to the notify-server handlers; reject any DomainEvent/K8sEvent whose embedded namespace/name/UID does not match the connection's tagged identity.

References:
- Vulnerable file: pkg/virt-handler/notify-server/server.go
- Pipe handler: pkg/virt-handler/notify-server/pipe.go