What are the signs that archive handling code is vulnerable to Zip Slip style attacks?

Look for code that passes archive entry names directly into file constructors or output streams without validating the destination path. Risk increases when the extraction logic lacks canonicalization, does not compare the resolved path to the intended output directory, or accepts user supplied archives in upload flows. These patterns are often subtle in review because the code can look like ordinary file handling.

What archive-handling code gets wrong before Zip Slip becomes possible

zip slip style vulnerabilities usually show up where extraction code trusts archive metadata too much. The biggest warning sign is path handling that treats an entry name as if it were already safe, rather than as attacker-controlled input that must be normalized, constrained, and rechecked before any file is written.

Typical code smells include direct concatenation of the archive entry name onto an output directory, use of relative segments such as ../ or platform-specific path separators without validation, and extraction routines that never compare the resolved destination against the intended base folder. Those patterns often survive review because they look like ordinary file I/O.

Another common indicator is broad support for arbitrary archives in upload or import flows, especially when the handler accepts user-supplied ZIPs, TARs, or nested archives and then extracts them automatically. If the code also preserves entry names, symbolic links, or directory structures without explicit policy checks, the attack surface becomes much wider.

Why canonicalization and destination checks matter

The core defense is to force every extracted path through a normalization step and then prove that the final resolved location still sits under the allowed extraction root. Without that check, a crafted entry can escape the target directory even if the code appears to be writing into a safe folder.

Good handling logic treats archive entry metadata as untrusted, not merely inconvenient. The code should resolve the candidate path, compare it to the intended output base, and reject anything that traverses outside the boundary. That same discipline should apply before creating parent directories, opening file handles, or unpacking nested content.

Archive handling also becomes fragile when extraction code is written for one filesystem assumption and then deployed on another. Path separator differences, case sensitivity, absolute paths, and link semantics can all change whether a filename is safe or dangerous, so a routine that “works in testing” may still be exploitable in production.

Review clues that the vulnerability is real, not hypothetical

When reading code, look for whether the implementation makes the safety decision before file creation or after it. If the destination path is assembled first and checked later only in a superficial way, that is a strong indicator of exploitable logic rather than defensive handling.

Also look for helper methods that sanitize names cosmetically but do not enforce a strict containment rule. Stripping a few characters is not enough if the final path can still escape the directory tree, and rejecting only obvious ../ strings misses encoded, nested, or platform-specific traversal forms.

Finally, pay attention to the surrounding workflow. If archives come from uploads, integrations, synchronizers, backup restores, or package managers, the code is more likely to process untrusted content at scale. In that situation, a path traversal bug is not just a coding defect, it is a file-write primitive that can overwrite application files, drop executables, or plant persistence.

Risk and Threat Considerations

Zip Slip style bugs are dangerous because they convert a routine archive import into arbitrary file write behavior. Once an attacker can influence where extracted files land, they can overwrite configuration, plant scripts, replace application assets, or prepare a follow-on execution path.

Failure mechanism: the extractor trusts archive entry names, fails to canonicalize the destination, or compares the wrong path representation, allowing traversal outside the intended directory.

Impact: successful exploitation can lead to file overwrite, webshell or payload placement, configuration tampering, denial of service, or chained compromise if the written path is later executed or loaded.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5, OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	SI-10 — Information Input Validation	Archive path handling depends on validating untrusted entry data before use.
	AC-3 — Access Enforcement	Extraction must enforce a hard boundary on where files may be created.
Recommendation — Validate archive-derived paths before writing extracted files. Enforce destination containment so extracted files cannot escape the allowed directory.
OWASP ASVS	V5 — File Handling	The issue is unsafe processing of uploaded archive files and extracted paths.
Recommendation — Apply secure file-handling checks to archive extraction and path resolution.
CIS Controls v8	CIS-16 — Application Software Security	Safe archive extraction is a software security control that needs testing and review.
Recommendation — Test archive extraction code for traversal and unsafe write behavior.
MITRE ATT&CK	T1105 — Ingress Tool Transfer	Malicious archives can deliver payloads that are written into attacker-chosen paths.
Recommendation — Hunt for payload delivery paths that rely on archive extraction to place files.

Practitioner Guidance

What to verify: inspect the exact write path logic, not just the input validation layer. A secure implementation should resolve the final path, enforce base-directory containment on the resolved value, and reject any archive entry that breaks that invariant before opening a stream.

Common mistake: teams often believe filename filtering is enough. It is not, because the dangerous condition is the final destination after normalization, not the visible string in the archive record.

Decision rule: if the code accepts user-controlled archives, treat extraction as a security boundary and require path containment, link handling rules, and test coverage for traversal cases before approving the feature.

Practitioner takeaway: the safest archive handler is one that proves every extracted file remains inside the intended directory, because any gap in that proof is what turns a benign import into a file-write exploit.