A common mistake is checking only the obvious installed package list and assuming that covers exposure. Many applications use vulnerable archive libraries indirectly through dependencies, so the real risk sits deeper in the software chain. Teams should trace the libraries used by each application, then verify whether any transitive component handles archive extraction unsafely.
Why teams miss Zip Slip exposure in dependency chains
zip slip is often hidden by the way software is assembled. A team can scan the obvious top-level packages, see nothing alarming, and still miss a vulnerable archive library pulled in several layers down through a framework, plugin, or utility module. That is why exposure review has to follow the actual dependency graph, not just the package inventory.
The problem is not limited to one language or packaging model. Archive extraction code can arrive through build tools, update mechanisms, importers, integration adapters, or other indirect paths that do not look security-sensitive at first glance. When you only inspect the named application dependency, you miss the transitive component that actually performs path handling during extraction.
That pattern is easy to underestimate because Zip Slip is an implementation flaw, not a headline feature. The dangerous behaviour usually appears inside normal application workflows, such as unpacking uploads, handling plugin bundles, or processing backup and sync archives. If those workflows are reachable, the weakness matters even when the application owner never knowingly chose the vulnerable library.
For broader context on how archive-related exposure can sit deeper in the software chain, NHIMG’s Guide to the Secret Sprawl Challenge is useful because it shows how security-relevant risk often hides in places teams do not inspect first. The same practical lesson applies here: the risk is frequently in the dependency path, not the surface list.
What actually creates the exposure
Zip Slip exposure exists when archive extraction code fails to validate file paths before writing them to disk. A crafted archive can use relative path tricks to place files outside the intended destination, overwrite application assets, or drop malicious content where it will later be executed or consumed. The vulnerability becomes actionable only when the archive handler is reachable in a real workflow.
Indirect dependencies matter because they carry the extraction logic even when the application team did not write it. In practice, teams need to identify every component that can unpack archives, then determine whether that component normalises paths, rejects traversal sequences, and constrains writes to the target directory. This is especially important in shared libraries that are reused across many services, because one unsafe module can create repeated exposure across the stack.
Teams also get the prioritisation wrong. They sometimes treat all archive libraries as equally relevant, or assume that a package name match is enough to prove exposure. What matters is whether the installed version is reachable, whether the vulnerable code path is invoked, and whether the application accepts attacker-controlled archives. A package can be present without being exploitable, but a transitive dependency can be exploitable even when it is not obvious in the front-line inventory.
NHIMG’s 52 NHI Breaches Analysis is relevant as a comparison point for dependency-driven exposure: it reinforces how hidden components and indirect trust paths can become the real failure point. The lesson for Zip Slip is similar, even though the mechanics differ.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS 2 — Software Inventory and Control | Directly supports tracing installed and transitive software components that may carry Zip Slip risk. |
| CIS 16 — Application Software Security | Applies because Zip Slip is an application-layer file path validation flaw in archive handling. | |
| Recommendation — Maintain an accurate software inventory that includes transitive libraries used by archive-processing code. Review archive extraction code for path normalisation and traversal prevention before release. | ||
| OWASP Agentic AI Top 10 | A1 — Agentic Input and Tool Abuse | Selected only as a close analogue for untrusted input reaching a tool-like file write path through application logic. |
| Recommendation — Treat attacker-controlled archive contents as untrusted inputs that must be constrained before file writes. | ||
| MITRE ATT&CK | T1106 — Native API | Relevant because the weakness abuses normal file write behaviour in the host environment. |
| Recommendation — Hunt for abnormal file-write activity that lands outside the intended extraction directory. | ||
Practitioner Guidance
What to verify: Do not stop at software bill of materials summaries that only show direct dependencies. Confirm which runtime paths actually invoke archive extraction, whether transitive libraries are loaded in production, and whether the affected code is reachable from external input, update channels, or plugin ingestion.
Common mistake: Treating “we do not use that package directly” as a valid closure condition. If the vulnerable extractor is still present in a nested dependency and the application can process attacker-controlled archives, the exposure is still real.
Decision rule: If you can demonstrate that a component unpacks untrusted archives, prioritise path traversal testing and version remediation for that component before relying on inventory hygiene. If the library is only present but unreachable, document that evidence so the finding is not reopened on every scan.
Practitioner takeaway: Zip Slip review is a reachability problem as much as a version problem, so the most useful question is not “is the package installed?” but “which code path actually performs extraction, and can an attacker influence it?”
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
