## 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
## 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
Update dulwich to 1.2.5 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanDulwich has an arbitrary file write via NTFS-hostile tree entries on Windows affects dulwich (pip). Severity is high. ## 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
AI coding agents often install or upgrade packages automatically in pip. A high vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| dulwichpip | >=0.10.0,<1.2.5 | 1.2.5 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate dulwich to 1.2.5 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanDulwich has an arbitrary file write via NTFS-hostile tree entries on Windows affects dulwich (pip). Severity is high. ## 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
AI coding agents often install or upgrade packages automatically in pip. A high vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| dulwichpip | >=0.10.0,<1.2.5 | 1.2.5 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard