Git Remote Code Execution via Malicious .gitmodules Submo...

CVE-2018-11235 is a critical remote code execution vulnerability in Git that turned an everyday developer action — cloning a repository with submodules — into a potential system compromise. By crafting a malicious .gitmodules file with a specially constructed submodule name, an attacker could trick Git into writing a hostile post-checkout hook outside its intended directory and then silently executing it the moment a victim ran git clone --recurse-submodules or git submodule update --init. No further interaction was required beyond the clone itself, making this one of the more alarming source control vulnerabilities disclosed in 2018.

What Is CVE-2018-11235?

Git submodules let a repository reference other Git repositories at a fixed commit, with the mapping between submodule names, paths, and URLs stored in a tracked .gitmodules file. Under the hood, Git stores each submodule's own .git metadata inside $GIT_DIR/modules/<name>, where <name> is taken directly from the .gitmodules file.

CVE-2018-11235 existed because Git did not adequately sanitize that submodule name before using it to build a filesystem path. A malicious repository owner could set a submodule name containing directory traversal sequences (../), causing Git to write the submodule's internal Git directory outside the expected modules/ folder — for example, directly into the working tree's own .git directory. By carefully ordering multiple submodules alphabetically, an attacker could arrange for a crafted hooks/post-checkout script to survive the checkout process undisturbed. As soon as Git finished checking out the malicious submodule, it executed that hook automatically, running arbitrary attacker-controlled code on the victim's machine with the victim's own privileges.

This is a textbook example of how a seemingly narrow parsing flaw in Git internals can escalate into full remote code execution: the victim only needed to clone a repository — a routine, trusted action for any engineer pulling code from a project — and the compromise happened without any prompt or warning. Because so much of modern software supply chain security assumes that git clone is a safe, inert operation, CVE-2018-11235 was a wake-up call about how much implicit trust flows through Git tooling itself, not just the code it retrieves.

Affected Versions and Components

CVE-2018-11235 affects the core Git client across a wide span of release lines:

• Git before 2.13.7
• Git 2.14.x before 2.14.4
• Git 2.15.x before 2.15.2
• Git 2.16.x before 2.16.4
• Git 2.17.x before 2.17.1

Because the flaw lived in Git's own submodule-handling logic, it affected any tool or workflow that shells out to the Git client to recursively clone or update submodules — including command-line usage, CI/CD pipelines, IDE integrations, and package managers that vendor dependencies via Git submodules. It was disclosed alongside a related issue, CVE-2018-11233, and both were patched in the same round of releases. Downstream Linux distributions and package maintainers, including Red Hat, Debian, and Ubuntu, subsequently shipped their own advisories and backported fixes to older Git packages.

CVSS, EPSS, and KEV Context

CVE-2018-11235 carries a CVSS v3.0 base score of 7.8 (High), with the vector AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H. The "local" attack vector reflects that exploitation ultimately executes code on the victim's own machine (triggered by a local git clone/git submodule update operation) rather than over the network directly, but the impact is severe: full compromise of confidentiality, integrity, and availability, achieved with low complexity once a victim is lured into cloning a hostile repository. Under the older CVSS v2.0 scale, it was scored 6.8 (Medium).

As of this writing, CVE-2018-11235 does not appear on CISA's Known Exploited Vulnerabilities (KEV) catalog, and no widely cited EPSS score should be treated as authoritative given how long ago the flaw was patched and how quickly major Git hosting providers rolled out server-side mitigations. That said, the severity and simplicity of the exploit — a single malicious .gitmodules file — meant it received urgent, coordinated remediation across the Git ecosystem rather than a quiet patch cycle.

Timeline

• Early May 2018 — Security researcher Etienne Stalmans discovered the vulnerability while researching Git submodule behavior and reported it to GitHub's security team via its bug bounty program.
• Within hours of disclosure — GitHub's security team reproduced, triaged, and deployed temporary server-side mitigations to block malicious .gitmodules payloads from being pushed to GitHub-hosted repositories while an upstream fix was developed.
• May 29, 2018 — The Git project shipped coordinated patch releases (v2.13.7, v2.14.4, v2.15.2, v2.16.4, and v2.17.1) closing the vulnerability at the client level.
• May 30, 2018 — CVE-2018-11235 was published in the National Vulnerability Database alongside the related CVE-2018-11233.
• Following weeks — Linux distributions and enterprise vendors (Red Hat, Debian, Ubuntu, Microsoft's Visual Studio Team Services) issued their own advisories and backported patches, and major Git hosting platforms rolled out permanent server-side validation to reject repositories containing malicious submodule names.

Remediation Steps

Organizations still running affected Git versions, or auditing historical exposure, should take the following steps:

1. Upgrade Git immediately to 2.13.7, 2.14.4, 2.15.2, 2.16.4, 2.17.1, or later. Any current, actively maintained Git release already contains this fix, but legacy build agents, container base images, and developer workstations frequently lag behind and deserve a targeted audit.
2. Enable transfer.fsckObjects on self-hosted Git servers. The patch introduced server-side object validation that allows Git servers to reject pushes containing malformed or malicious .gitmodules content before it ever reaches a client.
3. Avoid --recurse-submodules on untrusted repositories. Treat recursive submodule operations against unfamiliar or third-party repositories with the same caution you'd apply to executing an unknown script, and prefer inspecting .gitmodules contents before a recursive clone when a repository's provenance is uncertain.
4. Audit CI/CD pipelines and build images. Automated pipelines that clone dependencies with submodules are a high-value target precisely because they run unattended with elevated permissions; confirm every runner and container image pins a patched Git version.
5. Verify hosting platform protections. If you self-host Git (e.g., via Gitea, Bitbucket Server, or a custom Git daemon), confirm the underlying Git version and any server-side hooks reject the directory-traversal patterns associated with this CVE.

How Safeguard Helps

CVE-2018-11235 is a reminder that source control tooling itself is part of the software supply chain attack surface — not just the packages and dependencies a codebase pulls in. Safeguard is built around that reality. Our platform continuously inventories the Git clients, CI runners, and build infrastructure across your environment, flagging outdated or vulnerable Git versions — including legacy releases still exposed to CVE-2018-11235 — before an attacker can weaponize a crafted .gitmodules file against your pipelines.

Beyond version tracking, Safeguard evaluates the repositories your teams actually clone and vendor, surfacing suspicious submodule configurations, unexpected hook definitions, and anomalous URL patterns that mirror historical Git remote code execution techniques. For organizations managing sprawling CI/CD estates where recursive submodule checkouts are routine, Safeguard's supply chain monitoring provides the visibility needed to catch a stale Git binary or a malicious submodule reference long before it triggers arbitrary code execution on a build server or developer laptop.

Vulnerabilities like CVE-2018-11235 rarely announce themselves — they hide in the plumbing of tools every engineering team trusts implicitly. Safeguard's mission is to make that implicit trust verifiable, giving security and platform teams continuous assurance that the Git infrastructure underpinning their software supply chain is patched, monitored, and free of the kind of quiet path-traversal flaws that turned a routine git clone into remote code execution.