<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://vulnerability.circl.lu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Wed, 30 Sep 2026 22:37:05 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-67323 — GitPython before 3.1.51 Command Injection via unguarded Git options</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2026-67323</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; gitpython-developers GitPython&lt;/p&gt;
&lt;p&gt;GitPython before 3.1.51 fails to guard against dangerous Git options passed as keyword arguments in Repo.archive() and git.ls_remote(), allowing command injection via options such as --exec/--upload-pack (leading to arbitrary command execution). Additionally, Repo.iter_commits() and Repo.blame() do not check for leading-dash revision arguments, so a revision like --output=&amp;lt;path&amp;gt; can cause Git to open and truncate an arbitrary file. Exploitation requires an application that passes attacker-controlled arguments to these methods.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; gitpython-developers GitPython&lt;/p&gt;
&lt;p&gt;GitPython before 3.1.51 fails to guard against dangerous Git options passed as keyword arguments in Repo.archive() and git.ls_remote(), allowing command injection via options such as --exec/--upload-pack (leading to arbitrary command execution). Additionally, Repo.iter_commits() and Repo.blame() do not check for leading-dash revision arguments, so a revision like --output=&amp;lt;path&amp;gt; can cause Git to open and truncate an arbitrary file. Exploitation requires an application that passes attacker-controlled arguments to these methods.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2026-67323</guid>
    </item>
    <item>
      <title>GHSA-956x-8gvw-wg5v — GitPython: command injection via unguarded Git options in `Repo.archive()`, `git.ls_remote()`, and arbitrary file overw…</title>
      <link>https://vulnerability.circl.lu/vuln/ghsa-956x-8gvw-wg5v</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: GitPython&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;GitPython already know that --upload-pack / --exec are command-exec vectors, they are denylist in
git/remote.py:535 and check by Git.check_unsafe_options() (git/cmd.py:963), the thing is this
check him he is only call from fetch, pull, push and clone_from, everything else who build a git
argv from caller values just go through, no check, three examples&lt;/p&gt;
&lt;p&gt;## Code analysis&lt;/p&gt;
&lt;p&gt;Repo.archive (git/repo/base.py:1623) do self.git.archive(&amp;#34;--&amp;#34;, treeish, *path, **kwargs), the
treeish is after the --, but the kwargs get dashify by transform_kwarg (git/cmd.py:1487) and
they land before it, so {&amp;#34;remote&amp;#34;: &amp;#34;.&amp;#34;, &amp;#34;exec&amp;#34;: &amp;#34;&amp;lt;cmd&amp;gt;&amp;#34;} give
git archive --remote=. --exec=&amp;lt;cmd&amp;gt; -- &amp;lt;rev&amp;gt;, the --remote spawn the upload-archive helper and
--exec choose which binary that is, done, default git config, no protocol.ext.allow needed, and
archive already document caller kwargs (format, prefix, path) so pass a dict is normal usage&lt;/p&gt;
&lt;p&gt;repo.git.ls_remote(url, upload_pack=&amp;#34;&amp;lt;cmd&amp;gt;&amp;#34;), same builder, same result, it&amp;#39;s exactly the kwarg
gap that CVE-2026-42215 close for fetch/pull/push/clone_from, except the dynamic
repo.git.&amp;lt;anything&amp;gt;(**user_dict) surface him he never got the fix&lt;/p&gt;
&lt;p&gt;Repo.iter_commits / Repo.blame (git/objects/commit.py:348, git/repo/base.py:1199) put the rev
before the --, no leading-dash check, a &amp;#34;branch name&amp;#34; like --output=/etc/whatever become
git rev-list --output=... --, and git he open and truncate that file before he even validate the
revision, the file is gone even if the command error ri…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: GitPython&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;GitPython already know that --upload-pack / --exec are command-exec vectors, they are denylist in
git/remote.py:535 and check by Git.check_unsafe_options() (git/cmd.py:963), the thing is this
check him he is only call from fetch, pull, push and clone_from, everything else who build a git
argv from caller values just go through, no check, three examples&lt;/p&gt;
&lt;p&gt;## Code analysis&lt;/p&gt;
&lt;p&gt;Repo.archive (git/repo/base.py:1623) do self.git.archive(&amp;#34;--&amp;#34;, treeish, *path, **kwargs), the
treeish is after the --, but the kwargs get dashify by transform_kwarg (git/cmd.py:1487) and
they land before it, so {&amp;#34;remote&amp;#34;: &amp;#34;.&amp;#34;, &amp;#34;exec&amp;#34;: &amp;#34;&amp;lt;cmd&amp;gt;&amp;#34;} give
git archive --remote=. --exec=&amp;lt;cmd&amp;gt; -- &amp;lt;rev&amp;gt;, the --remote spawn the upload-archive helper and
--exec choose which binary that is, done, default git config, no protocol.ext.allow needed, and
archive already document caller kwargs (format, prefix, path) so pass a dict is normal usage&lt;/p&gt;
&lt;p&gt;repo.git.ls_remote(url, upload_pack=&amp;#34;&amp;lt;cmd&amp;gt;&amp;#34;), same builder, same result, it&amp;#39;s exactly the kwarg
gap that CVE-2026-42215 close for fetch/pull/push/clone_from, except the dynamic
repo.git.&amp;lt;anything&amp;gt;(**user_dict) surface him he never got the fix&lt;/p&gt;
&lt;p&gt;Repo.iter_commits / Repo.blame (git/objects/commit.py:348, git/repo/base.py:1199) put the rev
before the --, no leading-dash check, a &amp;#34;branch name&amp;#34; like --output=/etc/whatever become
git rev-list --output=... --, and git he open and truncate that file before he even validate the
revision, the file is gone even if the command error ri…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ghsa-956x-8gvw-wg5v</guid>
    </item>
    <item>
      <title>PYSEC-2026-3839 — GitPython: command injection via unguarded Git options in `Repo.archive()`, `git.ls_remote()`, and arbitrary file overw…</title>
      <link>https://vulnerability.circl.lu/vuln/pysec-2026-3839</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: gitpython&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;GitPython already know that --upload-pack / --exec are command-exec vectors, they are denylist in
git/remote.py:535 and check by Git.check_unsafe_options() (git/cmd.py:963), the thing is this
check him he is only call from fetch, pull, push and clone_from, everything else who build a git
argv from caller values just go through, no check, three examples&lt;/p&gt;
&lt;p&gt;## Code analysis&lt;/p&gt;
&lt;p&gt;Repo.archive (git/repo/base.py:1623) do self.git.archive(&amp;#34;--&amp;#34;, treeish, *path, **kwargs), the
treeish is after the --, but the kwargs get dashify by transform_kwarg (git/cmd.py:1487) and
they land before it, so {&amp;#34;remote&amp;#34;: &amp;#34;.&amp;#34;, &amp;#34;exec&amp;#34;: &amp;#34;&amp;lt;cmd&amp;gt;&amp;#34;} give
git archive --remote=. --exec=&amp;lt;cmd&amp;gt; -- &amp;lt;rev&amp;gt;, the --remote spawn the upload-archive helper and
--exec choose which binary that is, done, default git config, no protocol.ext.allow needed, and
archive already document caller kwargs (format, prefix, path) so pass a dict is normal usage&lt;/p&gt;
&lt;p&gt;repo.git.ls_remote(url, upload_pack=&amp;#34;&amp;lt;cmd&amp;gt;&amp;#34;), same builder, same result, it&amp;#39;s exactly the kwarg
gap that CVE-2026-42215 close for fetch/pull/push/clone_from, except the dynamic
repo.git.&amp;lt;anything&amp;gt;(**user_dict) surface him he never got the fix&lt;/p&gt;
&lt;p&gt;Repo.iter_commits / Repo.blame (git/objects/commit.py:348, git/repo/base.py:1199) put the rev
before the --, no leading-dash check, a &amp;#34;branch name&amp;#34; like --output=/etc/whatever become
git rev-list --output=... --, and git he open and truncate that file before he even validate the
revision, the file is gone even if the command error ri…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: gitpython&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;GitPython already know that --upload-pack / --exec are command-exec vectors, they are denylist in
git/remote.py:535 and check by Git.check_unsafe_options() (git/cmd.py:963), the thing is this
check him he is only call from fetch, pull, push and clone_from, everything else who build a git
argv from caller values just go through, no check, three examples&lt;/p&gt;
&lt;p&gt;## Code analysis&lt;/p&gt;
&lt;p&gt;Repo.archive (git/repo/base.py:1623) do self.git.archive(&amp;#34;--&amp;#34;, treeish, *path, **kwargs), the
treeish is after the --, but the kwargs get dashify by transform_kwarg (git/cmd.py:1487) and
they land before it, so {&amp;#34;remote&amp;#34;: &amp;#34;.&amp;#34;, &amp;#34;exec&amp;#34;: &amp;#34;&amp;lt;cmd&amp;gt;&amp;#34;} give
git archive --remote=. --exec=&amp;lt;cmd&amp;gt; -- &amp;lt;rev&amp;gt;, the --remote spawn the upload-archive helper and
--exec choose which binary that is, done, default git config, no protocol.ext.allow needed, and
archive already document caller kwargs (format, prefix, path) so pass a dict is normal usage&lt;/p&gt;
&lt;p&gt;repo.git.ls_remote(url, upload_pack=&amp;#34;&amp;lt;cmd&amp;gt;&amp;#34;), same builder, same result, it&amp;#39;s exactly the kwarg
gap that CVE-2026-42215 close for fetch/pull/push/clone_from, except the dynamic
repo.git.&amp;lt;anything&amp;gt;(**user_dict) surface him he never got the fix&lt;/p&gt;
&lt;p&gt;Repo.iter_commits / Repo.blame (git/objects/commit.py:348, git/repo/base.py:1199) put the rev
before the --, no leading-dash check, a &amp;#34;branch name&amp;#34; like --output=/etc/whatever become
git rev-list --output=... --, and git he open and truncate that file before he even validate the
revision, the file is gone even if the command error ri…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/pysec-2026-3839</guid>
    </item>
  </channel>
</rss>
