CVE-2026-29064: Path Traversal via Symlink Extraction in Zarf

Zarf is a CLI tool used to package, ship, and deploy Kubernetes clusters and applications in air-gapped environments. A core function of Zarf is the archiver component, which handles the compression and decompression of package artifacts (typically tarballs or zip files). CVE-2026-29064 identifies a critical flaw in how this component handles symbolic links during the extraction process.

The vulnerability is a variation of the "Zip Slip" class of path traversal issues. When Zarf extracts an archive, it processes file entries sequentially. If an entry is a symbolic link, Zarf creates it on the filesystem. However, in affected versions, the extraction logic does not properly sanitize or restrict the LinkTarget of these symlinks. This allows a malicious archive to create a symlink that points to a sensitive location on the host system (e.g., /etc/shadow or ~/.ssh/authorized_keys) rather than a file within the extraction sandbox.

While the creation of the symlink itself might be benign, subsequent operations—such as writing to a file that resolves through that symlink—can result in arbitrary file overwrites. Furthermore, if the user or a downstream process interacts with the extracted directory, they may unwittingly access or modify sensitive host files.

The root cause lies in the implementation of the defaultHandler, stripHandler, and filterHandler functions within src/pkg/archive/archive.go. These handlers are responsible for iterating through archive headers and performing filesystem operations based on the entry type.

In the vulnerable code, when a handler encounters a symbolic link (Type Symlink), it extracts the LinkTarget string from the archive header and passes it directly to os.Symlink. While the destination path (dst) is often constructed using filepath.Join, this function only performs lexical cleaning (e.g., removing .. references within the path string) but does not resolve the physical path or validate that the symlink target resides within the intended directory tree.

Specifically, the code lacked a "jail check"—a mechanism to resolve the canonical path of the symbolic link's target and verify it starts with the canonical path of the extraction root. Without this check, a LinkTarget of ../../../../etc/passwd is accepted as valid. When the operating system processes the symlink() syscall, it creates a link on the filesystem that points outside the extraction root, effectively bypassing the application's intended sandbox.

The remediation for this vulnerability leverages the os.Root API introduced in Go 1.24, which provides a robust mechanism for directory-scoped file operations. This approach is superior to traditional string-based sanitization as it enforces boundaries at the file descriptor level.

Vulnerable Logic (Simplified): The original code relied on standard os package calls that operate on global paths. Note the lack of validation on h.Linkname.

// BEFORE: src/pkg/archive/archive.go
func (h *defaultHandler) Handle(ctx context.Context, header *tar.Header, dst string) error {
    target := filepath.Join(dst, header.Name)
    // ...
    case tar.TypeSymlink:
        // Vulnerability: h.Linkname is trusted blindly
        if err := os.Symlink(header.Linkname, target); err != nil {
            return err
        }
    // ...
}

Patched Logic: The fix, applied in commit 93f9c33, refactors the extraction to use an os.Root handle. The extraction root is opened once, and all subsequent operations (creating directories, opening files, creating symlinks) are performed relative to this root handle using the root object methods. The OS kernel ensures these operations cannot escape the directory descriptor.

// AFTER: src/pkg/archive/archive.go
func (h *defaultHandler) Handle(ctx context.Context, root *os.Root, header *tar.Header) error {
    // 1. Sanitize entry name to prevent absolute paths or drive letters
    if err := validateEntryName(header.Name); err != nil {
        return err
    }
 
    // 2. Use root-scoped methods for filesystem operations
    switch header.Typeflag {
    case tar.TypeSymlink:
        // 3. Additional validation on the symlink target
        if err := validateSymlink(header.Linkname); err != nil {
            return err
        }
        // 4. Create symlink relative to the root handle
        // The 'root' object enforces the sandbox boundary
        if err := root.Symlink(header.Linkname, header.Name); err != nil {
            return err
        }
    }
}

Exploiting this vulnerability requires the attacker to create a specially crafted archive (TAR or ZIP) and convince a user to extract it using the zarf tools archiver decompress command. The attack does not require authentication to the system but does require the ability to supply the malicious package.

Step-by-Step Recreation:

1. Preparation: The attacker identifies a target file on the victim's system (e.g., /etc/shadow or a sensitive configuration file).
2. Archive Creation: The attacker creates a symlink on their local machine pointing to the target file using relative paths.

   ln -s ../../../../../etc/shadow malicious_link

3. Packaging: This symlink is packaged into a tarball. Standard tar commands preserve the relative link target.

   tar -czf exploit.tar.gz malicious_link

4. Delivery & Execution: The attacker distributes exploit.tar.gz. When the victim runs zarf tools archiver decompress exploit.tar.gz output_dir, Zarf replicates the symlink in output_dir.
5. Impact Realization: The resulting file output_dir/malicious_link now points to /etc/shadow. If the victim (or a script) reads from this file, they read the shadow file. If the archive contained a second entry that wrote data to malicious_link, the extraction process itself would overwrite /etc/shadow.

The successful exploitation of CVE-2026-29064 results in a high-impact integrity and confidentiality breach. The specific impact depends on the context in which Zarf is running.

Scenario 1: CI/CD Pipelines Zarf is frequently used in automated pipelines to prepare air-gapped bundles. If a pipeline extracts a malicious package, the attacker could overwrite pipeline configuration files, inject backdoors into build artifacts, or exfiltrate secrets available on the build agent's filesystem.

Scenario 2: Developer Workstations Developers using Zarf to examine packages locally run the tool with their user privileges. An attacker could overwrite ~/.ssh/authorized_keys to gain persistent access or read ~/.aws/credentials.

CVSS Breakdown (8.2): The vulnerability scores High because the scope is Changed (S:C)—the attack impacts the underlying host operating system, not just the Zarf application. Integrity (I:H) and Confidentiality (C:H) are both rated High due to the potential for arbitrary file access. User Interaction (UI:R) is required, preventing a 9.0+ score.