What is the CVSS score of CVE-2026-42305?

CVE-2026-42305 has a CVSS 3.1 base score of 8.8 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H. EPSS exploitation probability: 0.2%.

Which versions of Dulwich are affected by CVE-2026-42305?

Dulwich, a widely-used pure-Python Git implementation, contains a critical remote code execution vulnerability (CVSS 8.8) triggered by processing malicious Git repositories.. A patch is available.

How to fix or mitigate CVE-2026-42305?

Within 24 hours: Identify all systems and applications using Dulwich versions 0.10.0-1.2.4, and catalog which interact with external or untrusted Git repositories. Within 7 days: Implement compensating controls-disable pre-commit hooks via Git configuration, restrict repository sources to approved internal repositories, and isolate any systems that must access external Git sources. Within 30 days: Monitor Dulwich vendor channels for patch confirmation; once released, immediately upgrade affected instances to patched versions.

Dulwich CVE-2026-42305

HIGH

Path Traversal (CWE-22)

2026-05-28 https://github.com/jelmer/dulwich

GHSA-897w-fcg9-f6xj

Microsoft RCE Path Traversal

8.8

CVSS 3.1 · Vendor: https://github.com/jelmer/dulwich

Severity by source

Vendor (https://github.com/jelmer/dulwich) PRIMARY

8.8 HIGH

AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

Primary rating from Vendor (https://github.com/jelmer/dulwich) · only source for this CVE.

CVSS VectorVendor: https://github.com/jelmer/dulwich

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

Required

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Source Code Evidence Fetched

May 28, 2026 - 22:50 vuln.today

Analysis Generated

May 28, 2026 - 22:50 vuln.today

CVE Published

May 28, 2026 - 22:28 nvd

HIGH 8.8

DescriptionCVE.org

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

AnalysisAI

Arbitrary file write leading to remote code execution in Dulwich (pure-Python Git implementation) versions >= 0.10.0 and < 1.2.5 allows attackers controlling a Git repository to plant files inside a Windows victim's .git directory - most notably .git/hooks/pre-commit.exe - which executes on the next commit. The flaw stems from the NTFS path-element validator accepting Windows-hostile bytes (\, :, and git~<n> 8.3 short-name aliases) plus broken handling of core.protectNTFS/core.protectHFS configuration. No public exploit identified at time of analysis, and the issue is not listed in CISA KEV, but the technique is closely modeled on the well-documented Git CVE-2019-1353/1354 class.

Technical ContextAI

Dulwich is a pure-Python implementation of the Git object/protocol stack, commonly used by porcelain.clone, downstream tools, and CI systems that need Git access without the native git binary. The vulnerability is a classic CWE-22 path traversal/injection in tree-entry validation: validate_path_element_ntfs failed to reject the Windows path separator (\), the NTFS alternate-data-stream marker (:), and 8.3 short-name aliases of .git (only the literal git~1 was blocked, while git~2, git~10, GIT~1, etc. slipped through). Compounding bugs caused core.protectNTFS and core.protectHFS to be read under wrong option names so user-set values were silently ignored, and core.protectNTFS only defaulted to true on Windows rather than universally as upstream Git has done since CVE-2019-1353. The CPE pkg:pip/dulwich confirms the affected distribution is the PyPI package.

RemediationAI

The primary fix is to upgrade to the vendor-released patch Dulwich 1.2.5 or later (release notes at https://github.com/jelmer/dulwich/releases/tag/dulwich-1.2.5), which rejects \, :, and all git~<digits> 8.3 short-name forms in validate_path_element_ntfs, defaults core.protectNTFS to true on every platform, and reads core.protectNTFS/core.protectHFS under their correct option names. There is no effective pre-patch workaround because pre-fix versions silently ignore core.protectNTFS, so setting that config flag has no effect; the vendor advisory explicitly states this. If immediate upgrade is impossible, the only viable compensating control is operational: prohibit cloning, fetching, or checking out untrusted repositories with Dulwich on Windows hosts (including developer workstations and Windows CI agents), and route any necessary untrusted-repo handling through native git on POSIX systems, accepting the productivity cost of restricting Windows-based Dulwich workflows. Inventory downstream tools that vendor Dulwich (build systems, IDE plugins, CI runners) and pin them to versions that depend on Dulwich >= 1.2.5.