Dulwich vulnerabilities

Dulwich before 1.2.9 contains a denial of service vulnerability in Pack.resolve_object that allows attackers to cause infinite recursion via self-referential OFS_DELTA objects. Attackers can supply a malicious packfile with an OFS_DELTA delta_offset of 0 to exhaust CPU during clone, fetch, or cat-file operations.

Buffer overflow in the C implementation of the apply_delta function in _pack.c in Dulwich before version 0.9.9 allows remote attackers to execute arbitrary code via a crafted pack file.

The build_index_from_tree function in index.py in Dulwich before version 0.9.9 allows remote attackers to execute arbitrary code via a commit with a directory path starting with .git/, which is not properly handled when checking out a working tree.

Dulwich before version 0.18.5, when using an SSH subprocess, allows remote attackers to execute arbitrary commands via an ssh URL with an initial dash character in the hostname.

Dulwich from 0.22.5 before 1.2.8 contains a path traversal vulnerability in stash.py pop() that allows attackers to write arbitrary files outside the worktree through intermediate directory symlinks. Attackers can craft a malicious repository whose popped stash writes a payload into .git/hooks/post-checkout, achieving code execution on the next checkout.

Dulwich from 0.23.1 before 1.2.8 contains a path traversal vulnerability in CommitFilter._apply_index_filter() that allows attackers to write files outside the working directory via symlinks persisting between commits. Attackers can craft a repository where an ancestor commit's symlink redirects a descendant commit's file writes during filter_branch, enabling code execution by writing into .git/hooks.

Dulwich from 0.24.0 before 1.2.8 contains a symlink following vulnerability in porcelain.checkout(paths=[...]) that allows attackers to write arbitrary files by abusing raw os.open without O_NOFOLLOW. Attackers can craft a repository where a worktree symlink points to .git/hooks/post-checkout, so restoring the file from a tag writes a malicious hook for code execution.

Dulwich before 1.2.9 fails to validate DOS drive letter prefixes in Git tree path elements on Windows, allowing arbitrary file write. Attackers can craft a malicious repository with a tree entry named 'C:' that bypasses NTFS validation and writes files outside the worktree to achieve remote code execution.

Dulwich through version 1.1.0 is missing SSH host key verification in contrib/paramiko_vendor.py. This means that during SSH connections, the server's public key is not checked for trustworthiness.

Dulwich versions 0.23.2 through 1.2.5 do not validate submodule paths during recursive clone. An attacker can craft a malicious .gitmodules and gitlink tree with path .git/hooks, causing files to be written into the victim's .git/hooks directory. Executable files are then run on any hook invocation, leading to remote code execution.

A vulnerability in Dulwich (versions 0.1.0 through 1.2.4) allows a client with push access to send a crafted thin pack (~174 bytes) whose delta header declares a huge dest_size. When processed by add_thin_pack/apply_delta, it allocates hundreds of MB of memory, potentially causing resource exhaustion.

A vulnerability in Dulwich (versions 0.24.0 through 1.2.4) allows writing patch files outside the intended directory via a malicious commit subject. The format_patch function derives filenames from commit subjects without sanitizing path separators or parent-directory components.

A vulnerability in the Dulwich library (versions 0.24.0 through 1.2.4) allows arbitrary command execution. An attacker can craft a malicious file path in a Git branch, which is substituted into the merge driver command via the %P placeholder and executed with shell=True when a victim merges the branch.

A vulnerability in the Dulwich library (versions 0.10.0 through 1.2.4) allows remote code execution via arbitrary file write when cloning or checking out a malicious Git repository on Windows. The issue stems from improper validation of path elements that can contain bytes interpreted by Windows as structural path syntax. Additionally, the core.protectNTFS and core.protectHFS security settings were silently ignored due to configuration bugs.