CVE-2026-17527

CDI's clone authorization contains a semantic trap that makes the view ClusterRole dangerous despite its read-only label. The view role includes create permission on the datavolumes/source subresource—permission that CDI's authorization logic interprets as sufficient to authorize a DataVolume clone operation. In practice, this means an attacker with the view ClusterRole (often bound cluster-wide because it appears safe) plus edit access in any single namespace can create a DataVolume referencing a source PVC in a different namespace. CDI will permit the clone because the attacker holds create permission on the source reference, even though they have no business copying data across namespace boundaries. The root failure is that Kubernetes provides no mechanism for application-level authorization decisions to surface in the RBAC layer. CDI asks "does this subject have create-on-source?" but never asks "is this subject allowed to exfiltrate data from arbitrary namespaces?" The cluster admin who granted view permissions thought they were granting observation access. They were actually granting cross-namespace data movement capability. If you're running CDI, audit your ClusterRoleBindings immediately. The view ClusterRole should not be bound cluster-wide; restrict it to specific namespaces where observation is genuinely needed. Remove the create permission on datavolumes/source from any view-like roles, or create a stripped-down view role that excludes this subresource. Monitor for DataVolume resources where the source.namespace differs from the target namespace—this is the operational signature of the exploit. The broader lesson: treat any aggregated view role as potentially hazardous until you've audited what application-level authorization decisions those permissions trigger.

Reviewed through automated stages and approved by a human before publication.