Dulwich: Symlink directory traversal in filter-branch index_filter via cross-commit state persistence
CVE-2026-114097 · GHSA-5fqc-mrg8-w798 · published 2 Oct 2026
How serious is it
- Severity: high.
- No exploit prediction (EPSS) score yet.
- Not on the CISA list of exploited vulnerabilities.
- No public exploit in Exploit-DB.
Is your app affected by CVE-2026-114097?
Paste this prompt into Claude Code, Cursor or any AI coding tool: it runs a free Shippable scan of your project and fixes what it finds. Built with Lovable, Bolt or v0? Scan your live app. Or upload your package file.
Who is affected
dulwich(PyPI) >= 0.23.1, < 1.2.8
How to check
- Run
pip show dulwichin your project to see the installed version, including copies pulled in by other packages. - Or paste your lockfile into the checker: it lists every package with a known vulnerability, this one included.
- Or run
npx shippable-dev scan localhost:3000in your project folder. It reads your lockfile and flags this vulnerability along with every other known one.
How to fix
Copies a prompt for Claude Code, Cursor or Codex: it checks your lockfiles for this and upgrades it.
- Upgrade
dulwichto 1.2.8 or later, commit the lockfile and redeploy. - If a vulnerable version was live, check your logs and rotate the secrets that server could read.
The advisory
## 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
1. 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)
2. Victim clones repository and runs `filter_branch` with an index filter
3. `process_commit()` processes ancestor first → materializes `evil` as symlink to `/target_dir` in CWD
4. CWD is NOT cleaned between commits
5. 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)**
Check your whole app
Dependencies are only half of it. Free and read-only: before you push, run npx shippable-dev scan localhost:3000 in your project folder, no account needed. For your live app, you prove it's yours with a one-line tag first.
References
- github.com/jelmer/dulwich/security/advisories/GHSA-5fqc-mrg8-w798
- github.com/jelmer/dulwich/commit/9571ac60b851fce228dae7ededb380c6ce9b3fb8
- github.com/jelmer/dulwich
- github.com/jelmer/dulwich/releases/tag/dulwich-1.2.8
Merged from OSV. Last updated 25 Oct 2026. All vulnerabilities · RSS · JSON