A 'read-only' role in Red Hat OpenShift Virtualization lets one tenant copy another tenant's data

Red Hat handed out a role named cdi.kubevirt.io:view and marked it read-only. On clusters running OpenShift Virtualization, that role can copy data it was never meant to touch. A user who holds it, and who has ordinary write access to just one namespace, can pull the contents of any storage volume on the cluster into a project they own. The tenant boundary that shared clusters are sold on does not hold.

The flaw is tracked as CVE-2026-17527, disclosed by Red Hat on July 27, 2026 and rated 7.7 on the CVSS scale. It affects Red Hat OpenShift Virtualization 4, specifically the Containerized Data Importer (CDI), the component that imports and clones virtual machine disk images. There is no public exploit and no report of use in the wild. There is also, at the time of writing, no published fix.

What the flaw actually is

CDI lets you build a virtual machine disk by cloning an existing one. Cloning a volume out of another namespace is supposed to require write access to that source namespace, so a tenant cannot read data they were never granted.

The read-only cdi.kubevirt.io:view role broke that rule. It carried a permission to create on the datavolumes/source subresource, and CDI's clone-authorization logic treated that single permission as enough to approve the copy. It never checked for write access to the source namespace. So a role that should let you look and nothing else quietly carried the one grant needed to begin a cross-namespace copy.

Read the CVSS vector and the shape is plain: an authenticated user with low privileges (PR:L), no interaction from anyone else, a scope change across the namespace boundary (S:C), and a full read of the target data with no ability to alter or destroy it (C:H/I:N/A:N). This is a data-theft bug, not a wiper. Whatever sits on those volumes, database files, secrets written to disk, or another team's VM image, can be copied out intact.

Who is actually exposed

Two conditions have to line up, and both are ordinary. First, the account needs the aggregated cdi.kubevirt.io:view role bound cluster-wide, which Red Hat notes is a routine way to grant it. Read-only roles are the ones administrators hand out freely, precisely because everyone assumes they are harmless. Second, the account needs edit or admin rights in any single namespace, which every developer or tenant with a project already has.

That combination describes a normal user on a shared cluster, not an attacker who already broke in. The people most exposed are the ones running OpenShift Virtualization the way it is marketed: many teams on one cluster, or a managed-service provider hosting separate customers side by side. In those setups the whole point is that one tenant cannot reach another tenant's data. This bug reaches straight through it. It is the same class of problem as a cross-tenant flaw that let one account act as every other user, moved down into the cluster's storage layer.

How you would know if it was used

Because this is confidentiality-only, nothing breaks when it happens. No workload crashes, no volume is altered, no built-in alert fires. A tenant siphoning a neighbor's disk looks, from the outside, like normal platform activity. The only durable trace is the audit log.

The signal to hunt for is a DataVolume created with a PVC source that points at a namespace the requester does not own. Review the Kubernetes audit log for clone requests where the target namespace and the source namespace belong to different tenants. Start by inventorying who even holds the role:

kubectl get clusterrolebindings -o json \ | jq '.items[] | select(.roleRef.name=="cdi.kubevirt.io:view") | .metadata.name'Every binding that grants that role cluster-wide is a principal that could have used this, and worth confirming against your intended access model.

What to check right now

Patching closes the hole. It does not tell you whether data already left, so treat the two as separate jobs.

• Watch Red Hat's advisory. No erratum is published yet. Apply the fixed virt-cdi-operator build as soon as Red Hat ships it, and track the entry on the Red Hat CVE page.
• Tighten the role now. Until a fix lands, audit every cluster-wide binding of cdi.kubevirt.io:view and remove it from any principal that does not genuinely need read access to CDI resources. The aggregated read-only role is the blast radius.
• Hunt the audit log. Look back for DataVolume clone requests whose source volume lives in a namespace the requester does not control. That is your "were we already hit" question, and the patch will not answer it for you.

This is the same lesson as the last OpenShift Virtualization exposure we covered, where a single default setting could open VMs to any pod on the cluster: the platform's security rests on defaults and role definitions that are easy to hand out and hard to re-read. Kubernetes role aggregation sharpens the risk, because a role can gain a capability without anyone noticing that "view" now includes it. If you run virtual machines on a shared cluster, the permission model is the attack surface, the same way one Envoy Gateway policy could hand a user the keys to a cluster.