Kaniko Build Context Path Traversal via Unsafe Tar Extraction

Kaniko is a tool designed to build container images from a Dockerfile, inside a container or Kubernetes cluster. A core phase of its operation involves unpacking a 'build context'—typically a compressed tar archive containing the application source code and Dockerfile. This process is expected to occur within a strictly confined directory (the workspace).

CVE-2026-28406 identifies a critical flaw in how Kaniko handles file paths within these archives. When extracting tar entries, the application fails to enforce that the destination path remains within the intended workspace root. This is a classic 'Zip Slip' or 'Tar Slip' vulnerability (CWE-22).

If an attacker can manipulate the build context (common in CI/CD pipelines where developers submit code/artifacts), they can include files with relative path traversals (e.g., ../../usr/bin/malicious). Upon extraction, Kaniko writes these files outside the workspace, overwriting system files on the builder's filesystem. This undermines the integrity of the build environment and facilitates further compromise.

The vulnerability stems from the unsafe usage of Go's path/filepath package during archive iteration. Specifically, the application relied on filepath.Clean and filepath.Join to determine the destination path for extraction. While filepath.Clean canonicalizes a path by removing redundant separators and . elements, it does not strip leading ../ components if they are syntactically valid relative to the input string.

In the vulnerable implementation, the code essentially performed the following operation:

// Vulnerable logic pattern
cleanedName := filepath.Clean(header.Name)
// If header.Name is "../../file", cleanedName remains "../../file"
destination := filepath.Join(extractionRoot, cleanedName)

The filepath.Join function resolves the path lexically. If cleanedName contains directory traversal sequences, the resulting destination path points outside extractionRoot. There was no subsequent check to verify that the resolved absolute path still shared the extractionRoot as its prefix.

Furthermore, the implementation lacked secure handling for symbolic links within the tar archive. A malicious symlink pointing to a parent directory could also be used to bypass path restrictions, allowing subsequent writes to traverse out of the sandbox.

The remediation involves replacing the naive path joining logic with securejoin, a library specifically designed to safely resolve paths within a chroot-like scope, and adding explicit lexical checks.

The fix was applied in pkg/util/fs_util.go. Below is a comparative analysis of the vulnerable and patched code paths.

Vulnerable Code (Simplified):

// The code simply cleans the name and joins it to the destination
cleanedName := filepath.Clean(hdr.Name)
path := filepath.Join(dest, cleanedName)
// File is written to 'path' immediately without boundary checks

Patched Code (Commit a370e4b1):

// 1. Lexical Validation: Reject explicit parent references immediately
if cleanedName == ".." || strings.HasPrefix(cleanedName, "../") {
    return fmt.Errorf("tar entry %q is not allowed: references parent directory", hdr.Name)
}
 
// 2. Secure Path Resolution: Use securejoin to handle symlinks and boundaries
path, err := securejoin.SecureJoin(dest, cleanedName)
if err != nil {
    return err
}
 
// 3. Post-Resolution Validation (Defense in Depth)
// Ensure the resolved path is actually inside the destination
if !strings.HasPrefix(path, dest) {
    return fmt.Errorf("tar entry %q resolves outside destination directory", hdr.Name)
}

The introduction of github.com/cyphar/filepath-securejoin ensures that even complex symlink attacks are mitigated, as SecureJoin emulates the kernel's path resolution logic in userspace to prevent breakouts.

To exploit this vulnerability, an attacker requires the ability to provide a build context to the Kaniko process. This is a standard workflow in CI/CD pipelines where Kaniko builds images based on repository contents.

Attack Vector Construction:

1. Crafting the Archive: The attacker creates a malicious tarball programmatically. Standard tar utilities often strip leading ../ for safety, so a script (e.g., Python or Go) is required to forcefully inject the traversal sequences.
2. Target Selection: The attacker targets a sensitive file. A high-value target in container build environments is the Docker credential helper (e.g., docker-credential-gcr or docker-credential-ecr-login).
3. Execution: The tarball entry is named ../../usr/bin/docker-credential-gcr. The content of this entry is a malicious binary or shell script.
4. Trigger: When Kaniko unpacks the context, it overwrites the system's credential helper. Later in the build process, when Kaniko attempts to push the built image to a registry, it invokes the credential helper. The malicious code executes with the privileges of the Kaniko process (often root within the container).

Proof of Concept Concept:

import tarfile
 
with tarfile.open("exploit.tar.gz", "w:gz") as tar:
    # Create a file that looks like a credential helper
    tar.add("malicious_script.sh", arcname="../../usr/local/bin/docker-credential-gcr")

The impact of CVE-2026-28406 is rated as High (CVSS 8.2). While the vulnerability is technically a path traversal, the context of Kaniko's operation elevates the risk significantly.

Integrity (High): The primary impact is arbitrary file overwrites. An attacker can modify any file the Kaniko process has write access to. In containerized build environments, Kaniko typically runs as root to perform filesystem operations required for image construction.

Confidentiality (Indirect): While the vulnerability is a write-primitive, it can lead to data exfiltration. By replacing binaries that handle secrets (like credential helpers or git wrappers), an attacker can capture authentication tokens or source code during subsequent build steps.

Availability (Low): An attacker could corrupt essential system libraries or binaries, causing the build pipeline to fail repeatedly (Denial of Service).

EPSS & Threat Landscape: As of late February 2026, the EPSS score is relatively low (0.12%), and there are no reports of active exploitation in the wild (CISA KEV negative). However, given the popularity of Kaniko in Kubernetes CI/CD (Tekton, Jenkins X, GitLab), this represents a significant latent risk for supply chain security.