What Happened
In early 2018, Snyk's security research team discovered a directory traversal vulnerability in archive extraction code affecting thousands of projects across multiple ecosystems. The vulnerability—designated CVE-2018-8008 for Apache projects—allowed attackers to write files outside the intended extraction directory by crafting malicious archive filenames with path traversal sequences like ../../evil.sh.
More than half of the Java, JavaScript, and Go libraries Snyk initially examined contained the flaw. The vulnerable pattern had spread through community code-sharing platforms, particularly StackOverflow, where developers copied and adapted extraction snippets without understanding the security implications.
Timeline
- Early 2018: Snyk research team identifies the vulnerability pattern across multiple language ecosystems.
- Private disclosure begins: Snyk contacts affected maintainers, including Apache Software Foundation and other major open source projects.
- 60-day remediation window: Teams work to patch vulnerable libraries before public disclosure.
- June 5th, 2018: Coordinated public disclosure after fixes are available.
Which Controls Failed or Were Missing
The Zip Slip incident reveals three control failures:
Secure development lifecycle gap: Projects lacked input validation requirements for archive extraction operations. The vulnerable code accepted user-supplied path components without canonicalization or boundary checks.
Third-party component management: Organizations using affected libraries had no inventory of which dependencies performed archive extraction, making impact assessment impossible until the CVE was published.
Vulnerability coordination process: Many projects had no documented security contact or disclosure policy. Snyk had to locate maintainers through GitHub profiles, mailing lists, and personal networks—a manual process that doesn't scale when coordinating fixes across hundreds of projects.
What the Standards Require
PCI DSS v4.0.1 Requirement 6.3.2 mandates that software engineering techniques include "review of custom code prior to release to production" to identify security vulnerabilities. The vulnerable extraction pattern should have been caught during code review, but the requirement assumes reviewers know what to look for. Without secure coding training that covers directory traversal in archive handling, reviews miss these issues.
OWASP ASVS v4.0.3 Section 12.5.1 requires that "file and resource filenames and URL parameter values are validated to ensure they do not contain directory traversal patterns." This applies directly to archive extraction—every filename in the archive is untrusted input that must be validated before use.
ISO 27001 Control 8.31 (Security of information in use) requires organizations to "identify and apply appropriate security measures for information during processing, storage and transmission." Archive extraction is processing untrusted data, and the standard requires you to identify and mitigate the risks. But it doesn't specify how, leaving teams to figure out what "appropriate measures" means for their context.
NIST 800-53 Rev 5 Control SI-10 (Information Input Validation) states that systems must "check the validity of information inputs." The control enhancement SI-10(3) adds that input validation should occur at "multiple defined locations" in the application. For archive handling, this means validating both the archive structure and individual file paths.
The gap: None of these standards explicitly mention archive extraction vulnerabilities. Security teams must translate general input validation requirements into specific technical controls for each data processing operation their applications perform.
Lessons and Action Items for Your Team
Create a Vulnerability Disclosure Policy
If you maintain any code that others use—internal libraries, open source projects, or APIs—publish a security.txt file or SECURITY.md with a contact method. Snyk spent significant time just finding the right people to notify. Make yourself easy to contact.
Your policy should specify:
- Security contact email (not a general support queue)
- Expected response time (24-48 hours for initial acknowledgment)
- Preferred disclosure timeline (typically 90 days, but negotiate case-by-case)
- Whether you participate in bug bounty programs
Audit Your Archive Handling Code
Search your codebase for these functions:
- Java:
ZipInputStream.getNextEntry(),JarInputStream - JavaScript:
unzip,tar.extract() - Go:
archive/zip,archive/tar - Python:
zipfile.extractall(),tarfile.extractall()
For each instance, verify that the code validates extracted file paths before writing to disk. The validation must:
- Resolve the full path after combining extraction directory and archive filename.
- Verify the resolved path starts with the extraction directory.
- Reject any path that escapes the boundary.
Don't write this validation yourself—use your language's standard library functions. In Java, use Path.normalize() and Path.startsWith(). In Python, use os.path.commonpath() to verify both paths share a common ancestor.
Map Your Vulnerability Response Process to SI-2
NIST 800-53 Rev 5 Control SI-2 (Flaw Remediation) requires you to "identify, report, and correct system flaws." For third-party vulnerabilities like Zip Slip, this means:
SI-2a: Install security-relevant updates within defined timeframes. Define what "security-relevant" means for your organization. Is directory traversal in a library you use for log file analysis critical? What if that library processes user uploads?
SI-2(2): Automate flaw remediation status tracking. Your dependency scanning tool should track when CVEs are published, which of your applications are affected, and which teams own the remediation work. If you're manually checking CVE feeds and cross-referencing SBOMs, you can't meet a 60-day remediation window for widespread vulnerabilities.
SI-2(6): Remove previous versions after updates are installed. Zip Slip affected library versions, not applications. If you update the library in your main branch but leave vulnerable versions in maintenance branches or container images, you haven't fixed the vulnerability—you've just moved it.
Learn from the Community Platform Problem
StackOverflow answers containing the vulnerable pattern received thousands of upvotes because the code worked for the functional requirement (extract this archive). Security was invisible until it failed.
When your team references community code:
- Search for the pattern plus "security" or "vulnerability"
- Check if the answer's comment thread mentions security issues
- Verify the code against OWASP guidance for that operation type
- If you adapt the code, document where it came from so you can track future disclosures
Better: Build an internal library of vetted code patterns for common operations like archive extraction, file uploads, and authentication. When developers need to implement these operations, they use your secure version instead of searching StackOverflow.
Prepare for the Next Coordinated Disclosure
Zip Slip provided a 60-day window between private notification and public disclosure. That's generous—many researchers disclose after 90 days regardless of fix status, and some use shorter windows for actively exploited vulnerabilities.
Build your response process now:
- Who receives vulnerability notifications? (Don't rely on a single person)
- How do you assess impact across your application portfolio?
- What's your SLA for patching critical third-party vulnerabilities?
- How do you communicate status to customers if you can't fix within the disclosure window?
The next widespread vulnerability might give you 30 days, or 7 days, or might already be exploited when disclosed. Your response speed depends on preparation, not heroics.
