<?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>Tue, 29 Sep 2026 22:58:18 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-44244 — GitPython: Newline injection in config_writer().set_value() enables RCE via core.hooksPath</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2026-44244</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; gitpython-developers GitPython&lt;/p&gt;
&lt;p&gt;GitPython is a python library used to interact with Git repositories. Prior to version 3.1.49, GitConfigParser.set_value() passes values to Python&amp;#39;s configparser without validating for newlines. GitPython&amp;#39;s own _write() converts embedded newlines into indented continuation lines (e.g. \n becomes \n\t), but Git still accepts an indented [core] stanza as a section header — so the injected core.hooksPath becomes effective configuration. Any Git operation that invokes hooks (commit, merge, checkout) will then execute scripts from the attacker-controlled path. This issue has been patched in version 3.1.49.&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 is a python library used to interact with Git repositories. Prior to version 3.1.49, GitConfigParser.set_value() passes values to Python&amp;#39;s configparser without validating for newlines. GitPython&amp;#39;s own _write() converts embedded newlines into indented continuation lines (e.g. \n becomes \n\t), but Git still accepts an indented [core] stanza as a section header — so the injected core.hooksPath becomes effective configuration. Any Git operation that invokes hooks (commit, merge, checkout) will then execute scripts from the attacker-controlled path. This issue has been patched in version 3.1.49.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2026-44244</guid>
    </item>
    <item>
      <title>GHSA-v87r-6q3f-2j67 — GitPython: Newline injection in config_writer().set_value() enables RCE via core.hooksPath</title>
      <link>https://vulnerability.circl.lu/vuln/ghsa-v87r-6q3f-2j67</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: GitPython&lt;/p&gt;
&lt;p&gt;`GitConfigParser.set_value()` passes values to Python&amp;#39;s `configparser` without validating for newlines. GitPython&amp;#39;s own `_write()` converts embedded newlines into indented continuation lines (e.g. `\n` becomes `\n\t`), but Git still accepts an indented `[core]` stanza as a section header — so the injected `core.hooksPath` becomes effective configuration. Any Git operation that invokes hooks (commit, merge, checkout) will then execute scripts from the attacker-controlled path.&lt;/p&gt;
&lt;p&gt;The vulnerability is not merely malformed config output: GitPython&amp;#39;s own writer converts embedded newlines into indented continuation lines, but Git still accepts an indented `[core]` stanza as a section header, so the injected `core.hooksPath` becomes effective configuration.&lt;/p&gt;
&lt;p&gt;This was found while auditing MLRun&amp;#39;s `project.push()` method, which passes `author_name` and `author_email` directly to `config_writer().set_value()` with no sanitization. Both parameters cross a trust boundary — they are caller-supplied API inputs that end up in `.git/config`.&lt;/p&gt;
&lt;p&gt;PoC (standalone, no MLRun required):&lt;/p&gt;
&lt;p&gt;```python
import git, subprocess, os&lt;/p&gt;
&lt;p&gt;repo = git.Repo(&amp;#34;/tmp/testrepo&amp;#34;)&lt;/p&gt;
&lt;p&gt;with repo.config_writer() as cw:
    cw.set_value(&amp;#34;user&amp;#34;, &amp;#34;name&amp;#34;, &amp;#34;foo\n[core]\nhooksPath=/tmp/hooks&amp;#34;)&lt;/p&gt;
&lt;p&gt;r = subprocess.run([&amp;#34;git&amp;#34;, &amp;#34;config&amp;#34;, &amp;#34;core.hooksPath&amp;#34;], cwd=&amp;#34;/tmp/testrepo&amp;#34;, capture_output=True, text=True)
assert r.returncode == 0
print(r.stdout.strip())  # /tmp/hooks&lt;/p&gt;
&lt;p&gt;os.makedirs(&amp;#34;/tmp/hooks&amp;#34;, exist_ok=True)
open(&amp;#34;/tmp/hooks/pre-commit&amp;#34;,…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: GitPython&lt;/p&gt;
&lt;p&gt;`GitConfigParser.set_value()` passes values to Python&amp;#39;s `configparser` without validating for newlines. GitPython&amp;#39;s own `_write()` converts embedded newlines into indented continuation lines (e.g. `\n` becomes `\n\t`), but Git still accepts an indented `[core]` stanza as a section header — so the injected `core.hooksPath` becomes effective configuration. Any Git operation that invokes hooks (commit, merge, checkout) will then execute scripts from the attacker-controlled path.&lt;/p&gt;
&lt;p&gt;The vulnerability is not merely malformed config output: GitPython&amp;#39;s own writer converts embedded newlines into indented continuation lines, but Git still accepts an indented `[core]` stanza as a section header, so the injected `core.hooksPath` becomes effective configuration.&lt;/p&gt;
&lt;p&gt;This was found while auditing MLRun&amp;#39;s `project.push()` method, which passes `author_name` and `author_email` directly to `config_writer().set_value()` with no sanitization. Both parameters cross a trust boundary — they are caller-supplied API inputs that end up in `.git/config`.&lt;/p&gt;
&lt;p&gt;PoC (standalone, no MLRun required):&lt;/p&gt;
&lt;p&gt;```python
import git, subprocess, os&lt;/p&gt;
&lt;p&gt;repo = git.Repo(&amp;#34;/tmp/testrepo&amp;#34;)&lt;/p&gt;
&lt;p&gt;with repo.config_writer() as cw:
    cw.set_value(&amp;#34;user&amp;#34;, &amp;#34;name&amp;#34;, &amp;#34;foo\n[core]\nhooksPath=/tmp/hooks&amp;#34;)&lt;/p&gt;
&lt;p&gt;r = subprocess.run([&amp;#34;git&amp;#34;, &amp;#34;config&amp;#34;, &amp;#34;core.hooksPath&amp;#34;], cwd=&amp;#34;/tmp/testrepo&amp;#34;, capture_output=True, text=True)
assert r.returncode == 0
print(r.stdout.strip())  # /tmp/hooks&lt;/p&gt;
&lt;p&gt;os.makedirs(&amp;#34;/tmp/hooks&amp;#34;, exist_ok=True)
open(&amp;#34;/tmp/hooks/pre-commit&amp;#34;,…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ghsa-v87r-6q3f-2j67</guid>
    </item>
    <item>
      <title>PYSEC-2026-2163</title>
      <link>https://vulnerability.circl.lu/vuln/pysec-2026-2163</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: gitpython&lt;/p&gt;
&lt;p&gt;GitPython is a python library used to interact with Git repositories. Prior to version 3.1.49, GitConfigParser.set_value() passes values to Python&amp;#39;s configparser without validating for newlines. GitPython&amp;#39;s own _write() converts embedded newlines into indented continuation lines (e.g. \n becomes \n\t), but Git still accepts an indented [core] stanza as a section header — so the injected core.hooksPath becomes effective configuration. Any Git operation that invokes hooks (commit, merge, checkout) will then execute scripts from the attacker-controlled path. This issue has been patched in version 3.1.49.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: gitpython&lt;/p&gt;
&lt;p&gt;GitPython is a python library used to interact with Git repositories. Prior to version 3.1.49, GitConfigParser.set_value() passes values to Python&amp;#39;s configparser without validating for newlines. GitPython&amp;#39;s own _write() converts embedded newlines into indented continuation lines (e.g. \n becomes \n\t), but Git still accepts an indented [core] stanza as a section header — so the injected core.hooksPath becomes effective configuration. Any Git operation that invokes hooks (commit, merge, checkout) will then execute scripts from the attacker-controlled path. This issue has been patched in version 3.1.49.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/pysec-2026-2163</guid>
    </item>
  </channel>
</rss>
