Zip Slip is a path traversal vulnerability that occurs when an app extracts an archive, such as a zip or tar file, and trusts the file paths inside it, so a malicious archive entry whose name contains parent-directory sequences can escape the intended extraction folder and write a file somewhere else. In an Android app that unpacks archives, this can overwrite files in the app's private storage, corrupting its data or configuration, or in some designs replacing code or resources the app loads, which turns a simple extraction into a way to tamper with the app. The fix is to validate that each extracted entry's resolved, canonical path stays inside the target directory before writing it, and to reject any entry that would escape. Static analysis scanners can flag unsafe extraction automatically, which is the fastest way to find it across a codebase.
Short answer
Zip Slip lets a crafted archive write files outside the extraction directory because the app trusts the archive's paths. Per the OWASP MASVS, apps must handle file paths and untrusted input safely, and archive extraction that does not validate entry paths violates that. The exploit works when a malicious entry name includes parent-directory sequences that escape the target folder, so the fix is to resolve each entry's canonical path and confirm it stays within the intended directory before writing, per Android's data storage guidance. Test it only on your own app with a crafted archive in isolation, and use a scanner such as MobSF or a build scanner to detect unsafe extraction automatically.
What Zip Slip path traversal is
Zip Slip is a specific form of path traversal, the class of vulnerability where untrusted input controls a file path and reaches outside the location it should be confined to. In Zip Slip, the untrusted input is the file names stored inside an archive. When an app extracts an archive, it reads each entry's name and writes the entry's contents to a path built from that name inside a target directory. If the app trusts the entry name and it contains parent-directory sequences, the resulting path can point outside the target directory, so the file is written somewhere the app did not intend.
The vulnerability is in the extraction code, not the archive format itself, because archives can legitimately contain any path, and it is the app's responsibility to refuse dangerous ones. So a Zip Slip issue exists whenever an app unpacks an archive without checking that each extracted file lands inside the intended folder.
How archive extraction is exploited in an app
Archive extraction is exploited by crafting an archive whose entry names are designed to escape the target directory, so understanding the mechanism helps you defend against it without needing a payload. An attacker creates an archive containing an entry whose name uses parent-directory sequences to point outside the folder the app extracts into, and when the app extracts it and writes that entry using the untrusted name, the file lands at the attacker-chosen location rather than inside the target. The attacker controls both the destination and the contents of that written file.
The impact depends on what the app extracts and where. If your app downloads or receives an archive from an untrusted source and unpacks it, an attacker who can supply a malicious archive can write files into your app's storage outside the extraction directory, overwriting existing files. Depending on the app's design, that can corrupt saved data or configuration, replace files the app reads at runtime, or, in the worst cases where the app loads code or resources from a writable location, influence what the app runs.
Android file permissions and why it matters
On Android, the app sandbox and its private storage are what make a Zip Slip write consequential, so the file permission structure matters to the impact. Each app has a private data directory that only that app can access, containing its databases, shared preferences, and files, and an Android app typically extracts archives into a subdirectory of that private storage. Because the app itself has full read and write access to its own private directory, a Zip Slip write escaping the extraction subfolder can reach other files in the app's private storage, the very data the sandbox is meant to protect from other apps but not from a bug in this app.
This is why the sandbox does not save you from Zip Slip. The sandbox isolates your app's data from other apps, but a path traversal within your own app writes as your app, so it can overwrite your own sensitive files, config, or cached content, all of which the app is permitted to modify. Understanding the file permission structure clarifies the risk: the danger is not writing to another app's data, which the sandbox blocks, but writing to your own app's protected files in ways you did not intend, which the sandbox permits because the write comes from your app. Confining extraction to a validated path is what keeps writes where they belong.
The fix: validate the canonical path
The fix for Zip Slip is to validate each extracted entry's path before writing it, ensuring it resolves to a location inside the intended target directory. For every entry, build the destination path from the target directory and the entry name, then resolve it to its canonical form, which collapses any parent-directory sequences, and check that this canonical path still begins with the canonical path of the target directory. If it does, the file is safe to write; if it does not, the entry is trying to escape and you reject it rather than writing it.
This canonical-path check is the standard defense, and it neutralizes the parent-directory trick because resolving the path exposes where it actually points, regardless of how the entry name is constructed. Prefer a well-maintained extraction library that performs this validation for you, since reimplementing extraction is where the vulnerability creeps in, and confirm that the library actually guards against traversal rather than assuming it does. Extract into an isolated directory, validate every entry, and refuse anything that resolves outside it, and Zip Slip is closed.
Testing your own app safely
Testing whether your app is vulnerable is a legitimate exercise you do only against your own app, in an isolated environment. Create a test archive containing an entry whose name would escape the extraction directory, then have your own app extract it on a device or emulator you control that holds no real data, and observe whether the file lands outside the target folder or is correctly rejected. If it escapes, your extraction code is vulnerable and needs the canonical-path validation; if it is rejected, your defense works.
Keep the exercise bounded and constructive. Only test applications you have the right to test, use a disposable environment so a successful write does not damage anything real, and use the result to fix the extraction code rather than to attack anything.
Tools to spot path traversal automatically
Because Zip Slip follows a recognizable code pattern, static analysis tools can flag it automatically, which is the fastest way to find it across an app. A mobile static analysis tool inspects your app's code for unsafe patterns, including archive extraction that writes entries without validating their paths, and reports the location so you can review and fix it. Running such a scan over your build surfaces the issue without you having to read every extraction call by hand, which is valuable in a large codebase or one with third-party libraries.
The open-source MobSF performs this kind of static analysis, and build scanners that map findings to security standards can flag insecure file handling and path traversal patterns as well. Automated detection is a first pass rather than a complete guarantee, since a scanner may not follow every code path and a manual review of your extraction logic is still worthwhile, but it reliably catches the common naive-extraction pattern that causes Zip Slip. So combine an automated scan to find candidates quickly with a manual check of your extraction code and the canonical-path fix to close them.
Vulnerable versus safe extraction
Comparing the two clarifies what changes. The table below sets them side by side.
| Aspect | Vulnerable extraction | Safe extraction |
|---|---|---|
| Entry path handling | Trusts the archive's entry name | Resolves and validates the canonical path |
| Parent-directory sequences | Followed, escaping the target | Rejected before writing |
| Result | Writes files outside the target directory | Every file stays inside the target |
| Detection | Missed without review | Flagged by a static analysis scanner |
Read the table by the entry-path row: trusting the archive's path is the root of Zip Slip, and validating the resolved canonical path is what fixes it.
Remediation checklist
Working through these steps closes a Zip Slip vulnerability. The checklist below covers them.
| Step | Action | Done? |
|---|---|---|
| Validate the canonical path | Confirm each entry resolves inside the target directory | [ ] |
| Reject traversal entries | Refuse any name that escapes the folder | [ ] |
| Use a safe library | Prefer extraction code that guards against traversal | [ ] |
| Isolate the extraction | Extract into a dedicated, isolated directory | [ ] |
| Scan the build | Detect unsafe extraction automatically | [ ] |
| Test on your own app | Verify with a crafted archive in isolation | [ ] |
The step that closes the vulnerability is validating the canonical path, since it neutralizes the escape regardless of how the malicious entry name is built.
Scan your app for unsafe extraction
Because Zip Slip hides in a common extraction pattern that is easy to miss by eye, especially in third-party code, scanning your build is the reliable way to find it across the app rather than one call at a time.
A scanner like PTKD.com analyzes your build and reports issues such as insecure file handling, path traversal patterns, and other weaknesses by severity, mapped to OWASP MASVS, so unsafe archive extraction is flagged for you to fix. To be clear about the boundary: PTKD does not patch your extraction code or run a live exploit; it identifies the pattern and the location. It gives you a fast, standard-aligned way to spot path traversal automatically, which you then close with the canonical-path validation in your own code.
What to take away
- Zip Slip is a path traversal vulnerability where an app trusts the file names in an archive, so a malicious entry with parent-directory sequences escapes the extraction directory and writes elsewhere.
- In an Android app, an escaped write reaches other files in the app's private storage, because the write happens as your app, which the sandbox permits, so the sandbox does not protect you.
- The exploit works by crafting an archive whose entry name points outside the target folder, turning extraction into a controlled file write.
- Fix it by resolving each entry's canonical path and confirming it stays inside the target directory before writing, rejecting anything that escapes, and prefer a library that does this.
- Detect it automatically with a static analysis tool like MobSF or a build scanner such as PTKD.com, and test your own app with a crafted archive in isolation.
