Git vulnerability with submodules

Edward Thomson

The Git community has disclosed a serious security vulnerability in Git that can lead to arbitrary code execution. This has been assigned CVE 2017-1000117.

The Visual Studio Team Services (VSTS) team takes security issues very seriously.  We encourage all users to update their Git clients as soon as possible to address this issue.

  • If you’re using Git for Windows, you can download the latest version from
  • Visual Studio 2017 users should update to version 15.3.26730.8 or better using the update mechanism within Visual Studio. Versions of Visual Studio prior to 2017 are unaffected.
  • Hosted build agents for VSTS have been updated to include a patched version of Git. An updated version 2.120.2 is available for download from VSTS for teams running their own agents.

If you use other Git clients, please contact the vendor to understand whether or not you need to upgrade.

The problem

When fetching from remote repositories, Git URL parsing can be confused by command line options embedded inside the URL. This can be exploited to pass specific command-line options to the ssh executable, and those options may specify a command to execute using its “ProxyCommand” functionality.

For example, if you run:

git clone ssh://-oProxyCommand=notepad.exe/ /tmp/git_vulnerability

Then Notepad will open. (Substitute notepad.exe with an application of your choice if you’re not a Windows user.)

Of course, since this URL looks quite funny, it’s unlikely that somebody would be convinced to clone that themselves. The larger risk, instead, comes when this URL is embedded as a submodule in a rather innocent-looking repository.

An attacker can easily change the URL of a submodule in a repository by editing the .gitmodules file. If it were changed to point to the exploit URL above:

[submodule "pwned"] path = pwned url = ssh://-oProxyCommand=notepad.exe/

Then doing a recursive clone on this innocent-looking repository would cause arbitrary code execution.


The solution to this problem is quite simple and effective: submodule URLs are now examined more closely by Git clients. If the SSH hostname looks like a command-line option (i.e., if it begins with a “-“) then the submodule is blocked. The updated Git clients referenced above contain this fix and should be installed as soon as possible.


Discussion is closed.

Feedback usabilla icon