CVE-2026-13208: Kubevirt: virt-handler-rhel9: kubevirt: virt-handler notify server trusts vmi identity from unauthenticated grpc request body
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 SOPEERCRED 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
Other sources
A flaw was found in KubeVirt's virt-handler domain notify server. The gRPC handlers for HandleDomainEvent and HandleK8SEvent derive the VMI identity (namespace/name) solely from the request body without validating it against the connection's origin. Each virt-launcher pod connects through a per-VMI pipe socket, but no identity tag is propagated from the pipe path to the server handlers. This allows a compromised virt-launcher process to send forged domain lifecycle events for any other VMI scheduled on the same node, causing virt-handler to erroneously update that VMI's state and disrupt its lifecycle management.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Update HandleDomainEvent (L54) and HandleK8SEvent (L96) to derive/verify the target VMI identity from the connection origin (pipe path encodes per-VMI domain-notify-pipe.sock) and reject any DomainEvent/K8sEvent forged with a different DomainJSON informer key / EventNamespace / EventName than the connection-tagged VMI identity.
KubeVirt virt-handler domain notify server (pkg/virt-handler/notify-server/server.go) gRPC handler identity validation (HandleDomainEvent/HandleK8SEvent) = Reject events when request-body VMI identity (namespace/name and/or UID) does not match the VMI identity tagged from the originating pipe connection - Configuration
Modify pipe.go to tag each accepted pipe connection with the VMI UID at accept time (derived from the per-VMI domain-notify-pipe.sock path) and propagate that tagged identity to notify-server handlers so server handlers validate request-body identity against the connection origin.
KubeVirt virt-handler notify pipe server (pkg/virt-handler/notify-server/pipe.go) Per-connection authentication/identity tagging = Tag each accepted pipe connection with the VMI UID encoded in the pipe socket path and pass it through to server handlers; no trust of unauthenticated request-body identity
Event History
Frequently Asked Questions
What is the severity of CVE-2026-13208?
CVE-2026-13208 has a medium severity level with a score of 6.5.
How do I fix CVE-2026-13208?
To fix CVE-2026-13208, ensure that your KubeVirt installation is updated to the latest version which addresses this vulnerability.
What is the impact of CVE-2026-13208?
CVE-2026-13208 could allow unauthorized access by manipulating gRPC request bodies, potentially leading to data exposure.
What software is affected by CVE-2026-13208?
CVE-2026-13208 affects KubeVirt's virt-handler component.
How does CVE-2026-13208 exploit gRPC requests?
CVE-2026-13208 exploits vulnerabilities by trusting VMI identity derived from unauthenticated gRPC request bodies.