CVSS 3.0 score: 6.4

Impact

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.

Components affected

This vulnerability was part of the Velero restore controller.

Patches

Users should upgrade their clusters to either v1.4.3 or v1.5.2 in order to fix the vulnerable behavior.

Both of these versions have been updated to associate bound PersistentVolumes with only their target PersistentVolumeClaims by leaving the claimRef intact on restore.

Workarounds

There are no current workarounds for this issue.

References

Refer to this Kubernetes issue comment for how binding happens between PersistentVolumes and PersistentVolumeClaims.

Credit

he Velero project team would like to thank Arianit Uka of StackSoft for reporting this problem and working with us on its remediation.

For more information

If you have any questions or comments about this advisory:

• Open an issue in the Velero repo
• Email us at projectvelero@googlegroups.com