Dulwich CVE-2026-52726

The victim must perform a recursive submodule operation against an attacker-controlled repository - specifically a call to dulwich.porcelain.clone(..., recurse_submodules=True) or a direct call to dulwich.porcelain.submodule_update - using dulwich version 0.23.2 through 1.2.4. The malicious upstream must ship a .gitmodules whose submodule path resolves inside the parent repository's .git directory (the description gives '.git/hooks' as the canonical case) plus a matching gitlink tree containing an executable matching a real hook name. Code execution is not instantaneous: it triggers only when a subsequent git or dulwich command invokes the planted hook, so a follow-on operation (status, checkout, commit) on the cloned tree is required. Limiting factors: the victim must opt into recursive submodules (default in some wrappers, opt-in in others), and the attack does not affect users who clone via the native git binary because git's own fixes for CVE-2024-32002/32004 already block this path.

The NVD CVSS vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H (7.5) materially understates real-world risk: the description explicitly states arbitrary code execution, which implies C:H/I:H/A:H, and exploitation realistically requires the victim to clone an attacker-controlled repository (UI:R) - so both the impact metrics and the UI metric in the published vector appear inconsistent with the described behaviour. There is no EPSS, KEV, or SSVC data in the provided intelligence, and no public PoC is referenced beyond the credited reporter (tonghuaroot), so this should be treated as no public exploit identified at time of analysis. Despite the scoring oddity, the bug class is well-trodden (direct port of Git's 2024 submodule RCE chain) and any pipeline that performs recursive clones of untrusted repositories - CI runners, package mirrors, code-search indexers - should treat this as a high priority.

An attacker publishes a malicious repository (e.g. on a public forge, or as a transitive dependency referenced by a legitimate-looking project) whose .gitmodules declares a submodule with path '.git/hooks' and whose tree contains an executable named 'post-checkout' or 'pre-commit'. When a CI job, developer, or automated indexer invokes dulwich.porcelain.clone(url, recurse_submodules=True), the submodule's contents are written into the cloned repo's .git/hooks/ directory with executable bits intact, and the very next dulwich or git operation against that working copy fires the hook, executing the attacker's payload as the user running the tooling.