A Zip Slip vulnerability in the Golang package go-rpmutils could have allowed attackers to write arbitrary files outside intended directories during archive extraction. The vulnerability, tracked as CVE-2020-7667, was published on June 5, 2020—just six days after Snyk's Security Research Team first notified the maintainer.
Six days. That's exceptional for vulnerability disclosure, especially in open source. The median time from disclosure to patch is often weeks or months, not days. What made this different was the effective communication path.
What Happened
Snyk's researchers discovered a Zip Slip vulnerability in go-rpmutils, a Go package used for reading and writing RPM packages. Zip Slip vulnerabilities occur when archive extraction code fails to validate file paths, allowing an attacker to craft a malicious archive that writes files outside the intended extraction directory. An attacker could include paths like ../../etc/cron.d/malicious in an archive entry, potentially achieving code execution or overwriting critical system files.
The researchers contacted SAS Software, the package maintainer, to report the issue. Their initial email went to an incorrect address but was quickly forwarded to the right team. The maintainer responded, patched the code, and coordinated publication—all within six days.
Timeline
Day 0 (May 30, 2020): Snyk Security Research Team identifies the Zip Slip vulnerability in go-rpmutils.
Day 0: Initial notification sent to SAS Software via email.
Day 0: Email forwarded internally to the correct security contact.
Day 1-5: Coordination between Snyk and SAS Software on patch development and testing.
Day 6 (June 5, 2020): CVE-2020-7667 published; patched version released.
This timeline represents what responsible disclosure should look like when both parties have the right infrastructure in place.
Which Controls Failed or Were Missing
This incident didn't stem from a catastrophic control failure—it demonstrates what happens when controls work correctly. However, the initial email mishap reveals a common gap: no dedicated, well-documented vulnerability disclosure channel.
Many projects rely on generic contact addresses (info@, support@) or bury security contact information in documentation. When a researcher finds a critical flaw, they shouldn't have to guess which email might reach someone who cares. The fact that SAS Software's team forwarded the message quickly prevented this from becoming a problem, but that's organizational luck, not process.
The vulnerability itself represents a different control gap: insufficient input validation during archive extraction. The code didn't sanitize file paths before writing extracted files to disk. This is a classic implementation flaw that appears across languages and frameworks.
What the Relevant Standards Require
ISO/IEC 27001:2022 Annex A.5.23 requires organizations to establish "information security for use of cloud services," which includes vulnerability management processes for third-party dependencies. More directly, A.8.8 covers "management of technical vulnerabilities" and requires organizations to obtain information about technical vulnerabilities, evaluate exposure, and take appropriate measures.
NIST 800-53 Rev 5 SI-5 (Security Alerts, Advisories, and Directives) requires organizations to receive security alerts and advisories, but the inverse—providing a channel for others to send you alerts—falls under RA-5 (Vulnerability Monitoring and Scanning) and SI-2 (Flaw Remediation). SI-2(2) specifically addresses "automated flaw remediation status" and implies you need a process to receive flaw reports in the first place.
PCI DSS v4.0.1 Requirement 6.3.3 states: "Security vulnerabilities are identified and addressed as follows: New security vulnerabilities are identified using industry-recognized sources for security vulnerability information." This includes monitoring your own code and dependencies. Requirement 6.3.2 requires an inventory of bespoke and custom software and third-party components—you can't manage vulnerabilities in packages you don't know you're using.
For vulnerability disclosure specifically, ISO/IEC 29147:2018 (Vulnerability Disclosure) provides the framework. While not universally mandated, it's referenced by many compliance regimes. It requires:
- A clear disclosure policy
- A documented point of contact
- A process for receiving, triaging, and responding to vulnerability reports
- Defined timelines for acknowledgment and resolution
The go-rpmutils incident succeeded because SAS Software had the informal equivalent of these elements, even if they weren't formally documented.
Lessons and Action Items for Your Team
1. Create a security.txt File
Implement RFC 9116 by placing a security.txt file at /.well-known/security.txt on your domain. Include:
Contact: [email protected]
Expires: 2025-12-31T23:59:59z
Preferred-Languages: en
Canonical: https://yourcompany.com/.well-known/security.txt
This is a standardized way for researchers to find your security contact. It takes 10 minutes to implement and eliminates the "where do I report this?" problem.
2. Document Your Disclosure Process
Write a public vulnerability disclosure policy. Include:
- How to report (email, web form, PGP key if you use it)
- What to expect: acknowledgment within 2 business days, updates every 5 business days
- Your remediation timeline targets (e.g., critical issues within 30 days)
- Whether you offer a bug bounty (if not, say so)
Publish this at /security or /vulnerability-disclosure on your main domain.
3. Assign a Disclosure Coordinator
Designate someone to monitor your security inbox. This doesn't need to be a full-time role, but it needs to be someone's explicit responsibility. Set up alerting so reports don't sit unread for days.
4. Map Your Dependency Tree
You can't respond to vulnerability reports about packages you don't know you're using. Run go mod graph, npm ls, or your language's equivalent. Export this to a dependency tracking system. When CVE-2020-7667 was published, could you have answered "do we use go-rpmutils?" in under five minutes?
5. Validate Archive Extraction Everywhere
If your code extracts archives (ZIP, TAR, RPM, anything), audit it for Zip Slip vulnerabilities. Every extracted file path must be validated:
// Check that the resolved path is within the target directory
if !strings.HasPrefix(filepath.Clean(targetPath), filepath.Clean(destDir)) {
return fmt.Errorf("illegal file path: %s", targetPath)
}
This applies to CI/CD pipelines, build scripts, deployment automation—anywhere you unpack archives.
6. Test Your Disclosure Path Annually
Ask a trusted colleague or external consultant to submit a test vulnerability report. Did they find your contact information easily? Did they get an acknowledgment? This is the only way to verify your process works.
The go-rpmutils incident went well because people responded quickly and communicated clearly. But "people responded" isn't a control—it's luck. Build the process so the next researcher doesn't have to get lucky.
