Bug 2493378 (CVE-2026-13325)
| Summary: | CVE-2026-13325 virt-handler-rhel9: kubevirt: kubevirt: DisableTLS migration setting removes authentication, exposing unauthenticated virtqemud proxy on all interfaces | ||
|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | OSIDB Bzimport <bzimport> |
| Component: | vulnerability | Assignee: | Product Security <prodsec-ir-bot> |
| Status: | NEW --- | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | unspecified | CC: | fdeutsch, oramraz, smullick, stirabos, thason |
| Target Milestone: | --- | Keywords: | Security |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | --- | |
| Doc Text: |
A flaw was found in KubeVirt's migration proxy. When spec.configuration.migrations.disableTLS is set to true on the KubeVirt custom resource, the target virt-handler binds a plain TCP listener on all interfaces (0.0.0.0/::) on a random port with no authentication, peer allow-list, or handshake token. This listener proxies directly into the target virt-launcher's virtqemud control socket. An attacker with a running pod on the cluster network can connect to this listener and issue unfiltered libvirt RPC commands against another tenant's virtual machine, including reading VM memory and configuration, modifying VM state via QMP, or destroying the VM. The bind address is unconditionally 0.0.0.0 — configuring a dedicated migration network via migrations.network only changes the advertised migration IP, not the listener bind address, so the port remains reachable on the pod network even when a dedicated migration network is configured. The API documentation describes disableTLS as removing "the additional layer of live migration encryption" without disclosing that it also removes all mutual authentication.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | Type: | --- | |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
A flaw was found in KubeVirt's migration proxy (pkg/virt-handler/migration-proxy/migration-proxy.go). When spec.configuration.migrations.disableTLS is set to true on the KubeVirt CR, serverTLSConfig is nilled and createTcpListener falls through to a plain net.Listen("tcp", ...) with no authentication. The listener binds unconditionally on 0.0.0.0/:: via GetIPZeroAddress() (pkg/util/net/ip/ip.go). The accept handler (handleConnection) performs no peer-IP check, no auth token validation, and immediately starts io.Copy into the target UNIX socket. The first proxied socket is virtqemud-sock, configured with auth_unix_rw=none. Any pod on the cluster network can connect and speak libvirt RPC against another tenant's VM. The migrations.network NAD configuration only changes the advertised migrationIpAddress (pkg/virt-handler/migration.go), not the listener bind, so the port remains reachable on the pod network even with a dedicated migration network. The API godoc (staging/src/kubevirt.io/api/core/v1/types.go) describes disableTLS as removing "the additional layer of live migration encryption" without disclosing the authentication removal. disableTLS is cluster-admin-only on the KubeVirt CR and is not available in the MigrationPolicy spec.