Docker archive extraction checked names but followed links

An archive entry can have an acceptable name and still cause a write outside the extraction directory. CVE-2026-17106 concerns that distinction in moby/go-archive. The extractor checked paths as strings, then handed filesystem operations to an operating system that resolved links. An archive could introduce those links and influence where a subsequent operation actually landed.

Docker published the CVE record on August 18. The Desktop 4.86.0 release notes identify the issue as a destination escape in docker container cp and date the patched release August 10. The underlying go-archive advisory, published August 11, describes the library failure. Those dates refer to different artifacts in the disclosure process.

The technical scope extends beyond a Desktop command. Docker's CVE record names several products that consume the affected archive implementation. The common cause is failure to confine extraction operations to the chosen destination. The consequence depends on where the extracting process runs and which files it can write.

String validation does not resolve a filesystem

The advisory names Unpack, UnpackLayer, Untar and UntarUncompressed, together with the ApplyLayer helpers. These routines unpack archive entries into a filesystem. Their vulnerable behavior was to decide where entries belonged using lexical checks before performing operations whose path interpretation depended on the filesystem's actual state.

A lexical check considers characters and path components. The operating system also considers links encountered during resolution. If an archive introduces a link that redirects an intermediate component, a later pathname can resolve beyond the directory that the extraction code intended to authorize. The advisory attributes the escape to that difference between the checked name and the resolved target.

This explains why simply discussing suspicious .. components would miss the documented failure. The published mechanism concerns links introduced by the archive. An apparently ordinary entry name can become dangerous because an earlier filesystem change alters the meaning of one of its components. Authorization has to remain true when the operation reaches its target.

The archive publisher controls more than the bytes of individual files. The publisher also controls the set of entries presented to the extractor. In the vulnerable implementation, that control could influence the paths used for later operations. Extraction therefore needs to account for the directory state created during extraction itself.

The source does not describe the full implementation of the repaired path handling, so it would be premature to prescribe a particular syscall sequence as Docker's fix. What it establishes is the broken property. Filesystem operations did not stay confined to the destination directory. A reliable repair must restore that property across the affected extraction routines.

The extraction process supplies the authority

The stated impact is creation or overwriting of arbitrary paths writable by the extracting process. That qualification matters. The advisory does not say every extraction becomes root execution on every host. It says attacker-controlled archive contents can direct writes beyond the intended destination, subject to the process's existing filesystem authority.

Those limits still leave a serious integrity problem. A person choosing a destination directory authorizes a narrower action than allowing writes anywhere their process can reach. The vulnerability expands the action from the selected destination to other writable paths. The archive can influence that expansion without receiving a separate authorization for each outside file.

Docker's CVE classification is improper link resolution before file access, CWE-59. That description fits both the location of the error and its practical effect. The boundary being checked is a directory boundary. The link-following behavior permits the operation to cross it after the string-level decision has already accepted the entry.

I tend to think about Docker through its build and distribution model. Repeatable build files and layered artifacts are the parts I value most. This issue is a reminder that consuming an artifact also invokes a filesystem implementation, and that implementation must enforce the destination requested by its caller.

For someone shipping small service images, the interesting point is the consumer's authority. Reducing the contents of an application image does not determine the permissions of a separate extraction process. The security question here is what that process can modify while handling an archive selected by another party.

Several products share the vulnerable library

Docker's affected-product list starts with moby/go-archive versions before 0.3.0. The same CVE record names Desktop before 4.86.0, Docker Sandboxes before 0.38.0, and Docker Engine before 29.7.0. Docker CLI versions before 29.7.0 and Compose before 5.4.0 also appear in the record.

These version numbers identify separate release lines. Updating one installed product is not evidence that every consumer of the archive library has changed. A machine can have more than one executable involved in Docker workflows, and the record assigns affected ranges to those executables independently. The installed component determines which threshold applies.

The library advisory links both Docker CLI and Moby release material. That is consistent with a defect in shared archive code being relevant in several contexts. It should not be simplified into a claim that the entire problem resides in one graphical Desktop component.

Desktop 4.86.0 bundles Engine 29.7.2 according to its release notes. That version is above the Engine boundary in the CVE record. The Desktop note also names the docker container cp destination escape explicitly, giving Desktop users a direct product-level statement of remediation without requiring them to infer it from dependency versions alone.

The release includes other changes, including Docker VMM beta performance improvements. Those changes do not explain the security mechanism. A faster virtual machine and a confined archive extractor address different properties of the system, even when Docker ships them in the same Desktop update.

The workaround preserves the trust requirement

The published workaround is to extract only trusted archives. That advice follows from the attacker's required control over archive contents. It narrows the inputs reaching the vulnerable implementation, but it does not turn lexical path checks into correct filesystem confinement.

Trust in this context has to cover the contents the extractor will actually process. A familiar command name does not establish that property. In the Desktop release notes, the affected operation is a copy command. The CVE supplies the explanation for why archive handling beneath that operation can produce writes outside the selected destination.

There is no need to publish a malicious archive to explain the lesson. The failure can be understood by separating the requested destination, the pathname accepted by the checker, and the target reached after link resolution. Each describes a different part of the operation. The implementation must keep the final target within the authority represented by the requested destination.

My preference is for the tool to enforce that restriction even when the input is hostile. A destination argument should remain meaningful throughout extraction. Requiring every caller to inspect archive semantics would move a filesystem correctness obligation into applications that chose the library to handle those details.

The distinction is useful when evaluating the workaround as well. Trusted inputs can reduce immediate exposure while updates are pending. They do not provide the same guarantee as an implementation that prevents hostile entries from escaping. Docker's advisory presents trusted archives as a workaround, and the patched versions remain the concrete remediation.

The affected list includes macOS, Linux and Windows for the named Docker products. This is therefore not a claim limited to one host filesystem implementation. The shared code makes a directory-confinement decision that must survive the path resolution performed on each supported platform. Docker identifies a library-level defect and product releases containing its repair, which gives a more useful scope than attributing the issue to virtualization alone.

What the disclosure lets operators establish

The CVE credits Ron Masas of Imperva and other independent reports. It describes the defect in shared extraction routines and identifies affected product ranges. Neither that attribution nor the existence of a public advisory establishes a history of exploitation against deployed systems, so the event should not be presented as evidence of such incidents.

The practical consequence is that archive extraction belongs in the security model of copy and image workflows. Its job includes constraining writes to the intended destination even when entries create links. For Desktop, 4.86.0 is the named fixed release. For other consumers, the corresponding product version in Docker's record determines whether the vulnerable archive code remains in use.