When detection happens before merge, the vulnerable change can be blocked, fixed, and re-reviewed before it reaches customers. That shortens remediation, reduces release risk, and avoids incident response work after deployment. It also preserves delivery speed because the repair happens inside the normal engineering workflow rather than through a separate emergency patch cycle.
Why pre-merge detection changes the zip slip outcome
When a zip slip issue is caught in a pull request, the problem is still in source control rather than in a released artifact. That changes the response from containment and recovery to correction and review. A team can reject the change, replace the unsafe extraction logic, and keep the vulnerable pattern out of the build pipeline, which is why early detection is materially different from discovering the flaw after deployment. For a control-oriented view of why review gates matter, see NIST SP 800-53 Rev 5 Security and Privacy Controls. In practice, many teams only learn the true cost of zip slip after a release review has already accepted the unsafe archive handling.
That matters because zip slip is not just a code-quality issue. It is a path traversal weakness that can turn a routine archive operation into file overwrite, configuration tampering, or deployment compromise if it ships. Catching it before merge preserves the normal engineering cadence, but only if the review process treats archive handling as a security-sensitive code path rather than a low-risk utility function.
What reviewers should verify in the patch itself
The practical question is not whether the archive code looks tidy, but whether it prevents extracted files from escaping the intended destination. Safe handling usually means normalising paths, rejecting traversal sequences, and validating that each candidate file remains inside the approved extraction root after resolution. The review should also check any helper methods that wrap archive extraction, because unsafe logic is often hidden behind a reusable utility or library call.
- Confirm that the patch validates the final resolved path, not just the original entry name.
- Check that absolute paths, parent directory segments, and symbolic link edge cases are rejected or neutralised.
- Verify that tests cover malicious archive entries, not only ordinary sample files.
- Ensure the fix applies anywhere archives are unpacked, including build steps, import flows, and background jobs.
Teams often miss that the vulnerability can reappear through a second code path using the same helper, so review should include call sites, not only the immediate diff. The best pre-merge outcome is a fix that is explicit enough to survive refactoring and obvious enough to be tested automatically.
Where this guidance breaks down is when archive extraction is delegated to a component whose safety guarantees are unknown or too weak to validate in review.
Where pull request fixes still leave room for failure
Tighter review gates reduce release risk, but they also create a tradeoff: the team must spend more effort proving that archive handling is safe before merge. That extra scrutiny is worthwhile, because a path traversal bug can look harmless in a code review while still creating a high-impact overwrite condition after deployment.
There is one important nuance. If the issue is found only because a scanner or reviewer recognises a suspicious pattern, the fix may still be incomplete if the code path is data-dependent or if the archive content is assembled indirectly from user input. The best-practice answer is to treat the pull request as a validation point, not as proof of safety. Teams should also be careful not to assume that “caught before merge” means “fully remediated,” because the same extraction pattern can survive in tests, examples, or sibling services.
If the pull request review is the only control, then the process depends heavily on human consistency. In that case, teams should treat archive unpacking as a recurring inspection target rather than a one-time secure coding lesson.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 16 — Application Software Security | Zip slip is a software flaw best prevented before release through secure coding review. |
| Recommendation — Apply secure coding review and testing to block archive path traversal before code merges. | ||
| NIST CSF 2.0 | PR.IP-1 — Information Protection Processes and Procedures | Pre-merge detection fits secure change control and review of protective coding processes. |
| Recommendation — Enforce secure change review so vulnerable archive-handling code is corrected before release. | ||
| MITRE ATT&CK | T1036 — Masquerading | Zip slip abuses trusted file operations to place content where it should not be written. |
| Recommendation — Hunt for archive extraction abuse that writes files outside the intended directory. | ||
Practitioner Guidance
What to prioritise: Block the merge until the patch proves that extracted paths cannot escape the intended directory, and require tests that exercise traversal payloads rather than only happy-path archives.
What to verify: Confirm that every archive-handling entry point uses the same safe path validation rule, because a single corrected method does not protect alternate code paths or future refactors.
Decision rule: If the fix depends on a library default or an informal reviewer judgment, treat it as unfinished; if the code explicitly validates resolved paths and the tests fail on traversal attempts, it is much more trustworthy.
Practitioner takeaway: Pre-merge detection is valuable because it converts a release-time exposure into a code-time correction, but only durable path validation and test coverage prevent the same zip slip pattern from returning later.
Related resources from NHI Mgmt Group
- What happens when Bandit findings are not reviewed before a pull request is merged?
- What happens when pull requests are not scanned for secrets and high-severity issues before merge?
- What breaks when code verification only happens in CI or pull request review?
- What breaks when untrusted issue or pull request content is inserted directly into an AI prompt?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
