GitPython CVE-2026-110855

Requires the victim to clone an attacker-supplied repository AND invoke submodule handling (clone plus submodule_update) using GitPython before 3.2.0; the attacker must control the repository's .gitmodules to supply a submodule name containing shell/environment-variable syntax. Impact is realized only when sensitive data is present in the process environment variables that get expanded, and the leaked values land in .git/modules directory names and DEBUG-level logs - so verbose/DEBUG logging or exposure of the working directory increases disclosure. Limiting factors: user interaction is mandatory (UI:P - no server-side or unauthenticated-remote trigger), the operation must involve submodules, and the GitPython version must be below 3.2.0; integrity and availability are unaffected.

This is a moderate-severity information disclosure flaw (CVSS 4.0 base 7.1) whose real-world risk is tempered by a required user action. The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:N/VA:N) indicates a network-reachable, low-complexity, unauthenticated attack with high confidentiality impact but no integrity or availability impact - consistent with CWE-200 and the description of secrets leaking into .git/modules directory names and DEBUG logs. The decisive limiter is UI:P (passive user interaction): exploitation requires a victim to clone and run submodule_update against an attacker-controlled repository, so this is not a server-side, drive-by, or self-propagating condition. No EPSS score, CISA KEV listing, POC reference, or SSVC decision data was provided in the input, so there is no signal of active or probable exploitation; the risk rests on vendor/NVD analysis alone. Net assessment: a legitimate supply-chain/CI hardening priority for environments that automatically clone untrusted repositories (e.g., CI runners, package importers), but not an emergency-patch, mass-exploitation scenario. Note: VC:H (high confidentiality) depends on sensitive data actually existing in the attacker-influenceable environment variables - environments with no secrets in env vars see far lower practical impact than the base score implies.

An attacker publishes a malicious git repository whose .gitmodules defines a submodule name containing environment-variable syntax (e.g. referencing a secret env var). When a victim - such as a CI pipeline or developer tool - clones the repo and runs submodule_update with a vulnerable GitPython (before 3.2.0), separate_git_dir in Repo._clone() expands that variable, writing the secret value into .git/modules directory names and DEBUG log output where the attacker or log aggregators can recover it. No public exploit code was referenced in the provided data, and exploitation requires the victim to perform the clone and submodule operation.