CVE-2026-73623 exposes a gap in GitPython's git clone sanitization: the --template flag was not included in the unsafe_git_clone_options denylist, allowing an attacker to specify a template directory containing malicious hook scripts that execute post-clone. This is not a novel attack vector — it's the latest iteration of a recurring vulnerability class where git flags enable hook injection. The pattern has appeared across multiple git wrapper libraries over the past decade, making this a genetic weakness rather than an unforeseeable omission.
What makes this CVE significant is what it reveals about denylist-based security models. Git exposes dozens of flags with non-obvious behavioral side effects, and maintaining an exhaustive denylist requires maintainers to trace chains of interaction that flags themselves don't advertise. The --template flag isn't dangerous in isolation — it becomes dangerous when combined with git's directory processing logic during clone operations. A code reviewer checking the denylist against git's documentation would need to understand that --template specifies a directory, that directory can contain hook scripts, and that post-checkout hooks execute automatically. That's a multi-step reasoning chain that exceeds what a standard security review can reasonably demand.
The deeper problem is that the denylist encodes threat intelligence without provenance. There's no record of which attack vector each blocked flag was meant to address, no linked security issues, and no audit trail explaining the reasoning. When maintainers change, the institutional knowledge that built the denylist walks out the door with them. The sedimient problem — older git features that predate the denylist were never systematically audited for hook-adjacent behavior — compounds with each release.
For defenders, the practical implication is straightforward: check whether your environment uses GitPython to clone repositories from untrusted sources, and if so, verify that --template is blocked or that cloned repositories are isolated from user-controlled hook directories. However, the more important takeaway is architectural. The denylist model places an impossible burden on maintainers — they must anticipate every flag interaction that could enable hook execution, while attackers need only one gap. This asymmetry doesn't improve with tighter audits; it degrades as git's surface area expands. Libraries wrapping dangerous system calls should consider explicit allowlists or default-deny models, where users must consciously enable potentially dangerous flags rather than relying on the library to block everything dangerous.
The EPSS score of 0.00692 indicates this gap persisted for a meaningful period before disclosure. That duration wasn't a testament to the denylist's completeness — it was luck, the interaction is fiddly enough that attackers didn't find it first, and the security community's attention hadn't mapped this specific flag-to-hook chain in GitPython's context. That luck is not a security posture.