Dulwich: Symlink directory traversal in stash pop allows arbitrary file write via intermediate directory symlinksGHSA-cm62-gvxx-vmxx
HIGHFix: jelmer/dulwich@40a542cGHSA-cm62-gvxx-vmxx is a high-severity (CVSS 8.6) Path Traversal vulnerability in dulwich. A fix is available for dulwich — see the affected versions and patch details below.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
GHSA-cm62-gvxx-vmxx by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 394,803 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
dulwichReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
Summary
Dulwich's stash.py:pop() function is vulnerable to symlink directory traversal, allowing an attacker to write arbitrary files outside the repository worktree when a victim pops a stash in a malicious repository.
Root Cause
The pop() function at dulwich/stash.py:236 uses os.path.exists(parent_dir) to check if a parent directory exists before writing stashed files. os.path.exists() follows symlinks, so when an intermediate directory in the path is a symlink pointing outside the worktree (e.g., link → ../../.git/hooks), the check passes and subsequent file writes resolve through the symlink.
The validate_path() function (line 228) only validates path component names against INVALID_DOTNAMES — it performs zero filesystem symlink detection. On dulwich 1.2.7 (latest release), build_file_from_blob() has no symlink protection whatsoever.
Impact
An attacker can craft a malicious repository that, when a victim clones it and performs a stash pop operation, writes attacker-controlled content to arbitrary filesystem locations. Writing to .git/hooks/post-checkout achieves Remote Code Execution on the victim's machine on the next git checkout operation.
Attack Scenario
- Attacker creates a repository with branch
maincontaininglink(symlink →../../.git/hooks) and branchfeaturecontaininglink/post-checkout(executable payload) - Victim clones the repository (landing on
main— symlinklinkexists in worktree) - Victim checks out
feature, makes changes, runsstash.push() - Victim checks out
main(restoring thelinksymlink) - Victim runs
stash.pop(0)— stash containslink/post-checkout os.path.exists("link")returns True (symlink to existing directory),os.makedirsskippedbuild_file_from_blob(blob, mode, "link/post-checkout")→open("link/post-checkout", "wb")follows the intermediate symlink → payload written to.git/hooks/post-checkout- Next checkout operation triggers the hook → RCE
Suggested Fix
Before writing any file, verify that no component of the target path resolves through a symlink outside the worktree. Use os.path.realpath(parent_dir) and confirm it stays within the repository root. Alternatively, use os.open() with O_NOFOLLOW on each path component.
Reported by zx (Jace)
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | dulwich | ≥ 0.22.5&&< 1.2.8 | 1.2.8pip install --upgrade 'dulwich==1.2.8' |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for dulwich, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update dulwich to 1.2.8 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-cm62-gvxx-vmxx is resolved across your whole dependency graph.
Workarounds
Resolve every user-supplied path to its canonical form and reject anything that escapes the intended directory, and run the component under an account that has no read or write access outside the directory it legitimately serves.
Frequently Asked Questions
Is GHSA-cm62-gvxx-vmxx in your dependencies?
Find it across PyPI, including transitive dependencies.