https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 29 Sep 2026 23:46:38 +0000 https://vulnerability.circl.lu/vuln/cve-2026-76222 <p><strong>Affected:</strong> gitpython-developers GitPython</p> <p>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.</p> <p><strong>Affected:</strong> gitpython-developers GitPython</p> <p>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.</p> https://vulnerability.circl.lu/vuln/cve-2026-76222 https://vulnerability.circl.lu/vuln/ghsa-hmq2-w58f-27jc <p><strong>Affected:</strong> PyPI: GitPython</p> <p>### Summary GitPython computes the on-disk location of a submodule&#39;s separate Git directory (`.git/modules/&lt;name&gt;`) from the submodule&#39;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&#39;s independent reimplementation never adopted an equivalent check.</p> <p>### Details `src/GitPython/git/objects/submodule/util.py` `sm_name()` strips the `submodule &#34;` / `&#34;` wrapper from a `.gitmodules` `[submodule &#34;...&#34;]` 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, &#34;modules&#34;, name)` - `os.path.join` does not normalize `../` sequences. `Submodule._clone_repo()` passes…</p> <p><strong>Affected:</strong> PyPI: GitPython</p> <p>### Summary GitPython computes the on-disk location of a submodule&#39;s separate Git directory (`.git/modules/&lt;name&gt;`) from the submodule&#39;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&#39;s independent reimplementation never adopted an equivalent check.</p> <p>### Details `src/GitPython/git/objects/submodule/util.py` `sm_name()` strips the `submodule &#34;` / `&#34;` wrapper from a `.gitmodules` `[submodule &#34;...&#34;]` 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, &#34;modules&#34;, name)` - `os.path.join` does not normalize `../` sequences. `Submodule._clone_repo()` passes…</p> https://vulnerability.circl.lu/vuln/ghsa-hmq2-w58f-27jc https://vulnerability.circl.lu/vuln/pysec-2026-3784 <p><strong>Affected:</strong> PyPI: gitpython</p> <p>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.</p> <p><strong>Affected:</strong> PyPI: gitpython</p> <p>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.</p> https://vulnerability.circl.lu/vuln/pysec-2026-3784