Affected: Homebrew: aider

`GitConfigParser.set_value()` passes values to Python's `configparser` without validating for newlines. GitPython'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.

The vulnerability is not merely malformed config output: GitPython'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.

This was found while auditing MLRun'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`.

PoC (standalone, no MLRun required):

```python import git, subprocess, os

repo = git.Repo("/tmp/testrepo")

with repo.config_writer() as cw: cw.set_value("user", "name", "foo\n[core]\nhooksPath=/tmp/hooks")

r = subprocess.run(["git", "config", "core.hooksPath"], cwd="/tmp/testrepo", capture_output=True, text=True) assert r.returncode == 0 print(r.stdout.strip()) # /tmp/hooks

os.makedirs("/tmp/hooks", exist_ok=True) open("/tmp/hooks/pre-commit",…

GitPython is a python library used to interact with Git repositories. Prior to version 3.1.49, GitConfigParser.set_value() passes values to Python's configparser without validating for newlines. GitPython'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.

Affected: PyPI: GitPython

`GitConfigParser.set_value()` passes values to Python's `configparser` without validating for newlines. GitPython'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.

The vulnerability is not merely malformed config output: GitPython'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.

This was found while auditing MLRun'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`.

PoC (standalone, no MLRun required):

```python import git, subprocess, os

repo = git.Repo("/tmp/testrepo")

with repo.config_writer() as cw: cw.set_value("user", "name", "foo\n[core]\nhooksPath=/tmp/hooks")

r = subprocess.run(["git", "config", "core.hooksPath"], cwd="/tmp/testrepo", capture_output=True, text=True) assert r.returncode == 0 print(r.stdout.strip()) # /tmp/hooks

os.makedirs("/tmp/hooks", exist_ok=True) open("/tmp/hooks/pre-commit",…

Affected: openEuler:24.03-LTS: 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):

### Summary GitPython blocks dangerous Git options such as `--upload-pack` and `--receive-pack` by default, but the equivalent Python kwargs `upload_pack` and `receive_pack` bypass that check. If an application passes attacker-controlled kwargs into `Repo.clone_from()`, `Remote.fetch()`, `Remote.pull()`, or `Remote.push()`, this leads to arbitrary command execution even when `allow_unsafe_options` is left at its default value of `False`.

### Details GitPython explicitly treats helper-command options as unsafe because they can be used to execute arbitrary commands:

- `git/repo/base.py:145-153` marks clone options such as `--upload-pack`, `-u`, `--config`, and `-c` as unsafe. - `git/remote.py:535-548` marks fetch/pull/push options such as `--upload-pack`, `--receive-pack`, and `--exec` as unsafe.

The vulnerable API paths check the raw kwarg names before they're its normalized into command-line flags:

- `Repo.clone_from()` checks `list(kwargs.keys())` in `git/repo/base.py:1387-1390` - `Remote.fetch()` checks `list(kwargs.keys())` in `git/remote.py:1070-1071` - `Remote.pull()` checks `list(kwargs.keys())` in `git/remote.py:1124-1125` - `Remote.push()` checks `list(kwargs.keys())` in `git/remote.py:1197-1198`

That validation is performed by `Git.check_unsafe_options()` in `git/cmd.py:948-961`. The validator correctly…

python311-GitPython-3.1.49-1.1 on GA media

Affected: PyPI: gitpython

GitPython is a python library used to interact with Git repositories. Prior to version 3.1.49, GitConfigParser.set_value() passes values to Python's configparser without validating for newlines. GitPython'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.

lodash: lodash: Arbitrary code execution via untrusted input in template imports fast-uri: fast-uri: Path traversal vulnerability allows bypass of security policies fast-uri: fast-uri: URI authority bypass due to improper delimiter handling python-pip: Path traversal via malicious entry point name in pip wheel installation allows arbitrary file overwrite ansible-core: argument injection in ansible-galaxy role install leads to arbitrary code execution aap-gateway: missing requestHeadersToRemove allows mTLS bypass via Subject header spoofing pulpcore: pulpcore: relative_path_validator bypass via directory traversal in FilesystemExport golang.org/x/net/html: golang.org/x/net/html: Arbitrary code execution via Cross-Site Scripting golang.org/x/net/html: golang: golang.org/x/net/html: Cross-Site Scripting via HTML parsing bypass crypto/x509: golang: Go crypto/x509: Denial of Service via inefficient certificate chain validation net: golang: Go net package: Denial of Service via long CNAME response in LookupCNAME golang.org/x/net/idna: golang: net/http: golang.org/x/net/idna: Privilege escalation via incorrect Punycode label processing axios: Axios: Invisible JSON Response Tampering via Prototype Pollution Gadget 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…

Security update for python-GitPython

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:25.10: python-git, Ubuntu:Pro:26.04:LTS: python-git

GitPython is a python library used to interact with Git repositories. Prior to version 3.1.49, GitConfigParser.set_value() passes values to Python's configparser without validating for newlines. GitPython'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.

Ein Angreifer kann mehrere Schwachstellen in Splunk SOAR ausnutzen, um Sicherheitsvorkehrungen zu umgehen, um Informationen offenzulegen, um Dateien zu manipulieren, um einen SQL-Injection Angriff durchzuführen, um einen Cross-Site Scripting Angriff durchzuführen, und um beliebigen Programmcode auszuführen.