If your app downloads and extracts archives, content packs, updates, user uploads, there is a classic vulnerability waiting if you trust the file names inside them: Zip Slip. An archive entry whose name contains directory-traversal sequences can, when extracted naively, write a file outside the folder you intended, overwriting other files, app data, or even code. The fix is simple but easy to miss: validate each entry's destination before writing it. Here is what Zip Slip is, how it happens, and how to extract archives safely.
Short answer
Zip Slip is a vulnerability where extracting an archive whose entry names contain directory-traversal sequences, such as paths with .., writes files outside the intended extraction directory, because the extraction code trusts the entry's path. Per OWASP, this can let an attacker overwrite arbitrary files, including app data or code, leading to data corruption or worse. It applies to any mobile app that extracts archives it downloads or receives. The fix is to validate, for each entry, that its resolved destination path stays within the target directory before writing, and to reject entries with traversal sequences or absolute paths. Never extract an archive entry to a path you have not confirmed is safe.
What you should know
- Zip Slip exploits entry paths: a crafted entry name escapes the extraction folder.
- It causes arbitrary file write: overwriting files outside the intended directory.
- It affects archive extraction: zip, tar, or similar, in any app that extracts them.
- Validate the destination: confirm each entry resolves inside the target directory.
- Reject traversal and absolute paths: entries with
..or absolute paths.
What is Zip Slip?
It is a directory-traversal vulnerability in archive extraction. An archive stores each file with a name, and that name can include path components, including traversal sequences like .. that move up the directory tree. When extraction code takes the entry name and joins it to the target directory without checking, a malicious entry named to traverse upward causes the extracted file to be written outside the intended folder. So an archive that looks like it contains ordinary files can actually write to locations the app did not intend, the classic example being an entry path that escapes the extraction directory to overwrite a file elsewhere in the app's storage. The vulnerability is not in the archive format; it is in trusting the entry path during extraction, which makes it a member of the broader path-traversal family applied to archives.
How does it happen, and what is the impact?
It happens when extraction trusts the entry path, and the impact is arbitrary file write. The table outlines it.
| Step | What happens |
|---|---|
| Archive with a crafted entry | An entry name contains traversal sequences or an absolute path |
| Naive extraction | The code joins the entry name to the target directory without checking |
| File written outside the target | The traversal escapes the intended folder |
| Impact | Overwriting app data, configuration, or code; corruption or compromise |
The impact depends on what the escaped write can reach: overwriting the app's own data or configuration can corrupt state or change behavior, and in some cases an attacker who can overwrite executable or loadable content can achieve more serious compromise. The trigger is an archive the app extracts, downloaded content, an update package, a user-supplied file, combined with extraction code that does not validate where each entry lands. So any app that extracts archives without checking entry paths is potentially exposed.
How do you extract archives safely?
Validate every entry's destination before writing it. For each entry in the archive, compute the full destination path by joining the entry name to your target directory, resolve it to a canonical form, and confirm it is still inside the target directory before writing, rejecting any entry whose resolved path escapes the directory. Reject entries containing traversal sequences or absolute paths outright, and do not create files or directories from an entry until the path check passes. Where possible, use a well-maintained extraction library or platform API that performs this validation for you, rather than hand-rolling extraction, since the safe behavior is easy to get wrong. Treat the archive and its entry names as untrusted input, the same as any external data, since that is exactly what they are. The principle is that the destination of every extracted file must be one you confirmed is within the intended directory, never one the archive dictates unchecked.
What to watch out for
The first trap is joining an entry name to the target directory and writing without checking, which is the Zip Slip bug; validate the resolved destination first. The second is trusting an archive because it came from your own server, when it could be tampered in transit or compromised at the source; treat entry paths as untrusted. The third is hand-rolling extraction instead of using a vetted library that validates paths. Zip Slip is a code-level input-handling flaw, so a pre-submission scan such as PTKD.com (https://ptkd.com), which reads the binary against OWASP MASVS, assesses input and data handling broadly, while the path validation is something you implement in your extraction code.
What to take away
- Zip Slip is when extracting an archive with crafted entry paths writes files outside the intended directory, because extraction trusts the entry name.
- The impact is arbitrary file write, which can overwrite app data, configuration, or code and lead to corruption or compromise.
- Validate each entry's resolved destination is inside the target directory before writing, reject traversal and absolute paths, and prefer a vetted extraction library.
- Treat archive entry names as untrusted input, and use a pre-submission scan such as PTKD.com to assess your app's input and data handling.
