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 authunixrw=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.
A flaw was found in KubeVirt's RBAC (Role-Based Access Control) evaluation logic. The authorization mechanism improperly truncates subresource names during evaluation. This causes requests for granular subresources, such as vnc/screenshot or sev/, to be incorrectly evaluated against their parent resource permissions (e.g., vnc or sev). As a result, the RBAC engine fails to enforce the intended granular access controls. This can cause legitimate users to be denied access or allow authenticated users with specific custom roles to gain unauthorized access to subresources.
A flaw was found in KubeVirt's RBAC (Role-Based Access Control) evaluation logic. The authorization mechanism improperly truncates subresource names during evaluation. This causes requests for granular subresources, such as vnc/screenshot or sev/, to be incorrectly evaluated against their parent resource permissions (e.g., vnc or sev). As a result, the RBAC engine fails to enforce the intended granular access controls. This can cause legitimate users to be denied access or allow authenticated users with specific custom roles to gain unauthorized access to subresources.