A vulnerability in setuptools on Windows allows attacker-controlled content in a wheel's .dist-info/namespace_packages.txt to cause legacy wheel installation to create an __init__.py file outside the intended installation directory. The created file has fixed content and is placed at a filesystem path influenced by the wheel, with the permissions of the installing process. The attack requires the target parent directory to already exist.
The filelock ReadWriteLock and AsyncReadWriteLock components use SQLite databases for locking, but they pass SQLite a database name that the lock user does not control. 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 another local user who can create or rename files in the directory holding the lock database (a writable directory without the sticky bit) to cause the lock user to write arbitrary data into their own files or cause lock failures. The vulnerability affects filelock versions 3.20.4 through 4.2.0, with the /proc/self/fd redirect introduced in 4.0.9 and side-file variants since 3.20.4. The CVSS 3.1 score is 7.1 (High), reflecting local attack with low complexity and high integrity and availability impact but no confidentiality impact.
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 without permission to remove it to forge the process ID in the marker. This causes the lock to be incorrectly considered stale, enabling another process running as the same user or root to remove the live lock marker and acquire the lock simultaneously. This results in two processes concurrently entering a critical section without error, potentially causing integrity issues in the protected resource. The vulnerability requires specific conditions related to file permissions and directory sticky bits and does not affect confidentiality or availability.
A vulnerability in filelock versions 3.30.0 through 4.2.0 allows a local user with write access to a shared directory to swap a symbolic link in place of a lock coordination directory during a narrow timing window. This causes the lock user's process to create claim files in an attacker-chosen directory, potentially disrupting other locks by causing stranded claims that force lock timeouts until manually cleared. The issue requires the attacker to rename the lock directory between a check and subsequent operations and is mitigated by directory sticky bit settings and ownership. The vulnerability has medium severity with high availability impact but low confidentiality and integrity impacts.
The ReadWriteLock and AsyncReadWriteLock classes in snowflake-cli resolve lock file paths by following symlinks and then open these paths with SQLite without preventing symlink traversal. This allows a local attacker with write access to the lock directory to create or manipulate files the victim process owns at attacker-controlled paths, break mutual exclusion between victim processes, or cause locking conflicts on unrelated SQLite databases.
A vulnerability in the filelock library versions 3.22.0 through 4.2.0 allows a local unprivileged user to cause two processes to simultaneously hold the same soft file lock. This occurs due to a race condition in the stale-lock break logic that identifies stale lock files by inode number and modification time. On filesystems like ext4 and xfs that reuse inode numbers immediately, an attacker can create and unlink a marker file with a future modification time, causing the lock-breaking process to remove a live lock file. This results in two holders of the same lock without detection or logging, potentially leading to data integrity issues.
The filelock library's ReadWriteLock and AsyncReadWriteLock use an SQLite-backed lock database that runs PRAGMA journal_mode=MEMORY on each acquire, causing SQLite to load the entire schema of the lock file. A local user able to place or overwrite the lock database file can craft a database that causes every acquire_read or acquire_write call to stall indefinitely, ignoring timeouts and blocking flags. This results in a denial of service by hanging the locking process, with no confidentiality or integrity impact. The vulnerability affects filelock versions 3.20.4 through 4.2.0.
A symlink swap race condition in the SoftFileLock implementation of the filelock library (versions 3.32.6 through 4.2.0) allows a local user with write access to the lock directory to leak one bit of information about the existence and writability of an arbitrary path. This occurs because the writability check uses os.lstat followed by os.access, which follows symlinks, enabling a time-of-check to time-of-use (TOCTOU) symlink swap. The leak is limited to one bit per lock acquire attempt and requires high attack complexity, including concurrent execution on multiple CPUs and observation of the lock user's acquire result. Linux kernel's fs.protected_symlinks setting blocks this attack in sticky world-writable directories like /tmp but not in other writable directories without the sticky bit. The vulnerability has a low CVSS score of 2.5 due to limited impact and high complexity.
The vulnerability affects filelock implementations StrictSoftFileLock, AsyncStrictSoftFileLock, SoftReadWriteLock, and AsyncSoftReadWriteLock in versions 3.30.0 through 4.2.0. These locks adopt ownership of a protocol directory if it already exists without verifying ownership, allowing a local attacker to pre-create this directory in shared sticky directories like /tmp. This can lead to integrity and availability impacts, including multiple writers entering critical sections simultaneously and denial-of-service conditions such as spinning CPU or memory exhaustion. The vulnerability requires local access and a race condition where the attacker creates the directory before the legitimate user first acquires the lock on a new or cleaned path. The CVSS 3.1 score is 6.3 (Medium).
UnixFileLock, used by FileLock and AsyncFileLock on Unix systems, truncates and can change permissions of any regular file that another local user renames or hard-links onto the lock path. This occurs because UnixFileLock empties the file it finds at the lock path when acquiring the lock and applies an explicit mode if specified. The vulnerability requires local user access and specific directory permissions or kernel settings to exploit. It affects all filelock releases up to and including 4.2.0. The CVSS 3.1 score is 6.1 (Medium), reflecting local attack complexity with high integrity impact but no availability impact.
The filelock library versions 3.30.0 through 4.2.0 have a vulnerability in the StrictSoftFileLock and AsyncStrictSoftFileLock classes where claim directories are created without applying the caller's restrictive mode, resulting in directories with permissions influenced by the umask or default ACLs. This can allow another local user with write access to the claim directories to unlink claim files, causing multiple holders to believe they hold the lock simultaneously, leading to integrity issues. The vulnerability requires a local attacker with write permissions on the lock's parent directory and a specific environment setup. It has no confidentiality impact but can cause high integrity and low availability impacts. The CVSS score is 5.3 (Medium).
GitPython's Submodule.move() API does not properly handle symbolic links in the destination path, allowing an attacker-controlled symlink to redirect submodule moves outside the parent repository worktree. This can cause the submodule checkout to be moved to an attacker-selected directory outside the repository, corrupting the repository's index and configuration. The issue affects GitPython versions from 3.4.1 up to but not including 3.30.0. No code execution or confidentiality impact has been demonstrated. A fix is available in version 3.30.0.
GitPython versions up to 3.1.62 contain a vulnerability in the Head.checkout() method that allows an attacker to cause an arbitrary file read via a specially crafted branch name. The issue arises because the branch name, passed as a positional argument, is not properly sanitized and can inject unsafe Git command-line options. This leads to exposure of sensitive files such as /etc/passwd when the application clones and checks out a repository controlled by an attacker. The vulnerability is a partial regression of previous fixes and is rated high severity with a CVSS 3.1 score of 7.5. A fix is available in GitPython version 3.30.0.
A command injection vulnerability exists in GitPython's Remote.pull() method used by snowflake-cli. The method improperly forwards a positional refspec argument directly to the git pull command without filtering unsafe options like --upload-pack. An attacker controlling this refspec can execute arbitrary commands with the privileges of the calling process when the remote uses a local-path or SSH transport. This affects snowflake-cli versions from 3.4.1 up to but not including 3.30.0. The issue is fixed in version 3.30.0.
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 regular expression in GitPython's parse_actor_and_date function causes quadratic backtracking on malformed author/committer/tagger lines missing or having malformed trailing epoch or timezone data. This leads to CPU exhaustion when processing crafted commit or tag objects. The issue affects snowflake-cli versions from 3.4.1 up to but not including 3.30.0. A fix is available in version 3.30.0 that modifies the regex to prevent backtracking.
GitPython's Repo._clone() method improperly expands environment variables in the separate_git_dir parameter derived from attacker-controlled .gitmodules submodule names. This leads to leakage of environment variable values into persistent on-disk directory names and debug logs when DEBUG-level logging is enabled. The vulnerability allows an attacker controlling a repository to cause secret environment variables in the victim process to be exposed on disk and in logs during normal clone and submodule update operations.
GitPython's TagReference.create() method improperly handles a positional 'reference' argument, allowing an attacker to bypass the intended unsafe option guard for '--file'. This flaw enables an arbitrary local file read, with the file contents returned as the annotated tag message. The vulnerability affects GitPython versions up to 3.1.58 and is fixed in version 3.27.0.
A critical vulnerability (CVE-2026-78676) in GitPython's GitConfigParser allows dormant multi-line git-config values to be corrupted into live injected directives upon any unrelated config write. This occurs because the parser's re-serialization logic mishandles multi-line values, causing injected directives like core.hooksPath to be interpreted by Git, enabling remote code execution (RCE). The issue affects GitPython version 3.1.58 at HEAD and specific kimi-cli versions. A patch is available.
A high-severity vulnerability in GitPython (CVE-2026-78675) allows arbitrary local file content disclosure via the [include] directive in an untrusted .gitmodules file. The SubmoduleConfigParser does not disable merge_includes, enabling an attacker to craft a malicious .gitmodules file that causes the parser to include and read arbitrary files on the victim's system. When the parser encounters a non-gitconfig file, it raises an exception that leaks the first line of the included file in the error message. This disclosure occurs during common read-only operations such as enumerating submodules, without requiring repository updates or checkouts. A fix is available for this vulnerability.