Look for version disclosures in public assets, archive handling endpoints, and server responses that change when a crafted ZIP is submitted. A successful but unauthorized request may return an unusual error, yet still write files to disk. Publicly reachable folders that can later serve uploaded content are a strong indicator that exploitation may be possible.
What a zip slip vulnerability looks like in practice
A zip slip issue is usually visible through the application’s handling of uploaded archives, not through the archive file alone. The most useful clue is a path handling weakness: file extraction follows entries like ../, absolute paths, or other traversal patterns instead of constraining writes to a safe directory. In a web app, that often shows up around import features, backups, plugins, and document upload workflows.
When a ZIP is processed, a vulnerable application may extract files outside the intended folder, overwrite an existing file, or place content somewhere later served by the web server. That is why archive handling belongs in the same threat class as other file upload and path traversal problems, and why teams should test it with the same discipline they use for input validation and server-side file handling in OWASP Top 10.
Good indicators also include inconsistent responses across similar archives. A harmless ZIP may be accepted, while a crafted archive returns an error, times out, or reports partial success. If the application changes behavior when path traversal entries are present, or if you can infer that a file was written even after an apparent failure, the extraction logic deserves immediate review. Public upload targets, archive preview endpoints, and any feature that stores extracted content for later retrieval are especially important because they can turn a write primitive into a reachable web asset.
What response patterns and artefacts suggest exploitation is possible?
The strongest signs are behavioural. A request that submits a crafted ZIP may trigger unusual server responses, yet still leave behind modified files, new content in an upload directory, or overwritten application assets. If the application discloses storage paths, version details, or destination folders in error text, that often helps confirm the sink point and the extent of exposure.
Look for outputs that reveal where files landed, whether the extraction path was normalized, and whether the server accepted names that should have been blocked. If a ZIP entry can create or replace files in a publicly reachable directory, the issue is no longer limited to archive parsing. It becomes a web exposure problem because the written file may be executed, rendered, downloaded, or used as a follow-on foothold. That is the practical difference between a harmless upload bug and a real OWASP Web Security Testing Guide testing finding.
Another common clue is partial success. The application may report a validation or extraction error, but one or more entries still appear on disk. That mismatch usually means the server processed entries sequentially and failed to stop when it encountered a dangerous path. When you see that pattern, treat it as a likely file write risk, not as a benign exception path.
If the application serves extracted files from a web root, the risk can become immediately exploitable. A ZIP that writes HTML, script, template, or configuration files into a served location may create a second-stage attack path even if the original archive upload looked routine. In mature testing, that is often the point where the defect moves from “path traversal evidence” to “probable impact.”
Which conditions make a zip slip flaw materially exploitable?
Zip slip becomes materially exploitable when three conditions overlap: untrusted archive content, unsafe path construction, and a write target that matters. A vulnerable extractor alone is not always enough. The issue becomes serious when the application writes outside its intended directory, overwrites sensitive files, or places output where the web server or another process can consume it.
Operationally, the most dangerous pattern is a reachable upload or import feature that accepts archives and then extracts them without strict path canonicalization. If the destination is predictable, writable, and later served back to users, the attacker may only need one successful upload to gain persistent impact. That is why secure extraction must be treated as a file-system control, not just an input filter. The same mindset is reflected in application verification standards such as OWASP ASVS.
From a defensive perspective, do not focus only on whether the archive was accepted. Check whether the extracted file path was normalized, whether unexpected parent directory segments were stripped, and whether the destination directory is isolated from executable or user-facing locations. If the app allows user-controlled archive names, nested paths, or symlink-like behaviour, those are additional warning signs. For implementation teams, safe extraction is not optional hardening, it is the control that prevents a simple upload feature from becoming arbitrary file write.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V2 — Validation and Business Logic | Zip slip is caused by unsafe handling of untrusted archive paths. |
| V5 — File Handling | The flaw is a file write and extraction control failure in the web app. | |
| V15 — Secure Coding and Architecture | Secure extraction requires defensive design around file-system boundaries. | |
| Recommendation — Validate extracted paths and reject traversal before any file write occurs. Constrain archive extraction to a safe directory and block path traversal. Design upload and extraction flows so untrusted archives cannot affect protected paths. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | Zip slip is an input-validation failure that permits unsafe file paths. |
| AC-6 — Least Privilege | Limiting write permissions reduces impact if archive extraction is abused. | |
| Recommendation — Reject archive entries that resolve outside the intended destination path. Restrict the extractor account to the minimum write access needed. | ||
Practitioner Guidance
What to verify: Confirm whether extraction is constrained by canonical path checks and whether dangerous entries are rejected before any file is written. If the application reports an error but any files still appear on disk, treat that as a failed control, not a partial success.
What to prioritise: Focus first on any archive-handling endpoint that writes into a web-accessible or shared directory. That is where path traversal turns into the highest-impact outcome, because the written file can become visible, executable, or reusable by another process.
Common mistake: Teams often validate only the upload request and ignore the extraction stage. A ZIP can be syntactically valid, yet still carry traversal paths that become dangerous only when the server unpacks it.
Practitioner takeaway: The sign that matters is not simply that a ZIP was uploaded, but that the application accepted archive content in a way that changed server-side file placement, especially when the resulting path is reachable or executable.
Related resources from NHI Mgmt Group
- What are the signs that archive handling code is vulnerable to Zip Slip style attacks?
- How should security teams use exploit validation to prioritise vulnerability remediation in web application and API environments?
- What are the signs that cache key normalization is failing in a web application?
- What are the signs that resource level authorization is not working correctly in a web application?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
