HIGH 7.5

CVE-2026-52726: Dulwich Git Submodule Path Traversal & RCE

Dulwich, a Python library that implements Git functionality, contains a critical flaw in how it handles submodules from untrusted repositories. When cloning a repository with submodules enabled, or when explicitly updating submodules, the library fails to validate where those submodules are being placed. An attacker can craft a malicious repository with a `.gitmodules` file that points a submodule to a path like `.git/hooks/`, causing arbitrary files to be written into your repository's hook directory. Since Git automatically runs hooks during normal operations, this allows the attacker to execute code on your system. The vulnerability affects Dulwich versions 0.23.2 through 1.2.4.

Source data · NVD / CISA · public domain

CVSS
3.1 · 7.5 HIGH · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Weaknesses (CWE)
CWE-22
Affected products
0 configuration(s)
Published / Modified
2026-06-10 / 2026-06-17

NVD description (verbatim)

Dulwich is a pure-Python implementation of the Git file formats and protocols. Starting in version 0.23.2 and prior to version 1.2.5, `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. Version 1.2.5 patches the issue.

3 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

The vulnerability stems from insufficient path validation in `dulwich.porcelain.submodule_update()` and the recursive submodule cloning path invoked by `porcelain.clone(..., recurse_submodules=True)`. A crafted `.gitmodules` configuration combined with a corresponding tree gitlink entry specifying a malicious path (e.g., `.git/hooks/pre-commit`) allows an attacker to materialize submodule contents directly into sensitive directories within the parent repository's `.git` folder. The dropped files retain executable permissions, enabling arbitrary command execution when Git or Dulwich invokes the corresponding hook during subsequent operations. This mirrors the upstream Git security fixes for CVE-2024-32002 and CVE-2024-32004, which were not applied to Dulwich's independently maintained submodule handling logic.

Business impact

Organizations and developers using Dulwich to automate repository operations—particularly in CI/CD pipelines, deployment workflows, or automated repository management tools—face significant risk. Successful exploitation results in arbitrary code execution within the context of the process running Dulwich, potentially compromising build systems, credentials, source code, or downstream deployments. The attack requires no user interaction beyond cloning or updating a repository, making it particularly dangerous in unattended automation scenarios where an attacker can poison an upstream repository or perform supply-chain attacks.

Affected systems

Dulwich versions 0.23.2 through 1.2.4 are vulnerable. Any system or application using these versions to clone or update Git repositories with submodules enabled is at risk, particularly in CI/CD environments, automated deployment tools, and developer workstations that interact with untrusted or publicly accessible repositories.

Exploitability

Exploitation is straightforward and requires only network access to deliver a malicious repository. No authentication, special user privileges, or user interaction is needed beyond initiating a clone or submodule update operation. The attack surface is broad: any automated tool, script, or service that pulls code from repositories without strict repository signing or validation mechanisms is vulnerable. The ease of exploitation and lack of defensive friction make this a practical threat.

Remediation

Upgrade Dulwich to version 1.2.5 or later immediately. This version implements proper path validation to prevent submodules from being materialized outside the repository's working tree or into sensitive `.git` subdirectories. After patching, audit any recent repository clones or submodule updates performed with vulnerable Dulwich versions to detect and remove potentially malicious hook files from your `.git/hooks/` directories.

Patch guidance

Update Dulwich via your package manager (e.g., `pip install --upgrade dulwich>=1.2.5` for Python environments). Verify the installed version using `pip show dulwich` or equivalent. If Dulwich is a transitive dependency of another tool, ensure that tool and its dependencies are also updated to pull in the patched Dulwich version. Test the upgrade in a non-production environment first, particularly if Dulwich integration is critical to your workflows.

Detection guidance

Search your `.git/hooks/` directory for recently created or modified executable files, especially those with names suggesting they were not created by your team (look for timestamps correlating with suspicious repository clones or updates). Review repository clone and pull logs from the time period when vulnerable Dulwich versions were in use. If using Git, check `git log --all` for unexpected submodule entries pointing to `.git/*` paths in `.gitmodules`. Implement Git hook integrity monitoring in sensitive repositories to detect unauthorized modifications.

Why prioritize this

This vulnerability merits immediate remediation due to its high severity (CVSS 7.5), complete lack of authentication requirements, straightforward exploitation path, and impact on supply-chain security. Automated systems relying on Dulwich are particularly exposed. The fact that this mirrors known upstream Git vulnerabilities (CVE-2024-32002, CVE-2024-32004) that have been actively exploited reinforces urgency.

Risk score, explained

The CVSS 7.5 (HIGH) score reflects network-accessible exploitation (AV:N), low complexity (AC:L), no privilege or user interaction requirements (PR:N/UI:N), and denial-of-service impact (A:H). However, the actual risk is substantially elevated by the arbitrary code execution capability—which the CVSS vector does not fully capture—combined with prevalence in automation and CI/CD contexts where a single compromise can cascade to multiple systems.

Frequently asked questions

What is the difference between this and CVE-2024-32002/CVE-2024-32004?

Those CVEs describe the same vulnerability class in Git itself (the upstream project). Dulwich is a separate, pure-Python implementation of Git protocols and formats. When Git fixed those vulnerabilities, Dulwich's independently maintained submodule code was not updated in parallel, leaving it exposed to the same attack vector.

Are private or internal repositories safe from this attack?

If your internal repository is compromised, or if an employee inadvertently adds a malicious upstream repository as a submodule, the attack can succeed. Additionally, if an attacker gains write access to a repository your CI/CD system pulls from, they can inject the malicious `.gitmodules` configuration. Upgrading Dulwich closes the attack vector regardless of repository visibility.

Does upgrading Dulwich require code changes?

No. The fix is transparent and requires only a version bump. However, you should audit `.git/hooks/` directories on systems that used vulnerable Dulwich versions, as any already-planted hooks will not be automatically removed by the upgrade.

How can I prevent this beyond patching?

Verify and sign Git commits and tags in critical repositories. Use Git configuration to restrict submodule sources (`protocol.allowedProtocol`, `submodule.recurse=false` by default). In CI/CD, run builds in ephemeral containers and validate repository checksums before cloning. Implement least-privilege for build agents and monitor for unexpected process spawning from Git hooks.

This analysis is based on publicly available information as of the publication date. Readers should verify all patch versions, vendor advisories, and affected product lists against official sources before deploying mitigations. Exploitation details and proof-of-concept code are not provided; reference vendor security advisories and responsible disclosure channels for technical details. Organizations should conduct their own risk assessment and testing before implementing changes to production systems. Source: NVD (public-domain), retrieved 2026-07-20. Analysis generated by SEC.co (claude-haiku-4-5).