gitoxide CVE-2026-40034

Exploitation requires (1) the victim to use a tool built on gitoxide's gix or gix-submodule crate at a vulnerable version (>= 0.31.0, < 0.83.0); (2) the targeted submodule must have been previously initialized so that 'submodule.<name>.url' exists in .git/config (i.e., 'git submodule init' or equivalent has run at least once); (3) the attacker must control the .gitmodules content delivered in a subsequent fetch/update - typically via a malicious or compromised remote repository; and (4) the victim must subsequently invoke Submodule::update() (passive user interaction per CVSS UI:P). It does NOT trigger on a fresh clone before initialization, does NOT affect canonical git (which rejects the invalid update value with 'fatal: invalid value for submodule.sub.update'), and does NOT require authentication on the victim system; the CVSS AV:L indicates the malicious payload is processed locally even though it is delivered remotely.

The CVSS 4.0 vector (AV:L/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H) scores 8.5 and reflects local attack vector with passive user interaction and high impact on confidentiality, integrity, and availability - which matches the realistic threat model: a victim runs a gitoxide-based tool against a malicious repository. SSVC reports Exploitation=PoC, Automatable=No, Technical Impact=Total, aligning with the published proof-of-concept from VulnCheck and the GitHub Security Advisory. EPSS is very low (0.02%, 5th percentile) and the CVE is not on CISA KEV, indicating no observed mass exploitation; this is consistent with the targeted nature (must induce a victim to clone/update a crafted repo using a gitoxide-based client). The CVSS AV:L is worth scrutinizing - exploitation requires a local gitoxide operation against attacker-controlled .gitmodules content, so 'local' is accurate but the delivery channel is remote (malicious repo hosting), which defenders should consider when prioritizing.

An attacker publishes (or compromises) a public Git repository containing a benign initial state, induces a victim to clone and initialize submodules using a gitoxide-based tool, then later pushes an updated .gitmodules adding 'update = !arbitrary_shell_command' for the already-initialized submodule. When the victim next invokes Submodule::update() (for example via a CI job, mirroring tool, or wrapper CLI built on gix), the guard incorrectly passes and the attacker's shell command executes with the victim's privileges. A working proof-of-concept demonstrating Ok(Some(Update::Command("touch /tmp/pwned"))) is referenced in the GHSA writeup.