CVE-2026-42305

What it actually does

Affected Dulwich versions from 0.10.0 before 1.2.5 incorrectly validate Git tree entry names on Windows. A malicious repository can contain filenames with byte sequences that Dulwich treats as safe but Windows interprets as path structure, allowing checkout logic to write files outside the intended working tree. Because protective settings such as core.protectNTFS and core.protectHFS were looked up incorrectly, user-configured protections may be silently ignored. Successful exploitation can result in arbitrary file write and, depending on the target path and subsequent execution context, remote code execution with the privileges of the user or automation process performing the clone, fetch, or checkout.

Why it matters to the business

Organizations that use Dulwich directly or through downstream Python tooling on Windows can be compromised simply by processing an untrusted Git repository. The practical impact includes developer workstation compromise, CI/build runner compromise, source-code tampering, credential theft, and execution of attacker-controlled code in software delivery workflows. Although EPSS is currently low and there is no known KEV listing or public exploit maturity reported, the vulnerability has a high CVSS score, requires no attacker authentication, and affects a common supply-chain activity: cloning or checking out repositories.

How an attack unfolds

An attacker creates a Git repository containing specially crafted tree entries whose names include bytes that are acceptable to vulnerable Dulwich but are interpreted by Windows as path separators or special filesystem syntax. The attacker then convinces a victim, developer tool, automation job, dependency fetcher, or downstream application using Dulwich to clone, fetch, or check out that repository on Windows. During checkout, Dulwich writes files according to its flawed path validation, allowing attacker-controlled content to land outside the intended repository directory. If the attacker writes to a location that is later executed or loaded—such as a script, configuration file, tool plugin, startup location, or file used by a build process—the arbitrary file write becomes code execution under the account running the Dulwich-based operation. POSIX systems are not directly exploitable in the same way because backslash is treated as a literal filename byte, but POSIX users can still propagate malicious repositories to Windows consumers.

How to fix it

Upgrade Dulwich to version 1.2.5 or later everywhere it is used, including transitive use inside Python applications, developer tools, build systems, CI runners, release tooling, and internal automation. There is no reliable pre-patch configuration workaround: affected versions may silently ignore core.protectNTFS due to the incorrect option lookup, so setting that option does not mitigate the flaw. If immediate upgrade is not possible, stop using Dulwich on Windows to clone, fetch, or check out untrusted repositories and isolate any unavoidable processing in disposable, least-privileged sandboxes. After upgrading, the corrected NTFS validator is enabled by default on every platform and no additional configuration is required.

How to confirm the fix worked

Confirm that all environments using Dulwich report version 1.2.5 or later, for example with package inventory, lockfile review, SBOM data, pip show dulwich, or a Python import/version check. Validate downstream applications because Dulwich may be embedded as a library rather than invoked as a standalone CLI. On Windows, review automation and developer tooling for clone, fetch, or checkout operations that rely on Dulwich. To confirm the fix operationally, test with a controlled repository containing Windows-unsafe path elements and verify that checkout is rejected rather than writing files outside the repository root. Also confirm that dependency lockfiles, container images, virtual environments, and build runner images have been rebuilt after the upgrade.

Typical attack path

1. Attacker prepares a malicious Git repository with crafted tree entry names that Windows interprets as path syntax.
2. Attacker publishes or shares the repository through a Git hosting service, archive, dependency reference, or social-engineering lure.
3. A Windows user, CI job, build system, or downstream tool using Dulwich versions 0.10.0 through before 1.2.5 clones, fetches, or checks out the repository.
4. Vulnerable Dulwich validation accepts the malicious path elements and writes attacker-controlled files outside the intended checkout directory.
5. The written file overwrites or creates content in a location that is later executed, imported, loaded, or trusted by a user or automation process.
6. Attacker gains code execution or persists with the privileges of the process that performed the checkout.

How to detect it

Look for evidence of repository clone, fetch, or checkout activity using Dulwich on Windows followed by unexpected file creation or modification outside the intended checkout directory. Useful telemetry includes EDR file-write events, Sysmon Event ID 1 process creation, Sysmon Event ID 11 file creation, Sysmon Event ID 15 file stream creation, Windows Security Event ID 4688 process creation, PowerShell logs, CI runner logs, package/dependency fetch logs, and application logs from tools that embed Dulwich. Hunt for python.exe or pythonw.exe command lines invoking Dulwich or applications known to use Dulwich, then correlate those processes with writes to user startup folders, build scripts, tool/plugin directories, SSH/Git configuration paths, PATH-searchable directories, or other locations outside the repository root. On Git hosting or repository storage systems, inspect recently introduced tree entries for Windows-unsafe path elements and repositories that were cloned by Windows Dulwich clients. Because exploitation artifacts depend on the attacker-chosen write target, absence of a single filename does not rule out compromise; prioritize behavioral detection around path escape and unexpected file writes.

• python.exe -m dulwich
• pythonw.exe -m dulwich
• dulwich clone
• dulwich fetch
• porcelain.clone
• core.protectNTFS
• core.protectHFS
• pip show dulwich
• dulwich==0.
• AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup
• \Microsoft\Windows\Start Menu\Programs\Startup\
• Sysmon Event ID 11
• Sysmon Event ID 15
• Windows Security Event ID 4688

What your security team should do

• Prioritize upgrading Dulwich to 1.2.5 or later on Windows developer workstations, CI/build runners, release systems, and any service that processes third-party repositories.
• Inventory Python applications and downstream tools for direct or transitive Dulwich usage, including vendored copies and pinned lockfiles.
• Temporarily block or sandbox Dulwich-based clone, fetch, and checkout operations for untrusted repositories on Windows until upgrades are complete.
• Review recent Dulwich-based repository processing activity on Windows for suspicious file writes outside expected checkout directories.
• Harden build and developer systems with least privilege so repository checkout processes cannot write to startup folders, shared tool locations, credential stores, or other sensitive paths.
• Add detection for Python or Dulwich processes creating or modifying files outside the intended repository workspace during clone or checkout operations.
• Educate development and platform teams that POSIX systems can carry and republish malicious trees even if they are not directly exploitable themselves.