CVE-2026-87817

GitPython before 3.1.60 fails to properly validate the git directory location, allowing attackers to impersonate the git directory using tracked files like gitdir, commondir, and HEAD. Attackers can execute arbitrary code by placing a malicious pre-commit hook in the tracked hooks directory that executes when a victim calls index.commit() on a cloned or opened repository.

Summary

Repo.__init__ decides which directory is the git directory by testing candidate paths in an order that considers the real .git last. Two earlier tests can be satisfied by ordinary tracked files. Git reserves only the literal name .git, so HEAD, objects/, refs/, config, gitdir, commondir and hooks/ at a repository root are all legal tracked content.

Consequently, after a victim opens or clones an attacker's repository, GitPython resolves git_dir to the working-tree root while real git correctly resolves <root>/.git. Everything GitPython then treats as "inside the git directory" is attacker-authored content — including hooks/, which it executes.

CVE-2026-87817

Affected code (3.1.59)

The discovery loop in git/repo/base.py tests, in order:

1. git/repo/base.py:299 — isfile(curpath/gitdir) and isfile(curpath/commondir) and isfile(curpath/HEAD)
2. git/repo/base.py:320 — is_git_dir(curpath)
3. git/repo/base.py:341 — dotgit = osp.join(curpath, ".git") ← the real git dir, considered last

is_git_dir (git/repo/fun.py:60) requires only that objects/ and refs/ are directories and that HEAD is a file; HEAD's contents are never parsed. The hook path is resolved from index.repo.git_dir (git/index/fun.py:73), i.e. the mis-resolved directory.

Proof of concept

Requires only pip install GitPython==3.1.59. Full script attached as poc1_rce.py; it runs entirely in a temp directory and the payload only writes a marker file.

Attacker repository — four ordinary tracked files at the root:

| path | mode | content | |---|---|---| | gitdir | 100644 | .git\n | | commondir | 100644 | .git\n | | HEAD | 100644 | ref: refs/heads/master\n | | hooks/pre-commit | 100755 | #!/bin/sh + payload |

Victim — two ordinary calls:

repo = git.Repo.clone_from(url, dst)     # or git.Repo(dst)
repo.index.commit("automated commit")    # code execution happens here

Observed on the PyPI release 3.1.59 (Linux and Windows):

real git says the git dir is : /tmp/.../victim/.git
GitPython says it is         : /tmp/.../victim      <- shadowed
attacker's hook executed     : True
git fsck                     : (clean)

The pre-commit hook runs at git/index/base.py:1201, before write_tree(), so it fires even though the commit later fails.

Impact

A service that opens or clones an untrusted repository with GitPython — a CI runner building a fork pull request, a code-scanning/SBOM service, a mirror, a dependency bot, an AI code-review/agent tool — can be made to:

1. Execute arbitrary commands via the tracked <root>/hooks/pre-commit when the victim calls index.commit().
2. Read files outside the repository: the tracked <root>/config becomes the repository config and is parsed with merge_includes=True (git/repo/base.py:765), so [include] path = ~/.aws/credentials discloses the file. (Repo._config_reader still defaults merge_includes=True, so the hardening added in 3.1.59 for .gitmodules/GHSA-7833 does not cover this path.)
3. Write a config file to an attacker-chosen directory via an absolute tracked commondir.

Delivery is silent: git clone exits 0, git fsck (including --strict, and with transfer.fsckObjects/fetch.fsckObjects=true) reports nothing, and the clone passes every read-only probe (head.commit, branches, is_dirty(), untracked_files, iter_commits) because a tracked commondir of .git pins common_dir to the real .git.

Threat model / preconditions

• Attacker controls the content of a repository the victim opens or clones with GitPython (public repo, fork PR, mirrored dependency).
• For code execution, the victim performs a commit via GitPython's native index.commit(). For the file-read impact, opening the repo and reading config is enough.
• GIT_WORK_TREE is not a mitigation — git_dir is assigned and…

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-239g-whfq-7xj9. This link is maintained to preserve external references.

Original Description

GitPython before 3.1.60 fails to properly validate the git directory location, allowing attackers to impersonate the git directory using tracked files like gitdir, commondir, and HEAD. Attackers can execute arbitrary code by placing a malicious pre-commit hook in the tracked hooks directory that executes when a victim calls index.commit() on a cloned or opened repository.

**GitPython*is a python library used to interact with Git repositories.GitPython provides object model read and write access to your git repository. Access repository information conveniently, alter the index directly, handle remotes, or go down to low-level object database access with big-files support.With the new object database abstraction added in 0.3, its even possible to implement your own storage mechanisms, the currently available implementations are 'cgit' and pure python, which is the default.Documentation The latest documentation can be found here: As this version of GitPython depends on GitDB, which in turn needs smmap to work, installation is a bit more involved if you do a manual installation, instead of using pip.

Security Fix(es):

GitPython before 3.1.60 fails to properly validate the git directory location, allowing attackers to impersonate the git directory using tracked files like gitdir, commondir, and HEAD. Attackers can execute arbitrary code by placing a malicious pre-commit hook in the tracked hooks directory that executes when a victim calls index.commit() on a cloned or opened repository.(CVE-2026-87817)

GitPython 3.1.59 fails to restrict the --no-index option in the high-level diff API, allowing attackers to read arbitrary filesystem paths as repository operands. Attackers can combine --no-index with -I/--ignore-matching-lines to create a content-dependent Boolean oracle, repeatedly querying local files to recover single-line secrets through distinguishable success or error responses.(CVE-2026-87818)

GitPython before 3.1.60 contains a regular expression denial of service vulnerability in Actor.name_email_regex that processes commit author and committer fields. Attackers can craft a commit object with a malformed author field containing an unterminated angle bracket to cause quadratic backtracking, exhausting CPU resources for over two minutes per commit access.(CVE-2026-87819)

**GitPython*is a python library used to interact with Git repositories.GitPython provides object model read and write access to your git repository. Access repository information conveniently, alter the index directly, handle remotes, or go down to low-level object database access with big-files support.With the new object database abstraction added in 0.3, its even possible to implement your own storage mechanisms, the currently available implementations are 'cgit' and pure python, which is the default.Documentation The latest documentation can be found here: As this version of GitPython depends on GitDB, which in turn needs smmap to work, installation is a bit more involved if you do a manual installation, instead of using pip.

Security Fix(es):

GitPython before 3.1.60 fails to properly validate the git directory location, allowing attackers to impersonate the git directory using tracked files like gitdir, commondir, and HEAD. Attackers can execute arbitrary code by placing a malicious pre-commit hook in the tracked hooks directory that executes when a victim calls index.commit() on a cloned or opened repository.(CVE-2026-87817)

GitPython 3.1.59 fails to restrict the --no-index option in the high-level diff API, allowing attackers to read arbitrary filesystem paths as repository operands. Attackers can combine --no-index with -I/--ignore-matching-lines to create a content-dependent Boolean oracle, repeatedly querying local files to recover single-line secrets through distinguishable success or error responses.(CVE-2026-87818)

GitPython before 3.1.60 contains a regular expression denial of service vulnerability in Actor.name_email_regex that processes commit author and committer fields. Attackers can craft a commit object with a malformed author field containing an unterminated angle bracket to cause quadratic backtracking, exhausting CPU resources for over two minutes per commit access.(CVE-2026-87819)

**GitPython*is a python library used to interact with Git repositories.GitPython provides object model read and write access to your git repository. Access repository information conveniently, alter the index directly, handle remotes, or go down to low-level object database access with big-files support.With the new object database abstraction added in 0.3, its even possible to implement your own storage mechanisms, the currently available implementations are 'cgit' and pure python, which is the default.Documentation The latest documentation can be found here: As this version of GitPython depends on GitDB, which in turn needs smmap to work, installation is a bit more involved if you do a manual installation, instead of using pip.

Security Fix(es):

GitPython before 3.1.60 fails to properly validate the git directory location, allowing attackers to impersonate the git directory using tracked files like gitdir, commondir, and HEAD. Attackers can execute arbitrary code by placing a malicious pre-commit hook in the tracked hooks directory that executes when a victim calls index.commit() on a cloned or opened repository.(CVE-2026-87817)

GitPython 3.1.59 fails to restrict the --no-index option in the high-level diff API, allowing attackers to read arbitrary filesystem paths as repository operands. Attackers can combine --no-index with -I/--ignore-matching-lines to create a content-dependent Boolean oracle, repeatedly querying local files to recover single-line secrets through distinguishable success or error responses.(CVE-2026-87818)

GitPython before 3.1.60 contains a regular expression denial of service vulnerability in Actor.name_email_regex that processes commit author and committer fields. Attackers can craft a commit object with a malformed author field containing an unterminated angle bracket to cause quadratic backtracking, exhausting CPU resources for over two minutes per commit access.(CVE-2026-87819)

GitPython before 3.1.60 fails to properly validate the git directory location, allowing attackers to impersonate the git directory using tracked files like gitdir, commondir, and HEAD. Attackers can execute arbitrary code by placing a malicious pre-commit hook in the tracked hooks directory that executes when a victim calls index.commit() on a cloned or opened repository.

GitPython before 3.1.60 fails to properly validate the git directory location, allowing attackers to impersonate the git directory using tracked files like gitdir, commondir, and HEAD. Attackers can execute arbitrary code by placing a malicious pre-commit hook in the tracked hooks directory that executes when a victim calls index.commit() on a cloned or opened repository.

TuxCare rebuilt gitpython to address 3 CVEs. Fixed in 3.1.31.post14+tuxcare.

This update for python-GitPython fixes the following issues:

• CVE-2026-67322: environment-variable exfiltration in Repo.clone_from() URL via os.path.expandvars() (bsc#1273357).
• CVE-2026-67323: unguarded Git options passed as keyword arguments in Repo.archive() and git.ls_remote() allow for command injection (bsc#1273358).
• CVE-2026-67325: incomplete command injection blocklist fails to account for git's long-option prefix abbreviation feature and allows for bypass (bsc#1273359).
• CVE-2026-67326: failure to validate newline characters in the section parameter of config_writer() can lead to RCE via core.hooksPath (bsc#1273364).
• CVE-2026-69097: failure to properly escape section names in Git config files allows for injection of arbitrary configuration directives through malicious submodule names and can lead to RCE (bsc#1273414).
• CVE-2026-73619: incomplete denylist in the unsafe_git_archive_options guard that omits --add-file and --add- virtual-file options can lead to arbitrary file reads (bsc#1275755).
• CVE-2026-73620: failure to guard Git option forwarding in IndexFile.checkout() and TagReference.create() can lead to arbitrary file reads and writes (bsc#1275756).
• CVE-2026-73621: argument injection in the Commit.count() method allows for destruction/blanking of arbitrary files (bsc#1275757).
• CVE-2026-73622: failure to disable environment variable expansion in Remote.create() and Submodule.add() URL handling allows for secret exfiltration via URLs containing variable references (bsc#1275751).
• CVE-2026-73623: incomplete denylist in unsafe_git_clone_options that omits --template allows for arbitrary command execution (bsc#1275752).
• CVE-2026-73624: Diffable.diff method fails to validate git options passed through kwargs, which can lead to arbitrary file writes (bsc#1275753).
• CVE-2026-73625: check_unsafe_options guard bypass via smuggling of git options inside single-character kwarg values can lead to arbitrary code execution (bsc#1275754).
• CVE-2026-76217: failure to validate options passed to git rm and git checkout commands in IndexFile.remove() and Head.checkout() can lead to arbitrary file reads (bsc#1275745).
• CVE-2026-76218: unguarded git option forwarding in Repo.init allows for arbitrary command execution (bsc#1275746).
• CVE-2026-76219: unguarded git read-tree option forwarding in IndexFile.from_tree/reset/merge_tree can lead to arbitrary file overwrites (bsc#1275747).
• CVE-2026-76220: check_unsafe_options guard can be bypassed by combining a single-character kwarg with split_single_char_options=False, which can lead to arbitrary OS command injection (bsc#1275748).
• CVE-2026-76221: config-name injection in the option-name validator can lead to remote code execution (bsc#1275749).
• CVE-2026-76222: failure to validate submodule names from .gitmodules files allows creation of Git repositories at arbitrary filesystem paths outside the intended clone directory (bsc#1275750).
• CVE-2026-78675: failure to disable merge_includes when parsing .gitmodules can lead to discloseure of local file contents when arbitrary file paths are included via [include] directives (bsc#1276434).
• CVE-2026-78676: failure to safely re-serialize multi-line git-config values during write operations can corrupt dormant quoted values into live injected directives (bsc#1276433).
• CVE-2026-78677: omission of --separate-git-dir from unsafe_git_clone_options allows for creation of arbitrary git directories outside the intended clone destination (bsc#1276432).
• CVE-2026-78678: incomplete denylist in the unsafe_git_revision_options guard that omits --contents and -S options allows for reading of arbitrary files when these options to are passed to Repo.blame() (bsc#1276431).
• CVE-2026-78679: positional reference parameter can bypass an unsafe option guard and allows for arbitrary file read via…

This update for python-GitPython fixes the following issues:

• CVE-2026-87817: failure to properly validade the git directory location allows attackers to impersonate the git directory using tracked files and execute arbitrary code by placing pre-commit hooks in the tracked hooks directory (bsc#1279905).
• CVE-2026-87818: failure to restrict the --no-index option in the high-level diff API allows attackers to read arbitrary filesystem paths as repository operands and create content-dependent Boolean oracles (bsc#1279906).
• CVE-2026-87819: quadratic backtracking in the Actor.name_email_regex regular expression allows attackers to cause CPU exhaustion and a DoS via a commit with a malformed author field (bsc#1279907).