GitPython versions up to 3.1.62 contain a vulnerability in the Head.checkout() method where an attacker-controlled branch name can be used to inject arbitrary git command arguments. This allows an attacker who can control the repository URL to cause the application to read arbitrary files accessible to the process, such as /etc/passwd, and return their contents through an exception. The flaw stems from incomplete sanitization of positional arguments in the checkout method, despite prior fixes addressing keyword argument injection. The vulnerability has a CVSS 3.1 score of 7.5 (High).
The filelock ReadWriteLock and AsyncReadWriteLock components use SQLite databases for locking, but on Linux, SQLite reopens the lock database by name via /proc/self/fd, following symlinks and acting on side files like -journal, -wal, and -shm. This behavior allows a local attacker who can create or rename files in the directory containing the lock database (if it is writable without the sticky bit) to manipulate the lock user's files by planting symlinks or journal files. This can lead to arbitrary file writes, file creation or deletion, and denial of lock acquisition, all with the lock user's privileges. The vulnerability affects filelock versions 3.20.4 through 4.2.0, with the fixed version being 3.0.2_3. The CVSS 3.1 score is 7.1 (High).
CVE-2026-110857 affects the snowflake-cli tool's use of GitPython wrappers that omit critical unsafe protocol and option checks. Three methods—Git.ls_remote, Repo.merge_base, and IndexFile.move—fail to enforce established guards against unsafe Git transport protocols and options, leading to potential remote code execution (RCE) and argument injection vulnerabilities. The most severe issue is with ls_remote, which can execute arbitrary commands if the victim's Git configuration permits the 'ext' transport protocol. This vulnerability is confirmed on versions >=3.4.1 and <3.30.0 and fixed in 3.30.0. The CVSS 3.1 score is 7.5 (high severity).
A vulnerability in filelock versions 3.22.0 through 4.2.0 allows a local user with write access to a lock marker file (but not remove permissions) to forge the process ID recorded in the marker. This causes another process running as the lock owner or root to incorrectly consider the lock stale, remove the live marker, and acquire the lock concurrently. This results in two processes simultaneously entering a critical section protected by the lock, causing integrity violations. The issue requires specific conditions on file permissions and directory sticky bits and is rated medium severity with a CVSS score of 4.7.
Authlib versions up to 1.7.2 accept an empty HMAC key for JWS/JWT HS256/HS384/HS512 signature verification, allowing attackers to forge tokens that pass signature checks. This occurs because empty keys produce deterministic digests that anyone can reproduce, enabling token forgery if the verification key is empty at runtime. The issue affects OAuth 2.0 resource servers and OIDC relying parties using Authlib for token verification. A fix is available in Authlib versions after 1.7.2.
Authlib's is_secure_transport() function incorrectly treats URLs with a userinfo component containing loopback prefixes as secure, allowing cleartext HTTP URLs with non-loopback hosts to bypass TLS enforcement. This affects OAuth 2.0 / OIDC endpoint and redirect URI validation, potentially allowing an attacker to register or use non-TLS URLs where TLS is required. The issue impacts versions from 0.13 through 1.7.2. The severity is low due to the nature of the bypass and limited impact scope.
A vulnerability in virtualenv affects the bash activation prompt under older compatibility modes (bash 4.2 and lower). An attacker who can supply the prompt text passed to virtualenv can cause that text to be interpreted as executable shell syntax when the environment is activated and the prompt is drawn. This occurs because the prompt string is assigned to PS1 and then expanded again by the shell, with certain shells or compatibility modes interpreting the prompt text as commands. The issue affects POSIX activation scripts and specific shell usage scenarios, including dash sourcing and child dash shells inheriting an exported PS1 from bash. The vulnerability was introduced in virtualenv 20.0.0b1 and 21.14.7 and fixed in version 4.67.0.
The ReadWriteLock and AsyncReadWriteLock classes in tox versions 4.35.0 up to but not including 4.64.7 resolve lock file paths following symlinks, allowing a local attacker with write access to the lock directory to cause the victim process to create or lock files at arbitrary locations. This can break mutual exclusion, cause database lock errors, or corrupt protected resources. The issue is fixed in tox 4.64.7.
Tach's GitPython integration has a vulnerability where a submodule's ".git" path is validated only after cloning, allowing an attacker to plant an executable hook in the .git/hooks directory. This hook executes on subsequent git operations, enabling arbitrary code execution. Versions from 0.19.7 up to but not including 0.35.3_1 are affected. The issue arises because the path validation occurs too late, after the clone operation has already written files to disk. Although versions 0.35.3_1 and later raise an error, the malicious hook remains on disk and executable. This affects applications that create submodules from attacker-controlled paths, especially when the target hook name is free in .git/hooks, such as minimal or CI checkouts.
GitPython's Submodule.move() API does not properly validate intermediate symbolic links in the destination path, allowing an attacker-controlled symlink to redirect the move operation outside the intended repository worktree. This can cause the submodule checkout to be moved to an attacker-selected directory outside the parent repository, corrupting the repository's index and configuration state. The issue affects GitPython versions from 0.19.7 up to but not including 0.35.2 and has been fixed in version 0.35.2.
A vulnerability in GitPython's Remote.pull() method allows an attacker controlling the refspec argument to execute arbitrary commands. The issue arises because the positional refspec argument bypasses the unsafe-option guard that is intended to block dangerous options like --upload-pack. This leads to arbitrary command execution with the privileges of the calling process when using local-path or SSH transports. The vulnerability affects GitPython versions from 0.19.7 up to but not including 0.35.2 and has been fixed in version 0.35.2.
Tach's GitPython parse_actor_and_date() function contains a regex vulnerability causing quadratic backtracking on malformed author, committer, or tagger identity lines missing or having malformed trailing epoch or timezone. This leads to severe CPU exhaustion when processing crafted commit or tag objects. The issue affects Tach versions from 0.19.7 up to but not including 0.35.2. A fix is available in version 0.35.2 that modifies the regex to eliminate the backtracking problem.
GitPython versions from 0.19.7 up to but not including 0.35.2 contain a vulnerability in the handling of the separate_git_dir parameter during repository cloning. This flaw allows environment variable expansion from attacker-controlled .gitmodules submodule names, leading to leakage of environment variable values on disk and in debug logs. The issue is fixed in version 0.35.2.