What breaks when archive extraction trusts symlink chains inside untrusted files?

Why symlink-aware archive extraction turns into a boundary problem

The core issue is that extraction logic cannot rely on the visible archive path alone. If an attacker can place symlinks inside the archive, a destination that appears to stay inside the target tree may resolve elsewhere when the filesystem follows the link chain. The security boundary is therefore the resolved filesystem target, not the string that was parsed.

That distinction matters because unpacking code often validates names before it writes. If resolution happens later, or on a different path element than the validator considered, the extractor can be tricked into treating an external location as if it were local output.

When that happens, the operation stops being a normal file restore flow and becomes a write primitive controlled by archive contents. The failure is not that the path parser was confused, but that the enforcement point trusted a path that had not yet been fully resolved.

How the bypass happens in practice

A common pattern is a nested chain, where one extracted entry creates or points to a link and a later entry writes through that link. A lexical check may accept dest/subdir/file, but if subdir resolves through a planted symlink, the final write lands outside the intended root.

The same class of bug appears when extraction code checks for .. traversal but does not verify each filesystem hop during open or create. The danger comes from path components that are benign in text form yet unsafe after resolution. Robust handling has to treat every intermediate directory as part of the trust decision.

This is why archives, container layers, backup restores, and build artifacts need resolution-aware handling rather than string sanitation alone. If the extractor cannot prove that the final inode remains under the destination root, the archive entry is not safe to materialize.

What safe extraction has to verify before writing

Safe extraction has to validate the resolved destination, not just the archive member name. That means checking whether the target stays under the allowed root after following links, and refusing writes when the path escapes the boundary or when a pre-existing object changes the intended resolution.

Where possible, extract into a fresh directory tree with minimal pre-existing contents, and avoid following symlinks for directories or final write targets. If your platform and library support it, prefer APIs and options that resolve and constrain the path at open time rather than after the file is already created.

Federation and Trust Relationships Guide is useful here as a trust-boundary analogue: the same discipline applies when a supposedly local path can redirect authority somewhere else.

Risk and Threat Considerations

Symlink-chain abuse turns archive extraction into a boundary escape, which can overwrite configuration, plant executables, or place files in locations the extractor was never meant to reach. The practical risk is not limited to accidental corruption, because the same primitive can be used to stage persistence or to overwrite security-sensitive files during unpacking.

Failure mechanism: The extractor validates the archive path before the filesystem resolves planted links, so the final write occurs outside the intended destination tree.

Impact: An attacker can write to arbitrary reachable locations, corrupt data, or replace files that influence execution, access control, or later build and deployment steps.

Practitioner Guidance

What to verify: Confirm that your extraction path enforcement happens on the resolved filesystem target, not on the raw archive name. Test with archives that contain nested symlinks, pre-existing directories, and link chains that point outside the destination root.

Decision rule: If the library or wrapper cannot prove containment at open time, treat archive extraction as unsafe for untrusted inputs and switch to a safer extraction strategy or a hardened library path.

Common mistake: Do not assume that rejecting .. segments is enough. That blocks one traversal pattern, but it does not stop symlink resolution from redirecting a later write.

Practitioner takeaway: The control objective is filesystem boundary enforcement after resolution, because archive safety depends on where the path ends up, not where it first appears to point.

Related resources from NHI Mgmt Group

• What breaks when an AI browser can read local files inside a user session?
• What breaks when a workflow engine can execute untrusted code inside the same environment that stores secrets?
• What breaks when untrusted code runs inside a vm2 sandbox that relies on sanitization?
• What breaks when an API parser accepts untrusted XML inside a JSON workflow?