Zarf: Symlink targets in archives are not validated against destination directory

Vulnerability

Overview

CVE-2026-29064 is a path traversal vulnerability in Zarf, an airgap-native package manager for Kubernetes, affecting versions 0.54.0 through 0.73.0. The flaw resides in the archive extraction code within src/pkg/archive/archive.go, where symlink targets from archive entries are not validated to ensure they resolve within the extraction destination directory. Specifically, the defaultHandler function joins the destination path with the symlink target using filepath.Join but does not verify that the resolved path remains under the intended directory, allowing a crafted archive entry with a LinkTarget such as ../../../../etc/shadow to escape the extraction root [1][2].

Exploitation

An attacker can exploit this vulnerability by crafting a malicious Zarf package or archive containing symlink entries with targets pointing outside the destination directory. The attack requires processing of an untrusted or semi-trusted package, which could be received via file transfer, downloaded from a registry, or shared across organizational boundaries. The vulnerability also affects SDK consumers who utilize package load or archive operations. No authentication is needed beyond the ability to supply a crafted package to a system running an affected Zarf version [2].

Impact

Successful exploitation allows an attacker to achieve arbitrary file read or write on the system processing the package. By creating symlinks to sensitive files (e.g., /etc/shadow, SSH keys, or configuration files), an attacker could read their contents or overwrite them. In scenarios where an overwritten file is subsequently executed, this could lead to code execution, though the vulnerability itself does not provide an explicit execution path [2].

Mitigation

The issue has been patched in Zarf version 0.73.1, released on 2026-03-03 [4]. Users are advised to upgrade immediately. If immediate upgrade is not possible, only process Zarf packages from fully trusted sources. Previously created packages do not need to be rebuilt; only the Zarf binary or SDK package versions must be updated [2].