Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2026-17527

CVE-2026-17527: KubeVirt CDI Auth Bypass Vulnerability

CVE-2026-17527 is an authentication bypass flaw in containerized-data-importer (CDI) that allows unauthorized PVC data exfiltration across namespaces. This article covers technical details, affected versions, and mitigations.

Published:

CVE-2026-17527 Overview

CVE-2026-17527 is a broken access control flaw [CWE-639] in the Containerized Data Importer (CDI), a KubeVirt component used to import, upload, and clone virtual machine disk images into Kubernetes Persistent Volume Claims (PVCs). The aggregated cdi.kubevirt.io:view ClusterRole, intended to grant read-only access, includes a create rule on the datavolumes/source subresource. CDI's DataVolume clone authorization treats this permission as sufficient to clone any PVC the caller can name, without requiring write access to the source namespace. Any principal with the view role plus edit or admin on one namespace can clone arbitrary PVCs cluster-wide.

Critical Impact

Authenticated users can exfiltrate the contents of any PVC in the cluster into a namespace they control, breaking namespace isolation.

Affected Products

  • Containerized Data Importer (CDI)
  • KubeVirt deployments using CDI
  • Red Hat OpenShift Virtualization environments

Discovery Timeline

  • 2026-07-27 - CVE-2026-17527 published to NVD
  • 2026-07-27 - Last updated in NVD database

Technical Details for CVE-2026-17527

Vulnerability Analysis

CDI exposes a virtual datavolumes/source subresource used during DataVolume clone operations. When a user requests a clone, CDI validates authorization by checking whether the caller can create on datavolumes/source in the source namespace. The aggregated cdi.kubevirt.io:view ClusterRole incorrectly aggregates this create verb into a role labeled as read-only.

Because view is commonly bound cluster-wide through a ClusterRoleBinding, any subject holding that role passes CDI's clone authorization check for every namespace in the cluster. The attacker then only needs edit or admin on a single destination namespace to receive the cloned data. The vulnerability results in cross-namespace data exfiltration through a legitimate CDI workflow.

Root Cause

The root cause is a permission model mismatch between the RBAC role definition and the resource semantics. The datavolumes/source subresource requires create permission for cloning, but create on this virtual subresource does not perform a write in the source namespace. Including this verb in an aggregated view role violates the read-only guarantee that operators assume when granting the role.

Attack Vector

An attacker with the cdi.kubevirt.io:view role bound cluster-wide and edit or admin rights in one namespace crafts a DataVolume in their controlled namespace. The DataVolume's spec.source.pvc field references a target PVC in any other namespace. CDI validates the caller's create permission on datavolumes/source in the source namespace, finds it granted by the view role, and proceeds with the clone. The contents of the source PVC are copied into a PVC in the attacker's namespace, from which they can be mounted and read.

See the Red Hat CVE-2026-17527 Advisory and Red Hat Bugzilla Report #2507413 for authoritative technical details.

Detection Methods for CVE-2026-17527

Indicators of Compromise

  • DataVolume objects whose spec.source.pvc.namespace differs from the DataVolume's own namespace, especially where the source namespace hosts sensitive workloads.
  • Kubernetes audit log entries showing create actions on datavolumes/source from principals holding only view and unrelated edit/admin bindings.
  • Unexpected clone PVCs and importer pods appearing in tenant or user-owned namespaces.

Detection Strategies

  • Enable Kubernetes API server audit logging at RequestResponse level for cdi.kubevirt.io resources and review datavolumes and datavolumes/source verbs.
  • Enumerate subjects bound to cdi.kubevirt.io:view cluster-wide and correlate with subjects that also have edit or admin in any namespace.
  • Alert on DataVolume creation where source and destination namespaces do not match and the requester is not a cluster administrator.

Monitoring Recommendations

  • Forward Kubernetes and OpenShift audit logs to a centralized analytics platform and build queries for cross-namespace clone patterns.
  • Track creation of PersistentVolumeClaim and CDI importer pods correlated to DataVolume events across namespace boundaries.
  • Baseline normal CDI clone activity per namespace and alert on deviations.

How to Mitigate CVE-2026-17527

Immediate Actions Required

  • Upgrade CDI to a fixed release once published by the KubeVirt project or your distribution vendor, per the Red Hat CVE-2026-17527 Advisory.
  • Audit and remove unnecessary cluster-wide ClusterRoleBinding entries referencing cdi.kubevirt.io:view.
  • Restrict edit and admin role grants to trusted principals and scope them narrowly to specific namespaces.

Patch Information

Refer to the vendor advisory for fixed CDI versions. The fix removes the create verb on datavolumes/source from the aggregated view ClusterRole and tightens CDI's clone authorization logic so that read-only permissions no longer authorize cross-namespace clones. Consult the Red Hat Bugzilla Report #2507413 for tracking of vendor-specific package updates.

Workarounds

  • Replace cluster-wide cdi.kubevirt.io:view bindings with namespace-scoped RoleBinding grants limited to namespaces users legitimately need to inspect.
  • Deploy an admission controller policy (Kyverno or OPA Gatekeeper) that rejects DataVolume objects where spec.source.pvc.namespace differs from metadata.namespace unless the requester is explicitly allowlisted.
  • Remove the create verb on datavolumes/source from any custom aggregated roles until the vendor patch is applied.
bash
# Example Kyverno policy fragment blocking cross-namespace DataVolume clones
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: block-cross-ns-datavolume-clone
spec:
  validationFailureAction: Enforce
  rules:
    - name: deny-cross-namespace-source
      match:
        any:
          - resources:
              kinds:
                - cdi.kubevirt.io/v1beta1/DataVolume
      validate:
        message: "Cross-namespace PVC clones are not permitted."
        deny:
          conditions:
            all:
              - key: "{{ request.object.spec.source.pvc.namespace }}"
                operator: NotEquals
                value: "{{ request.object.metadata.namespace }}"

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.