CVE-2026-78676: GitPython config parser multi-line value injection in write

CVE-2026-78676 · Severity: critical · CVSS 9.8 · Published 2026-08-25

GitPython's configuration file parser incorrectly re-serializes multi-line git config values when writing back to disk, converting legitimately-encoded dormant values into active configuration directives. An attacker can pre-position a malicious value in a repository's git config file (or via the standard git include mechanism) that becomes a live `core.hooksPath` directive after any unrelated GitPython write operation, leading to arbitrary code execution when git invokes hooks during commit, checkout, or other operations.

Technologies: Gitpython Project Gitpython, gitpython (PyPI). Vendors: Gitpython Project, PyPI.

Quick answers

Is CVE-2026-78676 exploited in the wild?
No. Junglewise Threat Intelligence has no report of CVE-2026-78676 being exploited in the wild.
How severe is CVE-2026-78676?
Critical severity, with a CVSS score of 9.8, published 25 August 2026.
Which products and versions are affected?
gitpython (PyPI) ECOSYSTEM:introduced=0,fixed=3.1.59.
Is there a fix for CVE-2026-78676?
Yes. gitpython (PyPI): upgrade to 3.1.59 or later. Junglewise finds every place you run it, drafts the upgrade and applies it once you approve.
How is CVE-2026-78676 attacked?
It is attacked over the network or with local access, in a software library.
Am I affected by CVE-2026-78676?
Check whether you run Gitpython Project Gitpython or gitpython (PyPI) at an affected version. Junglewise does that check for you around the clock: connect your code, cloud and domains, and it matches new vulnerabilities like this one against what you actually run and tells you when one reaches you.

How to fix

  • gitpython (PyPI): upgrade to 3.1.59 or later
    pip install "gitpython>=3.1.59"

Technical details

The vulnerability is a read-then-corrupt-on-rewrite defect in git/config.py's GitConfigParser class. When reading config files, GitConfigParser._read() correctly decodes standard git multi-line syntax (backslash-continuation with escaped newlines) via string_decode() (line 460), converting escape sequences like `\n` into real embedded newlines in memory—this is legitimate and mirrors git's own behavior. However, when flushing the parser via _write()/write_section() (lines 694–712), the code uses the unsafe _value_to_string() path (not _value_to_string_safe()) and "handles" embedded newlines with a bare `.replace("\n", "\n\t")`, emitting an unquoted real newline followed by a tab. Real git does not recognize indentation-only continuation; a value only continues across lines if the prior line ends in a literal backslash. Thus, when GitPython re-serializes a multi-line value this way, the second "line" becomes an independent config entry on re-parse. If that dormant value contains `<anything>\nhooksPath = <attacker-path>`, it becomes a live core.hooksPath directive after one write, executing arbitrary hooks. The root cause is asymmetric: earlier fixes (c417af46, PR #2176) added UNSAFE_CONFIG_CHARS_RE guards to all setter-argument entry points but explicitly did not address values already resident in _sections via _read(). Exploitation requires only an attacker-influenced config file plus one ordinary config write—no unsafe caller argument is needed. Attack vector is network/local depending on how the config file is obtained; preconditions include read-write access to the parser and a dormant payload in the file.

Affected products

  • GitPython Developers GitPython <= 3.1.58

Identifiers

  • CVE-2026-78676
  • GHSA-284h-m62q-gf8w
  • PYSEC-2026-3786

Timeline

  • 2026-08-10: disclosed
  • 2026-09-08: advisory
  • 2026-09-08: kev added

References

This page as Markdown. Free to reuse under CC BY 4.0 with a link back.