Threat database

Dulwich versions from 0.22.5 up to but not including 1.2.8 contain a path traversal vulnerability in the stash.py pop() function. This flaw allows attackers to write arbitrary files outside the intended worktree by exploiting intermediate directory symlinks. A malicious repository can be crafted so that the popped stash writes a payload into the .git/hooks/post-checkout file, enabling code execution upon the next git checkout operation.

Dulwich from 0.23.1 before 1.2.8 contains a path traversal vulnerability in CommitFilter._apply_index_filter() that allows attackers to write files outside the working directory via symlinks persisting between commits. Attackers can craft a repository where an ancestor commit's symlink redirects a descendant commit's file writes during filter_branch, enabling code execution by writing into .git/hooks.

Dulwich versions from 0.24.0 up to but not including 1.2.8 contain a vulnerability in the porcelain.checkout function where symbolic links are improperly resolved before file access. This allows attackers to write arbitrary files by exploiting the lack of O_NOFOLLOW flag in os.open calls. Specifically, an attacker can craft a repository with a worktree symlink pointing to .git/hooks/post-checkout, causing a malicious hook to be written during a tag restore operation, potentially enabling code execution.

Dulwich before 1.2.9 contains a denial of service vulnerability in Pack.resolve_object that allows attackers to cause infinite recursion via self-referential OFS_DELTA objects. Attackers can supply a malicious packfile with an OFS_DELTA delta_offset of 0 to exhaust CPU during clone, fetch, or cat-file operations.

Dulwich versions before 1.2.9 contain a path traversal vulnerability on Windows due to improper validation of DOS drive letter prefixes in Git tree path elements. This flaw allows attackers to craft malicious repositories with tree entries named like 'C:' that bypass NTFS validation and write files outside the intended worktree, potentially enabling remote code execution.

Dulwich versions prior to 1.1.1 lack SSH host key verification in the contrib/paramiko_vendor.py component. This vulnerability can allow an attacker to perform man-in-the-middle attacks by impersonating SSH hosts, potentially leading to information disclosure. The issue is identified as CWE-295 and has a medium severity with a CVSS score of 5.3. No official patch or remediation guidance is currently confirmed.

### Summary `dulwich.porcelain.submodule_update`, and by extension `porcelain.clone(..., recurse_submodules=True)`, materializes attacker-controlled submodule paths from a crafted upstream repository without path validation. A malicious `.gitmodules` plus a matching tree gitlink whose `path` is `.git/hooks` (or any other directory inside the parent repository's `.git` directory) causes the attacker's submodule tree contents to be written directly into the victim's `.git/hooks/` directory, preserving executable mode bits. The dropped executables are then run by any subsequent `git` or `dulwich` command that invokes the matching hook, resulting in arbitrary code execution. This is the dulwich equivalent of the upstream Git fixes for CVE-2024-32002 / CVE-2024-32004, which were never propagated into dulwich's separately implemented submodule porcelain. ### Affected - **Package:** `dulwich` (PyPI) - **Affected versions:** `>=0.23.2, <1.2.5` - **Affected platforms:** all (Linux, macOS, Windows). Exploitation does not require a case-insensitive or NTFS filesystem, because the path written is a literal `.git/hooks` rather than a case- or short-name-aliased form. Affected entry points: - `dulwich.porcelain.submodule_update(repo, init=True, recursive=True)` - `dulwich.porcelain.clone(source, target, recurse_submodules=True)` - `dulwich submodule update` CLI / `dulwich clone --recurse-submodules` CLI ### Vulnerable code The submodule path from the tree's gitlink entry (and matching `.gitmodules`) is consumed without validation in [`dulwich/porcelain/submodule.py`](https://github.com/jelmer/dulwich/blob/8efb7d19eac519cd7fac39e79ca354327897e133/dulwich/porcelain/submodule.py#L154-L234). The attacker-controlled `path` enters the loop from `iter_cached_submodules` ([`submodule.py#L154-L168`](https://github.com/jelmer/dulwich/blob/8efb7d19eac519cd7fac39e79ca354327897e133/dulwich/porcelain/submodule.py#L154-L168)): ```python for path, target_sha in submodules_to_update: path_str = ( path.decode(DEFAULT_ENCODING) if isinstance(path, bytes) else path ) submodule_name: bytes | None = None for sm_path, sm_url, sm_name in read_submodules(gitmodules_path): if sm_path == path: submodule_name = sm_name break if not submodule_name: continue ``` It flows unchecked into `os.path.join` and the filesystem ([`submodule.py#L187-L188`](https://github.com/jelmer/dulwich/blob/8efb7d19eac519cd7fac39e79ca354327897e133/dulwich/porcelain/submodule.py#L187-L188)): ```python submodule_path = os.path.join(r.path, path_str) submodule_git_dir = os.path.join(r.controldir(), "modules", path_str) ``` Finally, the attacker tree's contents are materialized into that directory via `build_index_from_tree` with no `validate_path_element` argument, defaulting to the lax validator ([`submodule.py#L229-L234`](https://github.com/jelmer/dulwich/blob/8efb7d19eac519cd7fac39e79ca354327897e133/dulwich/porcelain/submodule.py#L229-L234)): ```python build_index_from_tree( submodule_path, sub_repo.index_path(), sub_repo.object_store, tree_id, ) ``` Three issues compound: 1. `path_str` originates from the parent repository's tree gitlink entry (attacker-controlled) and is never validated against `.git`, `..`, or other path-traversal patterns. The same value is read from the attacker-supplied `.gitmodules` blob via [`read_submodules`](https://github.com/jelmer/dulwich/blob/8efb7d19eac519cd7fac39e79ca354327897e133/dulwich/config.py#L1637-L1665), which also performs no validation. 2. `submodule_path = os.path.join(r.path, path_str)` therefore resolves to an attacker-chosen directory anywhere on disk (e.g. `<worktree>/.git/hooks`). 3. [`build_index_from_tree`](https://github.com/jelmer/dulwich/blob/8efb7d19eac519cd7fac39e79ca354327897e133/dulwich/index.py#L2034-L2044) is called without `validate_path_element`, so it defaults to `validate_path_element_default`, which only rejects literal `.git`, `.`, and `..`. It does not refuse a `root_path` that is itself inside the parent's `.git` directory, and it honors the attacker tree's file modes including executable bits (`0o100755`). ### Reachability A direct production call path from a user invocation: `porcelain.clone(source, target, recurse_submodules=True)` at [`dulwich/porcelain/__init__.py:1548-1551`](https://github.com/jelmer/dulwich/blob/8efb7d19eac519cd7fac39e79ca354327897e133/dulwich/porcelain/__init__.py#L1548-L1551) calls `submodule_update(repo, init=True, recursive=True)` once the parent clone completes, reaching the unsanitized loop at [`submodule.py#L154-L234`](https://github.com/jelmer/dulwich/blob/8efb7d19eac519cd7fac39e79ca354327897e133/dulwich/porcelain/submodule.py#L154-L234). The CLI command `dulwich clone --recurse-submodules <url>` reaches the same sink via [`dulwich

## Impact An uncontrolled-resource-consumption (memory exhaustion) denial-of-service vulnerability (CWE-400 / CWE-789). A client with push access could push a tiny crafted thin pack (~174 bytes) whose delta header declares a huge dest_size. When dulwich ingested it via add_thin_pack / apply_delta, it would allocate hundreds of MB of memory based on that attacker-controlled size, with no relationship to the actual bytes received. Who is impacted: Operators running a Dulwich-based Git server that exposes git-receive-pack (i.e. accepts pushes) - for example via dulwich.server functionality, the HTTP smart server, or anything built on ReceivePackHandler. ## Patches Patched in 1.2.5. add_thin_pack now accepts a max_input_size keyword (bytes; 0/None = unlimited, matching git's semantics), and ReceivePackHandler reads receive.maxInputSize from the repository config and passes it through. Wire reads are counted and a PackInputTooLarge exception is raised once the cap is exceeded - equivalent to git index-pack --max-input-size. Users should upgrade to Dulwich 1.2.5 or later and set receive.maxInputSize in their server's repository config to a sane bound for their environment. ## Workarounds On unpatched versions, receive.maxInputSize has no effect, so it cannot be used as a workaround. Until upgrading, operators should: - Restrict dulwich-receive-pack (push) access to trusted, authenticated clients only, or disable it entirely on servers that only need to serve fetches. - Run the server under an OS-level memory limit (e.g. ulimit, cgroups/MemoryMax, or a container memory limit) so a malicious push is killed rather than taking down the host. ## Resources - git's receive.maxInputSize / git index-pack --max-input-size documentation - Reported by Liyi, Ziyue, Strick, Maurice and Chenchen @ University of Sydney

### Impact dulwich.porcelain.format_patch(outdir=...) derives each patch filename from the commit's subject line. Prior to this fix, get_summary only replaced spaces with dashes - path separators (/, \), parent-directory components (..), and other filename-hostile characters (e.g. :) were preserved verbatim and passed straight into os.path.join(outdir, f"{i:04d}-{summary}.patch"). A malicious commit subject could therefore direct the generated patch file outside the requested outdir. Reduced examples: - x/../../x produced <outdir>/0001-x/../../x.patch, resolving two directories above outdir. - x\..\..\x produced the equivalent escape on Windows, here \ is also a path separator. Related issues from the same root cause: - Subjects containing characters that are illegal in Windows filenames (e.g. :) caused format_patch to fail outright on Windows, where git would have succeeded. - Very long subjects produced excessively long filenames that could exceed filesystem limits; git truncates them. Anyone calling porcelain.format_patch (or the dulwich format-patch CLI) against untrusted commits - for example, a service that runs format-patch over user-supplied repositories or pull requests - could have patch files written to attacker-chosen locations within the process's write permissions. ### Patches Fixed in Dulwich 1.2.5. Users should upgrade. dulwich.patch.get_summary now mirrors git's format_sanitized_subject: only `[A-Za-z0-9._]` are kept, runs of other characters collapse to a single -, consecutive . collapse to a single ., trailing ./- are stripped, and the result is length-limited. This makes the returned string safe to embed as a filename component, so format_patch can no longer be steered out of outdir via the commit subject. ### Workarounds Until upgrading, callers that pass untrusted commits to porcelain.format_patch can: - Use stdout=True and write the patch to a destination they control, rather than letting format_patch choose the filename. - Validate the chosen path before opening - e.g. compare os.path.realpath(returned_path) against os.path.realpath(outdir) and reject any patch whose resolved path is not inside outdir. - Pre-screen commits and refuse to format any whose subject's first line contains /, \, .., or other characters that are not safe on the target filesystem. ### Resources - Fix commit: https://github.com/jelmer/dulwich/commit/c2446e51b - Affected API: dulwich.porcelain.format_patch / dulwich format-patch - Reference behavior: git's format_sanitized_subject in pretty.c

## Summary Dulwich's `ProcessMergeDriver` substitutes the file path (from the git tree, controllable by an attacker via a malicious branch) into the merge driver command via the `%P` placeholder and executes it with `subprocess.run(..., shell=True)`. An attacker who can cause a victim to merge an untrusted branch can achieve arbitrary command execution by crafting malicious file paths. ## Description - **Type:** Command Injection - **Source:** `merge.py` line 195 — path from merge tree (from repository content when merging untrusted branch) - **Sink:** `merge_drivers.py` lines 124–127 — `subprocess.run(cmd, shell=True)` where `cmd` includes path via `%P` placeholder - **Impact:** Arbitrary code execution when merging from a malicious repository. Requires the user to have a merge driver configured that uses the `%P` placeholder. ## Resources - Repository: https://github.com/dulwich/dulwich - Vulnerable file: `dulwich/merge_drivers.py` (lines 119–129) ## Proof of Concept ```python from dulwich.attrs import GitAttributes, Pattern from dulwich.config import ConfigDict from dulwich.merge import merge_blobs from dulwich.objects import Blob # Merge driver with %P (path) - typical for custom merge tools config = ConfigDict() config.set((b"merge", b"injectable"), b"driver", b"echo %P > %A") patterns = [(Pattern(b"*"), {b"merge": b"injectable"})] gitattributes = GitAttributes(patterns) base = Blob.from_string(b"base") ours = Blob.from_string(b"ours") theirs = Blob.from_string(b"theirs") # Malicious path from attacker-controlled git tree: injects "touch /tmp/pwned" malicious_path = b"x; touch /tmp/pwned #" merge_blobs(base, ours, theirs, path=malicious_path, gitattributes=gitattributes, config=config) # => Executes: echo x; touch /tmp/pwned # # => Shell runs: echo x, then touch /tmp/pwned ``` ## Fix [merge_drivers_shell_escape.patch](https://github.com/user-attachments/files/27016503/merge_drivers_shell_escape.patch)

## Impact Arbitrary file write leading to remote code execution when cloning or checking out a malicious Git repository on Windows. Dulwich's path-element validator accepted tree entries whose filenames contained bytes that Windows interprets as structural path syntax: - \ — the Windows path separator. A single tree entry named .git\hooks\pre-commit.exe was treated as one valid filename on POSIX but materialized as nested directories .git/hooks/pre-commit.exe on Windows, planting a file inside the victim's .git directory. Git for Windows then executes that hook on the next git commit, giving the attacker arbitrary code execution in the victim's user context. The same primitive can be used with ..\outside.txt to escape the work tree. - : — the NTFS alternate-data-stream marker. .git::$INDEX_ALLOCATION writes directly into the victim's .git entity, bypassing the .git-as-a-directory check. - git~<digits> — NTFS 8.3 short-name aliases of .git. Only the literal git~1 was rejected; git~2, git~10, GIT~1, etc. were all accepted. Contributing configuration bugs made matters worse. The core.protectNTFS and core.protectHFS settings were looked up under a wrong option name and so user-set values were silently ignored, and core.protectNTFS only defaulted to true on Windows (Git upstream has defaulted it to true everywhere since CVE-2019-1353). Both have been corrected. Anyone who clones, fetches, or checks out an untrusted repository with Dulwich on Windows - either through the Dulwich CLI, porcelain.clone, or any downstream tool built on Dulwich - is impacted. POSIX clones are not directly exploitable (on POSIX \ is a literal filename byte), but a POSIX user can unknowingly propagate a malicious tree to Windows consumers via push or re-publication. ## Patches Fixed in Dulwich 1.2.5. Users should upgrade to 1.2.5 or later. The fix lives in three commits: - Read core.protectNTFS / core.protectHFS under their documented option names so user-set values are honored. - Default core.protectNTFS to true on every platform, matching Git's PROTECT_NTFS_DEFAULT=1. - Reject \, :, and all git~<digits> 8.3 short-name forms in validate_path_element_ntfs. ## Workarounds There is no effective pre-patch workaround. On affected versions the core.protectNTFS configuration key was silently ignored, so setting it to true does not mitigate the issue. Users who cannot upgrade should avoid cloning, fetching, or checking out untrusted repositories with Dulwich on Windows. After upgrading the NTFS validator is on by default on every platform, so no additional configuration is required. ## Resources - Git upstream path validation: https://github.com/git/git/blob/master/path.c (is_ntfs_dotgit, verify_path) - CVE-2019-1353 — the Git upstream vulnerability that established core.protectNTFS = true as the cross-platform default - CVE-2019-1354 — backslash-in-tree-path class in Git, analogous to this issue