Velero restores PersistentVolumes from snapshots prior to creating their associated PersistentVolumeClaims. Velero also cleared all PersistentVolume's claimRef data, which meant that on restore in busy clusters, it is possible that Kubernetes would match the PersistentVolume with a PersistentVolumeClaim other than the one that originally made it, thus leaking data to unauthorized users. This does not impact volumes restored via the Velero restic support, which are recreated with completely new PersistentVolumes upon restore. Reference: https://github.com/vmware-tanzu/velero/security/advisories/GHSA-72xg-3mcq-52v4