Git Submodule Vulnerability Announced
Security vulnerability in Git v2.19.0 and older
![](https://github.blog/wp-content/uploads/2019/09/security-1200-630.png?resize=1200%2C630)
The Git project has disclosed CVE-2018-17456, a vulnerability in Git that can cause arbitrary code to be executed when a user clones a malicious repository. Git v2.19.1 has been released with a fix, along with backports in v2.14.5, v2.15.3, v2.16.5, v2.17.2, and v2.18.1. We encourage all users to update their clients to protect themselves.
Until you’ve updated, you can protect yourself by avoiding submodules from untrusted repositories. This includes commands such as git clone --recurse-submodules
and git submodule update
.
Affected products
GitHub Desktop
GitHub Desktop versions 1.4.1 and older included an embedded version of Git that was affected by this vulnerability. We encourage all GitHub Desktop users to update to the newest version (1.4.2 and 1.4.3-beta0) available today in the Desktop app.
Atom
Atom included the same embedded Git and was also affected. Releases 1.31.2 and 1.32.0-beta3 include the patch.
Ensure you’re on the latest Atom release by completing any of the following:
- Windows: From the toolbar, click Help -> Check for Updates
- MacOS: From the menu bar, click Atom -> Check for Update
- Linux: Update manually by downloading the latest release from atom.io
Git on the command line and other clients
In order to be protected from the vulnerability, you must update your command-line version of Git, and any other application that may include an embedded version of Git, as they are independent of each other.
Additional notes
Neither GitHub.com nor GitHub Enterprise are directly affected by the vulnerability. However, as with previously discovered vulnerabilities, GitHub.com will detect malicious repositories, and will reject pushes or API requests attempting to create them. Versions of GitHub Enterprise with this detection will ship on October 9.
Details of the vulnerability
This vulnerability is very similar to CVE-2017-1000117, as both are option-injection attacks related to submodules. In the earlier attack, a malicious repository would ship a .gitmodules
file pointing one of its submodules to a remote repository with an SSH host starting with a dash (-
). The ssh
program—spawned by Git—would then interpret that as an option. This attack works in a similar way, except that the option-injection is against the child git clone
itself.
The problem was reported on September 23 by @joernchen, both to Git’s private security list, as well as to GitHub’s Bug Bounty program. Developers at GitHub worked with the Git community to develop a fix.
The basic fix was clear from the report. However, due to to the similarity to CVE-2017-1000117, we also audited all of the .gitmodules
values and implemented stricter checks as appropriate. These checks should prevent a similar vulnerability in another code path. We also implemented detection of potentially malicious submodules as part of Git’s object quality checks (which was made much easier by the infrastructure added during the last submodule-related vulnerability).
The coordinated disclosure date of October 5 was selected by Git developers to allow packagers to prepare for the release. This also provided hosting sites (with custom implementations) ample time to detect and block the attack before it became public. Members of the Git community checked the JGit and libgit2 implementations. Those are not affected by the vulnerability because they clone submodules via function calls rather than separate commands.
We were also able to use the time to scan all repositories on GitHub for evidence of the attack being used in the wild. We’re happy to report that no instances were found (and now, with our detection, none can be added).
Please update your copy of Git soon, and happy cloning!
Tags:
Written by
Related posts
![](https://github.blog/wp-content/uploads/2025/02/sponsors-3.png?resize=400%2C212)
Support the open source projects you love this Valentine’s Day
Show your appreciation to the open source projects you love. You can help provide much-needed support to the critical but often underfunded projects that keep your infrastructure running smoothly. And remember—every day is a perfect day to support open source! 💖
![](https://github.blog/wp-content/uploads/2024/04/1200.630-Community-wLogo.png?resize=400%2C212)
5 tips for promoting your open source project
Three open source experts offer their advice on sharing open source projects with the world.
![](https://github.blog/wp-content/uploads/2024/04/1200x630-Productivity-Unfurl-LIGHT-Logo@2x.png?resize=400%2C212)
4 steps to building a natural language search tool
Empowering humanitarian action with open source: A natural language search tool for UN Resolutions.