CVE-2024-9596 - GitLab EE Version Disclosure

A new security vulnerability, CVE-2024-9596, has been discovered in GitLab Enterprise Edition (EE). This issue affects all versions starting from 16.6 up to but not including 17.2.9, from 17.3 up to 17.3.5, and from 17.4 prior to 17.4.2.

In simple terms, this vulnerability allows anyone on the internet (even those not logged in) to find out the exact version number of a GitLab instance. While this might sound minor, version disclosure is frequently the first step for attackers. Knowing the version helps them decide which attacks or exploits to attempt next.

Let’s break down what this bug means, how it can be exploited, and what you can do to protect yourself.

What is Version Disclosure?

Version disclosure means a software product leaks its current version number to outsiders. In many cases, software tries to hide version information. But if someone can find it (like through a web request), attackers can look up public vulnerabilities for that version and strike with targeted exploits.

Impact: Version Disclosure

Official Advisory:
GitLab Security Release: 17.4.2, 17.3.5, and 17.2.9

Step 1: Send an HTTP Request

Attackers can make a simple GET request to the affected GitLab server.

In many cases, the version information is leaked via HTTP headers, or within a visible resource such as a JavaScript or CSS file served by GitLab.

Example using curl

curl -I https://gitlab.example.com/

This command fetches just the headers of the main GitLab page.

Step 2: Look for the Version Number

In vulnerable GitLab EE installs, the response may contain headers such as X-GitLab-Version or a link to an asset like /assets/application-[version].js.

Example vulnerable HTTP response

HTTP/2 200 OK
Content-Type: text/html; charset=utf-8
X-GitLab-Version: 17.3.2-ee
...

Or, in the page source/JavaScript link

<script src="/assets/application-17.3.2ee.js"></script>

The attacker now knows you're running version 17.3.2-ee.

Step 3: Use the Version Information

With the version info in hand, attackers search for public vulnerabilities or exploits targeting that specific release. If you were slow to patch previous critical bugs, you could be at risk of remote code execution, privilege escalation, or other dangerous attacks.

Real-World Demo

curl -I https://your-gitlab-server/

Sample Output

HTTP/2 200
X-GitLab-Version: 17.3.3-ee
Content-Type: text/html; charset=utf-8
...

Or scanning the homepage HTML for assets with the version suffix

curl https://your-gitlab-server/ | grep application-

Sample Output

<script src="/assets/application-17.3.3ee.js"></script>

Why This Matters

Even though version disclosure seems harmless, it's important to realize that most serious attacks START with attackers gathering information. If you keep your version information secret, you make an attacker's job harder.

Mitigation and Patching

Immediate Action:
Update GitLab EE to one of the fixed versions:

17.2.9 or later

Upgrade Instructions:
- Read the official upgrade documentation by GitLab.

References

- GitLab Security Release - 17.4.2, 17.3.5, 17.2.9
- GitLab Upgrade Guide
- CVE record for CVE-2024-9596

Conclusion

CVE-2024-9596 might seem "harmless" at first, but it’s a reminder that even small leaks can be the first domino in a chain of dangerous attacks. If you run GitLab EE, be sure to patch immediately.

If you need help auditing your installation or want to know more about securing self-hosted tools, keep your software up-to-date, and subscribe to security alerts from your key vendors!

Timeline

Published on: 10/10/2024 10:15:08 UTC
Last modified on: 10/10/2024 12:51:56 UTC