https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Thu, 29 Oct 2026 08:39:29 +0000 https://db.gcve.eu/vuln/cve-2026-110855 <p><strong>Affected:</strong> gitpython-developers GitPython</p> <p>GitPython before 3.2.0 contains an information disclosure vulnerability that allows malicious repositories to expand environment variables via separate_git_dir in Repo._clone(), which omits expand_vars=False when calling Git.polish_url(). Attackers can craft a .gitmodules submodule name containing variable syntax so that clone plus submodule_update exposes secrets in .git/modules directory names and DEBUG logs.</p> <p><strong>Affected:</strong> gitpython-developers GitPython</p> <p>GitPython before 3.2.0 contains an information disclosure vulnerability that allows malicious repositories to expand environment variables via separate_git_dir in Repo._clone(), which omits expand_vars=False when calling Git.polish_url(). Attackers can craft a .gitmodules submodule name containing variable syntax so that clone plus submodule_update exposes secrets in .git/modules directory names and DEBUG logs.</p> https://db.gcve.eu/vuln/cve-2026-110855 https://db.gcve.eu/vuln/ghsa-fx3j-rwgx-fr94 <p><strong>Affected:</strong> PyPI: GitPython</p> <p>### Summary `Repo._clone()`&#39;s handling of `separate_git_dir` never disables `Git.polish_url()`&#39;s environment-variable expansion, unlike every other caller of that helper that handles attacker-influenced data. Since `separate_git_dir` can be derived from an attacker-controlled `.gitmodules` submodule name, a completely ordinary `clone` + `submodule_update(init=True, recursive=True)` on a malicious repository expands an environment variable of the attacker&#39;s choosing and exposes its value both as a persistent on-disk directory name and, whenever DEBUG-level logging is enabled (a common CI/verbose-logging configuration), in a `Popen(...)` log line that is not redacted the way credential-bearing arguments are.</p> <p>### Root cause / Details `git/repo/base.py`&#39;s `_clone()` has:</p> <p>```python sep_dir = kwargs.get(&#34;separate_git_dir&#34;) if sep_dir: kwargs[&#34;separate_git_dir&#34;] = Git.polish_url(sep_dir) ```</p> <p>This is the only remaining `Git.polish_url()` call site handling attacker-influenced data that does not pass `expand_vars=False` (there is one other unguarded call site, `clone_path` at line 1537, but its input is the caller&#39;s own local destination path, not attacker-controlled). The sibling fixes for `GHSA-94p4-4cq8-9g67`/`GHSA-rwj8-pgh3-r573` added `expand_vars=False` to `clone_url` (5 lines below this one, in the same function), `git/repo/base.py:1599`, `remote.py:814`, and `submodule/base.py:686` — this one did not receive it. (`submodule/root.py` also currently sets `expand_vars=Fal…</p> <p><strong>Affected:</strong> PyPI: GitPython</p> <p>### Summary `Repo._clone()`&#39;s handling of `separate_git_dir` never disables `Git.polish_url()`&#39;s environment-variable expansion, unlike every other caller of that helper that handles attacker-influenced data. Since `separate_git_dir` can be derived from an attacker-controlled `.gitmodules` submodule name, a completely ordinary `clone` + `submodule_update(init=True, recursive=True)` on a malicious repository expands an environment variable of the attacker&#39;s choosing and exposes its value both as a persistent on-disk directory name and, whenever DEBUG-level logging is enabled (a common CI/verbose-logging configuration), in a `Popen(...)` log line that is not redacted the way credential-bearing arguments are.</p> <p>### Root cause / Details `git/repo/base.py`&#39;s `_clone()` has:</p> <p>```python sep_dir = kwargs.get(&#34;separate_git_dir&#34;) if sep_dir: kwargs[&#34;separate_git_dir&#34;] = Git.polish_url(sep_dir) ```</p> <p>This is the only remaining `Git.polish_url()` call site handling attacker-influenced data that does not pass `expand_vars=False` (there is one other unguarded call site, `clone_path` at line 1537, but its input is the caller&#39;s own local destination path, not attacker-controlled). The sibling fixes for `GHSA-94p4-4cq8-9g67`/`GHSA-rwj8-pgh3-r573` added `expand_vars=False` to `clone_url` (5 lines below this one, in the same function), `git/repo/base.py:1599`, `remote.py:814`, and `submodule/base.py:686` — this one did not receive it. (`submodule/root.py` also currently sets `expand_vars=Fal…</p> https://db.gcve.eu/vuln/ghsa-fx3j-rwgx-fr94