GitPython CVE-2026-76219

The vulnerable application must invoke at least one of three specific GitPython methods - IndexFile.from_tree, IndexFile.reset, or IndexFile.merge_tree - and must forward attacker-controlled input as the treeish positional argument (first argument to from_tree or merge_tree, or the commit keyword argument to reset). The CVSS 4.0 PR:L metric confirms that some form of low-privilege access or authentication to the application is required to supply that input; unauthenticated exploitation (PR:N) is not reflected in the provided vector. The target file path must be writable by the OS user account running the host process - files owned by root or other users are not reachable unless the process runs with elevated privileges. No special git configuration, repository state, or non-default GitPython settings are required; the vulnerability is present in default usage of the three methods. The impact is bounded to overwriting file content with DIRC-format git-index data; arbitrary byte injection into the written file is not possible, ruling out direct code execution via file content manipulation. Applications that never pass user-controlled strings to these three methods are not exploitable regardless of GitPython version.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:H) scores 7.2 and indicates network-reachable exploitation requiring only low privileges with no attack complexity or additional preconditions. Real-world exploitability is conditional on an application-layer requirement: the vulnerable code path is only reachable when an application passes attacker-influenced data as the treeish argument to one of the three named methods - a non-trivial precondition that limits exposure to code hosting platforms, CI/CD pipelines, or web tools that accept user-supplied git references and route them through these index operations. The integrity ceiling is bounded: written content is constrained to a valid git-index blob (DIRC magic bytes), not arbitrary attacker-chosen bytes, which rules out direct RCE via content injection; however, destroying or corrupting files such as SSH authorized_keys, cron jobs, application configs, or pip constraints files remains a high-impact outcome. The publicly available proof-of-concept (independently reproduced per the advisory) substantially lowers the exploitation bar. EPSS data was not provided in the available intelligence feed. The combination of a public POC, a simple one-argument injection, and high-value writable-file targets makes this a genuine priority for any Python application that exposes GitPython index operations to external input - but deployments where treeish arguments are always internally generated carry minimal incremental risk.

An attacker authenticated to a code-review or CI web application that accepts a user-supplied branch or commit reference submits the string --index-output=/home/app/.ssh/authorized_keys as the treeish parameter. The application passes this directly to IndexFile.from_tree(repo, user_input); GitPython appends it to the git read-tree argument list without sanitization, and git's last-occurrence-wins behavior causes the injected --index-output to override the library's internal temp path, overwriting authorized_keys with a git-index blob and locking the process owner out of SSH access. A proof-of-concept confirming this exact behavior - before content reading IMPORTANT ORIGINAL CONTENT, after content starting with DIRC bytes - is documented in GHSA-4gmw-gg2m-w46p.