GitLab has always been one of the major players in managing code, collaborating on projects, and hosting private repositories. But even the best platforms sometimes have issues, and in early 2024, security researchers found a serious problem affecting GitLab's Enterprise Edition (EE): CVE-2024-10240. If you run a GitLab instance, or just want to know how security holes arise and get fixed, you're in the right place.
Let’s break down what this vulnerability is, who’s affected, how an attacker could exploit it, and how to patch it.
1. What is CVE-2024-10240?
This vulnerability affects Merge Requests (MRs) in private projects on GitLab EE. Under specific circumstances, an *unauthenticated user* (a stranger on the internet, no login required) could sneak a look at certain information about a Merge Request (MR) you thought was private.
> Affected GitLab EE Versions:
> - From 17.3 up to (but not including) 17.3.7
> - From 17.4 up to (but not including) 17.4.4
> - From 17.5 up to (but not including) 17.5.2
If you’re running any of these, you’re at risk.
2. How Bad Is It?
If you’re running teams on GitLab, you probably use *private repositories* for things you don’t want outsiders to see — anything from work-in-progress code, to secret features, to hotfixes for critical vulnerabilities.
CVE-2024-10240 means that parts of information (metadata) about Merge Requests in those private repos could be leaked, even to users who are *not* signed in. Depending on the setup, this might reveal:
Possibly the author or branches involved
This doesn’t mean the whole MR (like all the code changes) is public, but even a little bit of leaked info can be useful to attackers. For example:
3. How Does the Exploit Work?
Let’s look at a simplified attack. (Note: we’re just showing how a researcher might prove the issue for awareness. Don’t attack real systems you don’t own.)
Suppose you know or can guess the URL of a merge request in a private project, such as
https://gitlab.example.com/mygroup/my-private-project/-/merge_requests/10
Normally, if you’re not a member, trying to visit this would just show a 404 Not Found, or “You don’t have access”. But, due to this bug, in certain circumstances a request to the MR endpoint would *return some JSON data* about the merge request instead of hiding everything.
Example Exploit (Python requests)
import requests
mr_url = "https://gitlab.example.com/mygroup/my-private-project/-/merge_requests/10.json"
# No authentication at all
response = requests.get(mr_url)
if response.status_code == 200:
print("[+] Merge Request Data:", response.json())
else:
print("[-] Can't access MR or it’s already patched.")
MR title
- Source/target branch names
4. Why Did This Happen?
On a technical level, the permissions check in some MR-related controllers failed to block unauthenticated API or JSON requests for private Merge Requests. That means if someone ever figured out the ID of an MR, they might just get details they weren’t supposed to see.
The exact cause is rooted in how API endpoints and user permissions are verified — a subtle but classic kind of web security bug.
5. What Should You Do?
Check your GitLab version!
GitLab provides upgrade instructions
- GitLab upgrade documentation
- GitLab blog post on the critical patch
Regularly updating your GitLab instance, as well as checking release notes for security fixes, is key.
## 6. References / Further Reading
Original Advisory:
GitLab Security Release: critical security fix for CVE-2024-10240
NVD Entry for CVE-2024-10240:
GitLab Upgrade Guide:
7. Conclusion
CVE-2024-10240 is a great reminder that *metadata leaks* can be just as dangerous as direct code or credential leaks. If your organization relies on GitLab for private work, make sure you patch *early and often*, and always assume that public endpoints might leak data if permissions checks are missed — because sometimes, they do.
If you have questions about upgrading, or you think you might have been affected, reach out to GitLab support or your own security team right away.
Timeline
Published on: 11/26/2024 20:15:24 UTC