Database/Container, Kubernetes & orchestration

Velero: malicious backup tarball escapes the extraction directory and overwrites files in the Velero pod

CVE-2026-32637Container, Kubernetes & orchestrationcurated

Impact

Velero restores run inside a pod that holds broad create and update rights on the Kubernetes API, because restoring a cluster means being able to write almost any object. An attacker who has compromised the object-storage backend holding backups can upload a tarball containing parent-directory paths that escape the extraction directory and overwrite sensitive files in the Velero pod filesystem. On a GPU cluster this is a path from "someone got into the backup bucket" to "someone influences what gets written back into the cluster" - including workload and RBAC objects on nodes you would rather not rebuild. Exploitation is not self-triggering: an operator has to run a restore against the poisoned backup (CVSS marks UI:A, 5.9).

Who can reach it

An attacker who already controls the backup object-storage backend (the S3, MinIO or equivalent bucket Velero writes to) plus an operator-initiated restore of the attacker-supplied backup. No Kubernetes credentials are needed.

What to do

Upgrade Velero to 1.18.1 or later - update the Velero deployment image and let the controller pod restart; no node drain or reboot is involved. Until then, treat restores from a backend you cannot vouch for as untrusted, and check that the bucket's credentials and bucket policy are not shared with tenant workloads.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-32637 https://github.com/velero-io/velero/security/advisories/GHSA-j2g6-362q-6qc6 https://github.com/velero-io/velero/commit/3f8e3588496391979915ace065f732a9013c1cf0 https://github.com/velero-io/velero/commit/c7fa4bfe3571667e9731f3f504da3c6be709a24c

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.