CVE-2017-1000117 is a client-side vulnerability in Git that allows a malicious repository to achieve remote code execution on the machine of anyone who clones it — no phishing, no macro, no attachment required. The flaw sits in how Git's transport layer parses ssh:// URLs before handing the hostname to the system ssh command. By crafting a hostname that begins with a dash, an attacker can smuggle command-line options — most dangerously -oProxyCommand — straight into the ssh invocation, turning a routine git clone or submodule fetch into arbitrary command execution. Because the trigger can be hidden inside a .gitmodules file, a developer can be compromised simply by cloning a repository that references a booby-trapped submodule, with no indication anything unusual has happened.
This is a textbook example of why source code management tooling itself belongs on the software supply chain threat model. Git is the substrate that every CI/CD pipeline, build server, and developer workstation trusts implicitly; a bug in how it handles untrusted input from a repository is, by definition, a bug that untrusted repositories can exploit.
What Is CVE-2017-1000117?
Git supports several transport protocols for fetching a repository, including ssh://. When a user runs git clone ssh://host/path (or Git resolves a submodule URL in that scheme), Git extracts the host portion of the URL and passes it to the local ssh binary as an argument, effectively building a command line like ssh host git-upload-pack '/path'. Prior to the fix, Git did not validate that the extracted host string was actually a hostname rather than something that looked like a command-line flag.
An attacker who controls the URL — for example ssh://-oProxyCommand=touch${IFS}/tmp/pwned/x — could cause ssh to interpret the leading -o as an option rather than a target host. The ProxyCommand option lets ssh run an arbitrary shell command to establish the connection, so the attacker's payload executes on the victim's machine the moment Git invokes ssh under the hood. This is a form of argument injection that escalates directly into command injection, a class of bug security researchers had already been probing across other tools that build shell command lines from attacker-supplied URLs.
The most dangerous delivery mechanism was not a user manually typing a hostile URL — it was Git's own submodule handling. A malicious .gitmodules file can declare a submodule whose URL uses this crafted ssh:// scheme. A victim who clones the parent repository with --recurse-submodules, or who later runs git submodule update --init, would have Git resolve and connect to that URL automatically, triggering code execution without ever seeing or approving the malicious hostname directly.
Affected Versions and Components
The vulnerability lives in Git's core transport/connect logic (the code responsible for parsing remote URLs and invoking the SSH client), which means every distribution of Git, on every operating system, that included the unpatched URL-parsing behavior was affected — this was not limited to a single hosting provider or GUI client, since it lived in the underlying git binary itself.
The Git project addressed the flaw by releasing patched point versions across every actively maintained release line at the time: 2.7.6, 2.8.6, 2.9.5, 2.10.4, 2.11.3, 2.12.4, 2.13.6, and 2.14.3, alongside a fix in the 2.15.0 release candidate. The fix adds validation that rejects hostnames beginning with a dash before they are ever handed to ssh, closing off the injection path for both direct clones and submodule-driven fetches. Any Git installation older than these patched releases — including the git binaries baked into CI runner images, build containers, and developer toolchains — should be considered vulnerable until upgraded.
Severity: CVSS, EPSS, and KEV Context
NVD scores CVE-2017-1000117 as High severity, with a CVSS v3 base score of 7.8, reflecting that successful exploitation compromises confidentiality, integrity, and availability with low attack complexity, though it does require user interaction (the victim initiating a clone or submodule update against attacker-controlled content). Exploitation is local in the sense that the payload runs via the victim's own ssh process, but the trigger is entirely attacker-controlled from a remote, untrusted repository.
The vulnerability has not been observed on CISA's Known Exploited Vulnerabilities (KEV) catalog, and available exploitation-probability signals for this CVE remain low — consistent with a client-side, interaction-required bug from 2017 that was patched quickly and broadly across Linux distributions rather than exploited at scale in the wild. That said, low observed exploitation does not mean low relevance: unpatched Git binaries have a long tail in build images, legacy CI agents, and cached container layers, and this class of bug — trusting attacker-supplied strings inside a shell-adjacent command line — remains a recurring pattern worth defending against structurally, not just patching reactively.
Disclosure Timeline
- Discovery and report: The issue was identified and reported by security researcher Joern Schneeweisz of Recurity Labs, as part of a wider look at how version control and URL-handling tools construct SSH command lines from user-supplied input.
- Coordinated fix development: Git maintainers, including longtime core contributor Jeff King, developed a fix that validates hostnames extracted from
ssh://URLs before passing them to the system SSH client. - Public disclosure and release: The Git project publicly disclosed the vulnerability and shipped patched releases across its maintenance branches in early October 2017, alongside the 2.15.0 release candidate, so that essentially every supported Git version received a fix simultaneously rather than only the newest release.
- Downstream propagation: Linux distributions and package maintainers (Debian, Ubuntu, Red Hat, and others) followed with updated
gitpackages in the days after, and CI/CD platforms and hosted Git services updated the Git binaries in their build images.
Remediation Steps
- Upgrade Git immediately to 2.14.3, 2.15.0, or later — or to the corresponding patched point release on any older maintenance branch (2.7.6 through 2.13.6). Run
git --versionto confirm the installed version is at or above the fixed line for your branch. - Audit CI/CD build images and runners, not just developer laptops. Because this bug triggers during
git clone --recurse-submodulesandgit submodule update, vulnerable Git binaries embedded in container images or ephemeral build agents are just as exploitable as a developer's local checkout — arguably more so, since CI jobs routinely clone third-party and dependency repositories automatically. - Treat submodule URLs as untrusted input. Until systems are confirmed patched, avoid recursive clones of unfamiliar repositories, and inspect
.gitmodulescontents before initializing submodules from sources you don't control. - Rebuild and redeploy affected container images rather than relying on host-level patching alone — cached base images with an old
gitpackage will silently reintroduce the exposure into new builds. - Verify the fix, don't just assume it. Confirming the exact Git version across every host, image, and pipeline stage is the only way to close the gap; version drift between environments is exactly how vulnerabilities like this linger for years after a patch exists.
How Safeguard Helps
CVE-2017-1000117 is a reminder that source code management infrastructure — the Git binaries, the clone operations, the submodule graph — is part of your software supply chain attack surface, not just a background utility. Safeguard is built to give organizations visibility into exactly this kind of risk before it turns into an incident.
Safeguard continuously inventories the toolchain components running across developer workstations, CI/CD runners, and build containers, so a vulnerable Git version isn't something you discover only after an incident review — it shows up as a tracked, prioritized finding tied to the specific CVE, the specific host, and the specific pipeline stage where it lives. Rather than relying on point-in-time audits, Safeguard maps known vulnerabilities like CVE-2017-1000117 against your actual runtime and build environments, correlating CVSS and exploitability context so teams can prioritize the systems where an unpatched Git binary sits closest to untrusted input, such as CI jobs that clone third-party dependencies and submodules automatically.
Because this vulnerability's most dangerous path runs through automated submodule resolution rather than a human typing a malicious command, Safeguard's supply chain monitoring also focuses on the parts of the pipeline that execute without a human in the loop — flagging build steps that recursively clone external repositories, surfacing drift when a container image reintroduces a patched-then-reverted dependency, and giving security teams a single place to confirm that a fix like the Git 2.14.3 patch has actually propagated everywhere it needs to, not just on the machines someone remembered to check.
For teams evaluating their exposure to CVE-2017-1000117 or similar argument/command injection issues in developer tooling, Safeguard provides the continuous, evidence-backed answer to the question that matters most after any CVE disclosure: not "did we read the advisory," but "can we prove every system that needed the fix actually has it."