CVE-2026-32637 in Velero
Summary
by MITRE • 08/26/2026
Velero is an open source tool for backing up, restoring, and migrating Kubernetes cluster resources and persistent volumes. Prior to 1.18.1, an attacker who compromises the backup object-storage backend can upload a malicious backup tarball containing parent-directory paths that escape the extraction directory during restore and overwrite sensitive files in the Velero pod filesystem. This issue is fixed in version 1.18.1.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/26/2026
Velero serves as a critical infrastructure component for Kubernetes environments, providing essential capabilities for backing up, restoring, and migrating cluster resources along with persistent volumes. The security integrity of this tool relies heavily on the assumption that backup sources are trusted or properly validated before restoration operations commence. Prior to version 1.18.1, Velero contained a significant path traversal vulnerability within its restore logic that allowed an attacker who had compromised the object storage backend hosting backups to execute arbitrary file writes on the host system running the Velero pod. This flaw stems from insufficient validation of archive contents during the extraction process, specifically regarding parent-directory paths such as .. which are designed to navigate up the directory hierarchy.
The technical root cause lies in how the restore operation processes tarball archives uploaded by users or automated systems into the designated object storage bucket. When a backup is restored, Velero extracts files from the archive into a specific target directory on the pod's filesystem. However, the implementation failed to adequately sanitize file paths contained within the tarball metadata before extraction. Consequently, if an attacker uploads a maliciously crafted tarball containing entries with parent-directory traversal sequences in their filenames, the underlying extraction utility interprets these sequences literally rather than restricting them to the intended sandboxed directory. This allows files to be written outside of the designated backup restore path and into arbitrary locations on the Velero pod's filesystem.
The operational impact of this vulnerability is severe due to its potential for privilege escalation and cluster compromise. By overwriting sensitive configuration files, binaries, or scripts within the Velero pod container, an attacker can manipulate the behavior of the backup agent itself. For instance, replacing critical executables with malicious versions could lead to arbitrary code execution when subsequent restore operations are triggered by legitimate administrators. Furthermore, since Velero pods often run with elevated privileges to interact with Kubernetes APIs and manage persistent volumes, successful exploitation grants the attacker a foothold within the control plane infrastructure. This can serve as a pivot point for lateral movement across the cluster, potentially leading to full compromise of sensitive data stored in backups or disruption of critical business continuity operations.
This vulnerability aligns with CWE-22: Improper Limitation of a Pathname to a Restricted Directory, which describes flaws where software does not properly neutralize special elements within file paths that can cause files to be located outside of the intended directory. In terms of offensive security frameworks, this exploitation technique maps directly to ATT&CK T1083: File and Directory Discovery combined with T1564: Hide Artifacts or T1222: File Permission Modification, as it involves navigating file systems and altering system files to maintain access or escalate privileges. The attack vector is classified as remote via network services but requires initial compromise of the object storage backend, highlighting a dependency chain risk where securing one component does not guarantee security if adjacent components are breached.
Mitigation strategies must prioritize immediate version upgrades alongside defensive architectural controls. Organizations running Velero prior to 1.18.1 should upgrade to version 1.18.1 or later as soon as possible, as this release includes the necessary code changes to properly validate and sanitize file paths during extraction operations. In addition to patching, administrators should enforce strict access controls on object storage buckets containing backups using principles of least privilege, ensuring that only authorized service accounts can upload backup archives. Implementing integrity checks such as cryptographic signatures for backup artifacts before restoration can also prevent the ingestion of tampered or malicious tarballs. Furthermore, running Velero pods with minimal required permissions and utilizing container runtime security policies like Pod Security Standards can limit the blast radius if an exploitation attempt occurs by restricting write access to sensitive areas of the filesystem outside of designated operational directories.