Mar 18, 2016 - Jacob Vosmaer, Marin Jankovski  

What Git vulnerabilities CVE-2016-2324 and 2315 mean for GitLab and you

A few days ago two security vulnerabilities in Git were made public. In response, we released GitLab 8.5.7 the same day.

At the time, there was still some confusion regarding which version of Git contained all of the security fixes. Yesterday, Git version 2.7.4 was released with the fixes for all known vulnerabilities.

Due to the potential impact of this vulnerability, we've released new omnibus-gitlab packages for the past four months' releases (8.2, 8.3, 8.4, and 8.5).

In this blog post we will go into more detail about the vulnerabilities and their impact on GitLab.

The problem

An attacker can create a malicious Git repository that causes a heap overflow in git commands that run on that repository (e.g., git clone At best this causes your git command to crash; at worst the malicious Git repository effectively becomes a program that runs on your computer.

This vulnerability got fixed in Git version 2.7.4.

General impact

If you are using a vulnerable version of the Git client and you run the "right" git command on a malicious repository, an attacker may gain control over your computer. It also means that if an attacker can upload a malicious repository to a GitLab server, and if that GitLab server has a vulnerable version of Git installed, then the attacker could execute arbitrary code on the GitLab server.

Impact on GitLab

During various operations GitLab will run git commands on the repositories it hosts. If your GitLab server uses a vulnerable version of Git and if one of your users pushed or imported a malicious repository onto your server then attacker code embedded in the malicious Git repository may be executed on the GitLab server as the application user.

What we are doing about it

We have released the new omnibus-gitlab packages for versions going back to GitLab version 8.2.

The Omnibus packages for GitLab 8.2.4, 8.3.5, 8.4.6 and 8.5.8 contain Git version 2.7.4.

We understand it's not always possible for all of our users to upgrade to the latest monthly releases. However, we urge you to upgrade to the latest available version as it contains the latest security fixes for all bundled software.

What you should do about it

You should make sure that you are using the latest version of Git on each computer you use Git. Because there are many different ways to install Git it is difficult to give specific instructions how to this.

If you are an administrator for a GitLab server and you installed GitLab using our Omnibus packages then you should make sure you are using GitLab 8.5.8 or newer.

If you installed GitLab from source or through some other means it is not enough to update to the latest version of GitLab; you should make sure you are using the latest version of Git for your platform.

If you installed Git from source according to the GitLab installation guide you can check its version by running:

/usr/local/bin/git --version

You should also verify that GitLab is seeing the correct version of Git by visiting your Administration dashboard and looking under Components.

For the latest and most detailed news follow @gitlab on Twitter. Future blog posts suggestions RSS

Install GitLab in 2 minutes

With Ubuntu, Debian, CentOS, openSUSE, and Raspbian packages or from source

Install GitLab Now

Try GitLab Enterprise Edition risk-free for 30 days.

No credit card required. Have questions? Contact us.