Link-following flaw in moby/go-archive enables writes outside the extraction directory

The tar extraction routines in moby/go-archive (Unpack, UnpackLayer, Untar/UntarUncompressed, and the ApplyLayer helpers) do not confine filesystem operations to the destination directory. The extractor decides where each archive entry lands using lexical string checks and then performs the filesystem operation on a path that is resolved by the OS, so links introduced by the archive can be followed out of the destination directory. An attacker who controls the contents of an archive can create or overwrite files at arbitrary paths writable by the extracting process.

• github.com/moby/go-archive: affected versions are < 0.3.0; 0.3.0 is the patched version.
• Docker Sandboxes: affected versions are < 0.38.0; release 0.38.0 contains the fix for the affected copy-out path.
• Docker Desktop: affected versions are < 4.86.0; release 4.86.0 fixes the destination-escape flaw in docker container cp.
• Docker Engine: affected versions are < 29.7.0; release 29.7.0 updates github.com/moby/go-archive to 0.3.0.
• Docker CLI: affected versions are < 29.7.0; verify and update the CLI using the corresponding boundary.
• Docker Compose: affected versions are < 5.4.0; 5.4.0 is the fixed boundary supplied in the record.
• Microsoft Azure Linux 3.0 has separate package boundaries: moby-engine before 0:25.0.3-20.azl3 and docker-cli before 0:25.0.7-5.azl3 are listed as affected; the corresponding package boundaries are 0:25.0.3-20.azl3 and 0:25.0.7-5.azl3.

Distro-backported packages and other bundled products require separate vendor-status checks. A fixed boundary for one Docker product or downstream package does not demonstrate that every parallel branch is unaffected.

moby/go-archive processes externally supplied tar content through the Unpack, UnpackLayer, Untar, UntarUncompressed, and ApplyLayer helper routines.

1. The extractor uses lexical string checks to decide where each archive entry should be placed.
2. It then performs filesystem operations on a path resolved by the operating system. If the archive has introduced a symbolic link or similar link in the destination tree, a later operation can follow that link outside the destination directory.
3. The extracting process can consequently create or overwrite files at arbitrary paths that it is allowed to write.

This is a link-following flaw classified as CWE-59, with path restriction characteristics also associated with CWE-22. Exploitation requires attacker control of archive contents and an affected extraction path that processes the archive. The available record does not establish the exact filesystem syscall used by each routine or every platform-specific behavior.

The supplied assessment describes local reachability, low attack complexity, no privileges required before the attack, and active user interaction. The attacker must provide a specially crafted archive to an extraction routine or product using the vulnerable logic.

A public proof of concept has been published and describes abusing Docker copy-out behavior to cause host-side writes in test scenarios. This confirms public PoC availability, but the available evidence does not establish exploitation in the wild. The issue is not described as a network service vulnerability that can be directly exploited remotely.

The confirmed technical outcome is that the extraction process can create or overwrite files at arbitrary paths it is permitted to write, rather than being limited to the destination directory. This directly affects file integrity and can affect availability if service files or data are replaced.

Loss of confidentiality, privilege changes, or code execution may follow depending on the selected file, the extracting process's permissions, and how the system uses that file afterward; these consequences are not automatic in every deployment. When extraction runs with high host privileges, the writable scope may be substantially broader than it is for a restricted account. When the process lacks permission to write the target, filesystem permissions limit the result.

The flaw can compromise the integrity of files within the extracting process's write permissions, including files outside the directory that an operator expected the archive to use. If extraction runs with elevated privileges, the affected set may include service configuration, executables, or other host data, creating a risk of service disruption or unauthorized system changes.

Actual exposure depends on the extracting process's permissions and on whether an attacker can deliver archive contents to the affected workflow. A replaced file could enable code execution or persistence if a service or system later trusts and executes it, but that is environment-dependent rather than guaranteed. The available evidence does not identify a breach, victim, or specific campaign.

1. Prioritize upgrading github.com/moby/go-archive to 0.3.0 or to the vendor-packaged fix. For Docker products, upgrade Docker Sandboxes to 0.38.0, Docker Desktop to 4.86.0, Docker Engine and Docker CLI to 29.7.0, or Docker Compose to 5.4.0, as applicable to the deployed product.
2. On Azure Linux 3.0, apply the Microsoft package updates for moby-engine to 0:25.0.3-20.azl3 and docker-cli to 0:25.0.7-5.azl3, or the corresponding vendor update confirmed as fixed.
3. If an immediate update is not possible, extract only trusted archives. This is the workaround stated by the advisory, not a complete fix and not a safe basis for processing attacker-controlled archives.
4. Rebuild or redeploy applications that bundle the vulnerable library directly, and check images, binaries, and CI artifacts for older copies.
5. Reconcile each release branch and downstream package separately after updating. A fixed boundary for Docker Desktop, Engine, CLI, Compose, or one distribution package does not prove that other products or parallel branches are safe.

1. Inventory direct and transitive dependencies for github.com/moby/go-archive in Go applications, image build systems, and Docker-related binaries.
2. Compare Docker Engine, Docker CLI, Docker Desktop, Docker Compose, and Docker Sandboxes versions with the affected boundaries in affected_summary. For distribution packages, check the distributor's package status rather than inferring safety from an upstream version alone.
3. Identify workflows that accept tar archives from users, containers, registries, CI jobs, or other sources that are not fully trusted, especially workflows that call the named extraction routines or use docker container cp.
4. Review file integrity, ownership, and unexpected changes to paths outside the intended destination after archive extraction. This is precautionary monitoring, not a confirmed indicator of compromise.
5. Test extraction in an isolated environment and verify that operations remain confined to the destination after upgrading. The absence of log evidence or unexpected changes does not prove that a system is safe.