Affected: Homebrew: aider

### Summary GitPython computes the on-disk location of a submodule's separate Git directory (`.git/modules/<name>`) from the submodule's `.gitmodules` section name with no validation. Because that name is fully attacker-controlled content of a cloned repository, a malicious repository can set a submodule name to a traversal string (e.g. `../../../../home/victim/.something`) and cause GitPython to create and initialize a full Git repository at an attacker-chosen filesystem path outside the intended clone directory. The only precondition is that a victim clones the malicious repository with GitPython and runs submodule initialization (`submodule_update(init=True)` / `sm.update(init=True)`), a very common and often automatic step. Core Git itself already blocks this exact attack class (CVE-2018-11235), but GitPython's independent reimplementation never adopted an equivalent check.

### Details `src/GitPython/git/objects/submodule/util.py` `sm_name()` strips the `submodule "` / `"` wrapper from a `.gitmodules` `[submodule "..."]` header and returns the result unchecked. `Submodule.iter_items()` in `src/GitPython/git/objects/submodule/base.py` reads this via `sm_name(sms)` and assigns it to `sm._name`; unlike the submodule `path`, `name` is never used for a tree lookup, so it is never implicitly validated. `Submodule._module_abspath()` then builds `osp.join(parent_repo.git_dir, "modules", name)` - `os.path.join` does not normalize `../` sequences. `Submodule._clone_repo()` passes…

GitPython before 3.1.58 fails to validate submodule names from .gitmodules files, allowing attackers to create Git repositories at arbitrary filesystem paths outside the intended clone directory. Attackers can craft malicious repositories with traversal sequences in submodule names that GitPython processes during submodule initialization, creating attacker-controlled Git repositories at escaped filesystem locations.

Affected: PyPI: GitPython

### Summary GitPython computes the on-disk location of a submodule's separate Git directory (`.git/modules/<name>`) from the submodule's `.gitmodules` section name with no validation. Because that name is fully attacker-controlled content of a cloned repository, a malicious repository can set a submodule name to a traversal string (e.g. `../../../../home/victim/.something`) and cause GitPython to create and initialize a full Git repository at an attacker-chosen filesystem path outside the intended clone directory. The only precondition is that a victim clones the malicious repository with GitPython and runs submodule initialization (`submodule_update(init=True)` / `sm.update(init=True)`), a very common and often automatic step. Core Git itself already blocks this exact attack class (CVE-2018-11235), but GitPython's independent reimplementation never adopted an equivalent check.

### Details `src/GitPython/git/objects/submodule/util.py` `sm_name()` strips the `submodule "` / `"` wrapper from a `.gitmodules` `[submodule "..."]` header and returns the result unchecked. `Submodule.iter_items()` in `src/GitPython/git/objects/submodule/base.py` reads this via `sm_name(sms)` and assigns it to `sm._name`; unlike the submodule `path`, `name` is never used for a tree lookup, so it is never implicitly validated. `Submodule._module_abspath()` then builds `osp.join(parent_repo.git_dir, "modules", name)` - `os.path.join` does not normalize `../` sequences. `Submodule._clone_repo()` passes…

Affected: openEuler:24.03-LTS-SP1: python-GitPython

GitPython is a python library used to interact with git repositories, high-level like git-porcelain, or low-level like git-plumbing. Security Fix(es):

GitPython before 3.1.57 contains an incomplete denylist in the unsafe_git_archive_options guard that omits --add-file and --add-virtual-file options. Attackers can supply these options to Repo.archive() to read arbitrary files from the filesystem and include them in the returned archive.(CVE-2026-73619)

GitPython before 3.1.57 fails to guard git option forwarding in IndexFile.checkout() and TagReference.create(), allowing attackers to pass unsafe options via kwargs. Attackers can use --prefix to overwrite arbitrary files with repository content or -F to read arbitrary files returned in-band.(CVE-2026-73620)

GitPython before 3.1.56 contains an argument injection vulnerability in the Commit.count() method, which forwards keyword arguments to &apos;git rev-list&apos; without the check_unsafe_options guard present in the sibling iter_items method. An attacker who can control options passed to Commit.count (e.g., via an application that forwards a user-supplied options dict) can supply output=&lt;path&gt;, causing &apos;git rev-list --output=&lt;path&gt;&apos; to open and truncate the target file to zero bytes before revision parsing. This allows destruction/blanking of an arbitrary file at the process&apos;s privilege level (no content control, 0-byte truncation).(CVE-2026-73621)

GitPython before 3.1.55 fails to disable env…

python313-GitPython-3.1.59-2.1 on GA media

Affected: PyPI: gitpython

GitPython before 3.1.58 fails to validate submodule names from .gitmodules files, allowing attackers to create Git repositories at arbitrary filesystem paths outside the intended clone directory. Attackers can craft malicious repositories with traversal sequences in submodule names that GitPython processes during submodule initialization, creating attacker-controlled Git repositories at escaped filesystem locations.

jetty: Eclipse Jetty: Information disclosure due to retained HTTP/1.1 trailers across connections ansible-core: argument injection in ansible-galaxy role install leads to arbitrary code execution ansible-core: argument injection in ansible-galaxy collection install via git clone (incomplete fix for CVE-2026-11332) aiohttp: AIOHTTP: Arbitrary code execution via untrusted input to CookieJar.load() GitPython: GitPython: Arbitrary command execution due to bypass of dangerous Git option checks GitPython: GitPython: Arbitrary code execution via improper validation of clone options GitPython: GitPython: Arbitrary code execution via injected newlines in Git configuration ruby-jwt: ruby-jwt: Authentication bypass due to empty key in HMAC verification jackson-databind: jackson-databind: Arbitrary code execution via PolymorphicTypeValidator bypass com.fasterxml.jackson.core/jackson-core: tools.jackson.core/jackson-core: jackson-core: Denial of Service via incomplete fix in async JSON parser aiohttp: AIOHTTP: HTTP Request Smuggling via WebSocket Upgrade aiohttp: AIOHTTP: Denial of Service via malformed HTTP responses gitpython: GitPython: Arbitrary file overwrite and read via unsafe git option forwarding gitpython: GitPython: Information disclosure via environment variable expansion in URL handling gitpython: GitPython: Remote Code Execution via malicious Git template gitpython: GitPython: Arbitrary File Overwrite via improper git option validation gitpython: GitPython: Remote Code Exec…

Affected: Ubuntu:Pro:14.04:LTS: python-git, Ubuntu:Pro:16.04:LTS: python-git, Ubuntu:Pro:18.04:LTS: python-git, Ubuntu:Pro:20.04:LTS: python-git, Ubuntu:Pro:22.04:LTS: python-git, Ubuntu:Pro:24.04:LTS: python-git, Ubuntu:Pro:26.04:LTS: python-git

GitPython before 3.1.58 fails to validate submodule names from .gitmodules files, allowing attackers to create Git repositories at arbitrary filesystem paths outside the intended clone directory. Attackers can craft malicious repositories with traversal sequences in submodule names that GitPython processes during submodule initialization, creating attacker-controlled Git repositories at escaped filesystem locations.

Ein Angreifer kann mehrere Schwachstellen in Red Hat Ansible Automation Platform ausnutzen, um seine Privilegien zu erhöhen, beliebigen Code auszuführen, Sicherheitsmaßnahmen zu umgehen, Daten zu manipulieren oder offenzulegen und einen Denial-of-Service-Zustand herbeizuführen.