Dulwich: Symlink directory traversal in filter-branch index_filter via cross-commit state persistenceGHSA-5fqc-mrg8-w798
HIGHFix: jelmer/dulwich@9571ac6GHSA-5fqc-mrg8-w798 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-5fqc-mrg8-w798 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 394,415 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 filter_branch.py CommitFilter._apply_index_filter() is vulnerable to symlink directory traversal. When processing commit history, materialized tree entries (including symlinks) persist in the working directory between commits, allowing a symlink from an ancestor commit to redirect file writes from a descendant commit to arbitrary filesystem locations.
Root Cause
_apply_index_filter() at dulwich/filter_branch.py:212 calls build_index_from_tree(".", tmp_index_path, ...) which materializes all tree entries to the current working directory. The finally block (line 229-230) only cleans up the temporary index file (os.unlink(tmp_index_path)) — NOT the filesystem files written to CWD. When process_commit() processes parents recursively first (line 260), files materialized from ancestor commits persist and affect processing of descendant commits.
On dulwich 1.2.7, build_file_from_blob() has no symlink protection, and validate_path_element only validates name patterns, not filesystem state.
Impact
An attacker can craft a malicious repository where running filter_branch with an index filter writes attacker-controlled content to arbitrary filesystem locations via symlink traversal. This achieves RCE if the write targets .git/hooks/.
Attack Scenario
- Attacker creates a repository where commit history (linearized) has:
- Ancestor commit: tree entry
evil(mode 120000, symlink →/target_dir) - Descendant commit: tree entry
evil/payload(mode 100644, attacker content)
- Ancestor commit: tree entry
- Victim clones repository and runs
filter_branchwith an index filter process_commit()processes ancestor first → materializesevilas symlink to/target_dirin CWD- CWD is NOT cleaned between commits
- Processing descendant:
os.path.exists("./evil")→ True (symlink exists).build_file_from_blob(blob, mode, "./evil/payload")→open("./evil/payload", "wb")follows intermediate symlink → writes to/target_dir/payload
Suggested Fix
Clean the CWD between commit iterations in _apply_index_filter(), or verify that no intermediate path components are symlinks before writing files.
Reported by zx (Jace)
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | dulwich | ≥ 0.23.1&&< 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-5fqc-mrg8-w798 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-5fqc-mrg8-w798 in your dependencies?
Find it across PyPI, including transitive dependencies.