No advisories yet.
Solution
No solution given by the vendor.
Workaround
Organizations can reduce exposure by: (1) restricting pods/exec permission on virt-launcher pods via admission policies (e.g., Gatekeeper or Kyverno rules denying exec on pods with the kubevirt.io launcher label), (2) using node affinity or dedicated node pools to isolate high-security tenant workloads from untrusted tenants, and (3) monitoring for unexpected VMI state transitions via cluster alerting.
Thu, 25 Jun 2026 00:15:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| References |
| |
| Metrics |
threat_severity
|
threat_severity
|
Wed, 24 Jun 2026 21:15:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Description | 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. | |
| Title | Kubevirt: virt-handler-rhel9: kubevirt: virt-handler notify server trusts vmi identity from unauthenticated grpc request body | |
| First Time appeared |
Redhat
Redhat container Native Virtualization |
|
| Weaknesses | CWE-287 | |
| CPEs | cpe:/a:redhat:container_native_virtualization:4 | |
| Vendors & Products |
Redhat
Redhat container Native Virtualization |
|
| References |
| |
| Metrics |
cvssV3_1
|
Projects
Sign in to view the affected projects.
Status: PUBLISHED
Assigner: redhat
Published:
Updated: 2026-06-24T20:39:00.675Z
Reserved: 2026-06-24T14:53:27.480Z
Link: CVE-2026-13208
No data.
No data.
OpenCVE Enrichment
Updated: 2026-06-25T00:30:03Z