A vulnerability in Legit's create_submodule function allows an attacker to plant an executable Git hook by specifying a submodule path of ".git/hooks". The path validation occurs only after the submodule is cloned, resulting in an attacker-controlled executable hook file that runs on subsequent Git operations. Versions 3.1.x silently allow this, while 3.2.0+ raise a ValueError after cloning but do not remove the planted hook, enabling code execution.
CVE-2026-100689 is a path traversal vulnerability in GitPython 3.1.61 and main branch affecting the submodule update process. The vulnerability arises because the 'path' field from .gitmodules is used without proper containment validation, allowing an attacker to specify a path outside the repository directory. This can lead to directory creation and population outside the intended repository location. However, typical clone workflows are not affected because Git itself prevents checkout of .gitmodules entries with '..' components. Exploitation requires use of non-HEAD commits and custom submodule update calls. A fix is available in GitPython version 1.2.0.post0_16 that applies the existing containment guard to the 'path' field.
GitPython versions prior to 1.2.0.post0_15 contain a Regular Expression Denial of Service (ReDoS) vulnerability in the Actor.name_email_regex pattern. This occurs when parsing commit author or committer headers containing a long string with an unterminated '<' character, causing catastrophic backtracking in the regex engine and resulting in CPU exhaustion proportional to the square of the input length. This can block GitPython API calls that access commit author or committer metadata for extended periods, impacting CI runners, code-hosting backends, and repository scanning tools that process untrusted commits.
GitPython version 3.1.59 contains a vulnerability where the repository's git directory is misresolved, allowing attacker-controlled repository content to impersonate the .git directory. This leads to arbitrary code execution when a victim performs a commit using GitPython's native index.commit() method. The vulnerability also allows reading sensitive files outside the repository and writing config files to attacker-chosen locations. The issue arises because GitPython tests candidate git directory paths in an order that considers the real .git directory last, causing it to treat the working tree root as the git directory if certain tracked files exist. This flaw affects services that open or clone untrusted repositories using GitPython. A fix is available in version 1.2.0.post0_15.
GitPython versions up to 1.2.0.post0_15 contain a vulnerability in the TagReference.create() method where a positional 'reference' argument can bypass the unsafe option guard for '--file'. This allows an attacker controlling the 'reference' parameter to cause an arbitrary local file read, with the file contents returned as the annotated tag message. The issue is an incomplete fix of a prior vulnerability and requires the embedding application to forward a user-controlled 'reference' value. A fix is available in version 1.2.0.post0_15.
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.
GitPython's Repo.blame() and Repo.blame_incremental() methods have an incomplete denylist for unsafe git revision options, omitting the --contents and -S options. This omission allows an attacker to cause arbitrary local file reads by passing these options, which echo file contents into the blame result. The vulnerability affects GitPython versions up to 3.1.58. A patch is available to address this issue by expanding the denylist to include these options.
GitPython versions prior to 1.2.0.post0_15 have a vulnerability in the clone_from() and clone() methods where the --separate-git-dir option is not blocked by the unsafe_git_clone_options denylist. This allows an attacker controlling input to specify an arbitrary filesystem path for the Git metadata directory during a clone operation, enabling creation of repository metadata outside the intended clone destination.
GitPython versions prior to 1.2.0.post0_14 contain a vulnerability where the submodule name from a cloned repository's .gitmodules file is not validated. This allows an attacker controlling the repository to specify a submodule name with directory traversal sequences, causing GitPython to create and initialize a Git repository outside the intended working directory when submodules are initialized. This behavior differs from core Git, which blocks such attacks. The vulnerability requires the victim to clone the malicious repository using GitPython and run submodule initialization.
GitPython versions prior to 1.2.0.post0_14 contain a vulnerability in the config-name validator that allows injection of arbitrary git configuration directives via crafted option names. The validator does not reject characters such as '=', '#', ';', '[', ']', or whitespace in option names, enabling attackers to forge directives like core.sshCommand or core.hooksPath. This can lead to remote code execution (RCE) when Git processes these injected directives during subsequent operations.
GitPython versions up to 1.2.0.post0_14 contain a vulnerability in the option guard mechanism that allows bypassing the unsafe git option check when using split_single_char_options=False. This bypass enables arbitrary OS command execution via crafted short-option tokens, affecting multiple guarded methods such as clone and fetch. The flaw is an incomplete fix of a previous vulnerability and arises because the guard does not inspect joined short-option tokens emitted when split_single_char_options is False.
GitPython's Repo.init method forwards keyword arguments directly to git init without guarding unsafe options like --template. This allows an attacker who can control the template argument and stage a malicious hooks directory to plant executable git hooks in the new repository. These hooks execute arbitrary code on the next git operation performed by the host process. The vulnerability affects GitPython versions prior to 1.2.0.post0_14 and requires attacker control over the template path and the ability to stage executable hooks. A fix is available in version 1.2.0.post0_14 that adds checks to block unsafe options.
GitPython versions >=0.1.0 and <1.2.0.post0_14 contain a vulnerability in the IndexFile.remove() and Head.checkout() methods. These methods forward arbitrary keyword arguments into git rm and git checkout commands without proper validation. When used with the --pathspec-from-file and --pathspec-file-nul options, this can cause Git to treat the entire contents of a specified file as a single pathspec, leading to the file's contents being leaked in error messages returned by GitPython. This allows an attacker with limited privileges to read arbitrary files on the system through error output.
GitPython versions up to 1.2.0.post0_14 contain a vulnerability in the IndexFile.from_tree, reset, and merge_tree methods where unguarded forwarding of git read-tree options allows an attacker to overwrite arbitrary files with a git-index blob. This occurs because these methods append caller-controlled treeish strings to git read-tree without proper unsafe option checks or a '--' separator, enabling injection of the --index-output option to specify an arbitrary output path. The impact is arbitrary file overwrite at the privileges of the host process, potentially corrupting or destroying files. A fix is available in version 1.2.0.post0_14.
GitPython versions up to 3.1.53 contain a vulnerability in the check_unsafe_options guard that can be bypassed by smuggling a git option token inside the value of a single-character keyword argument. This bypass allows arbitrary OS command execution via the --upload-pack option in all guarded methods such as clone, fetch, and pull. The vulnerability arises because the guard only inspects keyword argument keys, not their values, enabling injection of unsafe options. A fix is available in version 1.2.0.post0_12.
GitPython's Diffable.diff() method allows attacker-controlled arguments to be passed directly to git diff commands without proper validation, enabling arbitrary file overwrite via the --output option. This affects versions up to 3.1.53. An attacker can cause git to write diff output to any file path writable by the process, potentially overwriting critical files such as SSH authorized_keys. A fix is available in version 1.2.0.post0_12 that adds option validation and prevents option injection.