CVE-2026-17527 in OpenShift Virtualization
Summary
by MITRE • 07/27/2026
In containerized-data-importer (CDI), the aggregated cdi.kubevirt.io:view ClusterRole, intended to provide read-only access to CDI resources, includes a rule granting create on the datavolumes/source subresource. CDI's DataVolume clone authorization accepts this permission as sufficient to authorize cloning the contents of any PVC the caller can name, without requiring write access to the source namespace. A user or service account bound to the view role, commonly granted cluster-wide via ClusterRoleBinding, who also has ordinary write access (edit/admin) to any single namespace, can use this to exfiltrate the contents of any PVC in the cluster into a namespace they control, bypassing namespace isolation and the read-only guarantee of the view role.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 07/27/2026
The vulnerability exists within the containerized-data-importer (CDI) system where the aggregated cdi.kubevirt.io:view ClusterRole is designed to provide read-only access to CDI resources while maintaining strict namespace boundaries. This security mechanism fails due to an improper permission grant that includes a rule allowing create operations on the datavolumes/source subresource. The flaw represents a privilege escalation issue that violates the principle of least privilege and undermines the fundamental security model of Kubernetes RBAC. When combined with a user or service account that possesses ordinary write access (edit/admin) to any single namespace, this misconfiguration creates a critical exploit path that bypasses all namespace isolation controls.
The technical implementation flaw stems from the overly permissive ClusterRole definition that grants create permissions on datavolumes/source subresource without proper authorization checks. This permission allows unauthorized cloning operations that can transfer data from any PersistentVolumeClaim (PVC) within the cluster into a namespace controlled by the attacker. The vulnerability specifically affects CDI's DataVolume clone authorization mechanism which incorrectly validates the view role's create permission as sufficient authorization for cloning operations, regardless of whether the source PVC belongs to the same namespace or not. This design flaw enables cross-namespace data exfiltration while maintaining the appearance of read-only access, effectively breaking the security boundary between namespaces.
The operational impact of this vulnerability is severe and far-reaching within containerized environments that rely on CDI for data management. An attacker with a view role binding can leverage this weakness to extract sensitive data from any PVC across the cluster without requiring additional write permissions to source namespaces. The attack vector exploits the trust model where read-only roles are expected to maintain data confidentiality and isolation, but instead becomes a pathway for unauthorized data extraction. This vulnerability particularly affects multi-tenant environments where namespace isolation is critical for maintaining security boundaries between different teams, applications, or organizational units.
Mitigation strategies must address both immediate operational fixes and long-term architectural improvements to prevent similar issues in the future. The primary fix involves modifying the cdi.kubevirt.io:view ClusterRole to remove or restrict the create permission on datavolumes/source subresource, ensuring that view roles maintain their read-only guarantee without enabling unauthorized data movement operations. Additionally, organizations should implement comprehensive RBAC reviews and privilege audits to identify similar misconfigurations across their Kubernetes clusters. The solution aligns with security best practices outlined in CWE-284 (Improper Access Control) and follows ATT&CK techniques related to privilege escalation and lateral movement through compromised roles. Regular security scanning and monitoring for unauthorized permission changes should be implemented to detect potential abuse of this vulnerability. Organizations must also consider implementing network policies and admission controllers that enforce additional checks beyond standard RBAC mechanisms to prevent data exfiltration attempts.