CVE-2026-42305: Dulwich Arbitrary File Write and Remote Code Execution on Windows

Technical summary

CVE-2026-42305 stems from insufficient path validation in Dulwich's tree entry processing. The vulnerability has two root causes: (1) Dulwich's filename validator accepted tree entries containing bytes that Windows interprets as structural path syntax (such as colons, angle brackets, or asterisks), and (2) configuration options core.protectNTFS and core.protectHFS were checked under incorrect option names, causing user-set values to be silently ignored. Additionally, core.protectNTFS only defaulted to true on Windows, whereas Git upstream has defaulted it to true on all platforms since 2019. When a user clones, fetches, or checks out a repository containing maliciously-named files, Dulwich writes these files with their unvalidated names, enabling path traversal or direct writes to sensitive locations. The vulnerability is path-traversal-adjacent but is more accurately characterized as a filename normalization bypass specific to Windows NTFS semantics. Version 1.2.5 corrects both the validator logic and configuration handling, and enables NTFS-safe filename validation on all platforms by default.

Business impact

Organizations using Dulwich for automated Git operations face significant risk if developers or CI/CD pipelines clone or pull untrusted repositories on Windows machines. A successful exploit could result in unauthorized file creation, overwriting of legitimate files, or execution of arbitrary code in the context of the user running Dulwich. Development teams relying on Dulwich porcelain.clone() or CLI tools built atop Dulwich are particularly exposed. The remediation requirement is straightforward—upgrade to 1.2.5—but the window before patching is dangerous because existing configuration settings (core.protectNTFS=true) offer no protection due to the bug; users have no workaround and must avoid untrusted repositories entirely on Windows until upgraded.

Affected systems

Dulwich versions 0.10.0 through 1.2.4 are vulnerable on Windows. The vulnerability affects any tool or service built on Dulwich, including direct use of porcelain.clone(), fetch, or checkout operations, as well as any downstream application that wraps these functions. While POSIX systems (Linux, macOS) are not directly exploitable—because backslash is a literal filename character rather than a path separator in Unix—POSIX users can unknowingly pull or push malicious trees from/to a shared repository that is later cloned by Windows users. Systems with Python 3.x environments where Dulwich is installed and used for Git operations are in scope.

Exploitability

Exploitation requires user interaction (cloning or checking out a repository), but the barrier is low. An attacker distributes a malicious Git repository via any publicly accessible Git hosting platform or via social engineering to encourage developers to clone it. No special privileges are required on the victim's machine. The attack surface is broad: any Windows developer, CI/CD agent, or automated service using Dulwich to pull untrusted repositories is vulnerable. The CVSS score of 8.8 (HIGH) reflects the combination of network-based delivery, low complexity, low privilege requirement, and high impact across confidentiality, integrity, and availability. The user interaction requirement (cloning) prevents it from being CRITICAL, but the real-world likelihood is elevated because Git cloning is routine.

Remediation

Upgrade Dulwich to version 1.2.5 or later immediately. This release fixes both the path validation logic and the configuration option lookup bug, and enables NTFS-safe filename validation on all platforms by default. No configuration changes are required post-upgrade. Verify the upgrade with: `pip show dulwich` to confirm version 1.2.5+. For teams unable to upgrade immediately, the only effective mitigation is to prohibit cloning, fetching, or checking out untrusted repositories on Windows until the patch is applied. Attempting to set core.protectNTFS=true on vulnerable versions does not work due to the configuration bug.

Patch guidance

Update Dulwich using your standard Python package management process: `pip install --upgrade dulwich` will fetch version 1.2.5 or later. Verify the installation by running `python -c 'import dulwich; print(dulwich.__version__)'` and confirm it is 1.2.5 or higher. For vendored or pinned dependencies, update your requirements.txt, pyproject.toml, or equivalent to specify `dulwich>=1.2.5`. Patching is low-risk; the changes are confined to path validation and configuration handling with no breaking API changes. Test in a non-production environment first if running Dulwich in a critical CI/CD pipeline, but delays should be minimal given the severity.

Detection guidance

Monitor for Dulwich version usage in your environment via pip show, requirements audits, or software composition analysis (SCA) tools; flag any version <1.2.5. Enable logging or monitoring on Git cloning operations, especially those pulling from public or untrusted repositories on Windows machines. Look for unusual file creation patterns in temporary directories or user profile locations; an exploit may attempt to write files with names like `..\..\payload.exe` or files with reserved characters. Network-level detection is difficult because the attack is delivered via standard Git protocol; focus on endpoint-level file I/O monitoring. After patching, verify that core.protectNTFS is no longer in the configuration (or if present, that it is being honored); the default-safe behavior on all platforms post-1.2.5 eliminates reliance on manual configuration.

Why prioritize this

This vulnerability should be prioritized for immediate patching because: (1) it affects all Windows developers and automated systems using Dulwich, (2) exploitation is practical and requires only routine Git operations, (3) the impact is severe (arbitrary file write and RCE), (4) no workaround mitigates the risk, and (5) the patch is simple and low-risk. If your organization uses Dulwich directly or via a downstream tool, inventory affected systems and begin patching within 24–48 hours. Organizations with developer-focused or open-source ecosystems should prioritize even higher.

Risk score, explained

The CVSS 3.1 score of 8.8 (HIGH) reflects: Attack Vector Network (AV:N) because the malicious repository is delivered over the network; Attack Complexity Low (AC:L) because exploitation is straightforward filename manipulation; Privileges Required None (PR:N); User Interaction Required (UI:R) because the victim must clone/checkout; Scope Unchanged (S:U); and impact High across Confidentiality, Integrity, and Availability (arbitrary file write and code execution). The user interaction requirement prevents a CRITICAL rating, but the score appropriately reflects the practical danger. The emphasis on Windows systems does not reduce the baseline score but should increase organizational concern for Windows-heavy development teams.

Frequently asked questions