Security Digest · Vulnerability record
CVE-2026-78676: GitPython: Dormant multi-line git-config values are corrupted into live injected directives (e.g. core.hooksPath) on any unrelated GitConfigParser write, enabling RCE
GitPython before 3.1.59 fails to safely re-serialize multi-line git-config values during write operations, corrupting dormant quoted values into injected directives like core.hooksPath.
CVSS 9.3 Critical EPSS 0.8% · p55
Should you act?
Critical and remotely reachable
No known exploitation yet, but it is network-reachable without credentials. This signal is computed from CISA KEV, EPSS and CVSS data; it is not an editorial verdict.
- No confirmed exploitation. It is not in CISA’s KEV catalog and CISA’s SSVC assessment records no known exploitation. That can change quickly after a public write-up; re-check if you are affected.
- EPSS 0.8%, percentile 55: FIRST’s model estimates a 0.8% chance of exploitation activity in the next 30 days, higher than 55% of all scored CVEs (moderate). EPSS is a probability, not a verdict.
- Remotely reachable with no login and no user interaction. If the vulnerable service is exposed to the internet, prioritize it.
- Only applies if your dependency tree includes
GitPython(PyPI) <= 3.1.58, fixed in 3.1.59. Check your lockfile, including transitive dependencies.
What it is
GitPython before 3.1.59 fails to safely re-serialize multi-line git-config values during write operations, corrupting dormant quoted values into injected directives like core.hooksPath. Attackers can craft config files with embedded newlines that become live git directives after any unrelated GitPython config write, enabling arbitrary code execution via hook invocation.
From the GitHub advisory
- CWE: CWE-88 (Argument Injection) / CWE-94 (Code Injection) — via a read-then-corrupt-on-rewrite config round trip, not a direct setter argument - Affected component: git/config.py — GitConfigParser.read() (multi-line value decoding, lines 444-541, esp. stringdecode() at line 460 and its call sites at 519/541) and GitConfigParser.write()/writesection() (serialization, lines ~694-712, esp. line 708) - Affected version: GitPython at HEAD (9729ed3b948f2bde09f1f188c5311e172212b67e, 2026-08-05, VERSION 3.1.58)
Reachability GitPython added UNSAFECONFIGCHARSRE / valuetostringsafe() / assureconfignamesafe() guards (commits c417af46, 1ed1b924, a495ccd3, and PR #2176) to reject a Python string containing a raw \r/\n/NUL byte, or syntax-bearing characters, when it is passed as an argument to set(), setvalue(), addvalue(), or addsection(). This closed the four config-injection GHSAs above.
That guard is applied only on the write-argument surface. It is never consulted for values that entered GitConfigParser.sections via read() — i.e. values that came from parsing an on-disk config file. And read() legitimately supports standard, spec-compliant git config syntax for multi-line values: a quoted value that is not closed on the same physical line continues onto the next physical line (git's own backslash-continuation syntax), and stringdecode() (.decode('unicodeescape')) decodes a literal two-character \n escape sequence inside such a value into a real embedded LF character in the resulting Python string. No raw control byte is ever written to disk to achieve this — it's the same syntax real git itself uses and accepts.
The bug is in what happens when that GitConfigParser is later flushed: writesection() (line ~694) calls the unsafe self.valuetostring(v) — not valuetostringsafe() — and "handles" any embedded newline in the value with .replace("\n", "\n\t") (line 708), emitting a bare, unquoted in the output file with no re-quoting and no backslash-continuation marker. Real git does not treat an indentation-only continuation the way GitPython's writer assumes — a value only continues across physical lines when the previous line ends in a literal \ immediately before the newline. So the moment writesection()…
Weakness type: CWE-88, CWE-94.
Product: GitPython (PyPI) · Assigned by: VulnCheck · Published: 2026-08-25
Affected and fixed versions
| Ecosystem | Package | Vulnerable | First fixed |
|---|---|---|---|
| PyPI | GitPython | <= 3.1.58 | 3.1.59 |
| Vendor | Product | Affected versions (per CVE record) |
|---|---|---|
| gitpython-developers | GitPython | < 3.1.59 |
Severity scores
| Scored by | CVSS | Score | Vector |
|---|---|---|---|
| VulnCheck | 4.0 | 9.3 Critical | CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N |
| VulnCheck | 3.1 | 9.8 Critical | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H |
| GitHub | 4.0 | 9.3 | CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N |
- Attack vector: network (remotely reachable)
- Attack complexity: low
- Attack requirements: none
- Privileges required: none (no login)
- User interaction: none
CVSS measures how bad a flaw is if exploited, not how likely exploitation is. Read it next to the exploitation data below.
Exploitation and urgency
- CISA KEV: not listed (no confirmed in-the-wild exploitation known to CISA).
- CISA SSVC assessment: exploitation none, automatable yes, technical impact total.
- FIRST EPSS (model of 2026-10-21): 0.78% probability of exploitation activity in the next 30 days; percentile 55.
Timeline
- — CVE record published by VulnCheck
- — GitHub-reviewed advisory GHSA-284h-m62q-gf8w published (critical)
- — CVE record last updated
Sources and references
Original sources first. Version and fix details should always be confirmed against the vendor or project advisory.
Vendor and project advisories, patches
Vulnerability records
- GitHub Advisory GHSA-284h-m62q-gf8w github.com
- CVE.org record CVE-2026-78676 cve.org
- NVD entry CVE-2026-78676 nvd.nist.gov
Other references from the CVE record and advisory
- VulnCheck Advisory: GitPython before 3.1.59 Remote Code Execution via Config Injection vulncheck.com
- github.com github.com