A recent vulnerability, CVE-2024-4278, has been discovered in GitLab Enterprise Edition (EE) that allows project maintainers to retrieve sensitive Dependency Proxy credentials. This bug affects a wide swath of GitLab EE installs and could expose your organization to internal package registry leaks.

Let’s break down what happened, how this flaw works, show an example of how to reproduce it, and help you secure your instance.

What Is CVE-2024-4278?

CVE-2024-4278 is an information disclosure vulnerability affecting the Dependency Proxy feature in GitLab EE. Maintainers—users expected to have limited privilege—could obtain the Dependency Proxy password by simply editing a certain setting, allowing them to potentially access internal container registries or caches.

GitLab EE 17.4 _before_ 17.4.1

If your GitLab EE instance matches (or is older than) any versions in these ranges, you are vulnerable.

How Does The Exploit Work?

The Dependency Proxy allows users to cache and fetch Docker (OCI) images. Credentials for this proxy are usually sensitive and only top-level admins should see them.

However, a bug in how settings were handled made the password field visible to project maintainers. By navigating to the correct admin UI for the Dependency Proxy and making changes (e.g., toggling a setting or submitting an update), the maintainer could see the auto-generated password in clear text.

Exploitation Walkthrough

Below is a simplified step-by-step of what an attacker (a project maintainer, intentionally or accidentally) could do:

Edit the Dependency Proxy settings.

4. In the form (if in a vulnerable version), the hidden password field would be revealed after saving or toggling settings.

# Pseudo code for the vulnerable process

if user.role == "maintainer":
    show_dependency_proxy_settings()
    # BUG: Password is shown in plain text in the settings form
    print("Dependency Proxy Password: ", dependency_proxy.password)

This password could then be copied and used elsewhere to directly access and pull cached container images, or even shared outside the company—potentially leaking sensitive code or binaries.

Technical Example: Simulating the Disclosure

Below is a (hypothetical) example using Python and the GitLab API to view settings—*in reality, the exploit is through the web UI, but this reflects the broken access control logic*:

import requests

BASE_URL = "https://your-gitlab-instance/api/v4";
TOKEN = "your_maintainer_access_token"
PROJECT_ID = 123

# Attempt to fetch dependency proxy settings
r = requests.get(
    f"{BASE_URL}/projects/{PROJECT_ID}/dependency_proxy/settings",
    headers={"PRIVATE-TOKEN": TOKEN}
)

if r.status_code == 200 and 'password' in r.json():
    print("Leaked password:", r.json()['password'])
else:
    print("Access denied or password is protected.")

On secure (patched) GitLab versions, this endpoint would redact or refuse to display the password to maintainers.

For 17.4.x, upgrade to 17.4.1 or later.

You can find official upgrade docs here:
👉 GitLab Update Docs

Auditing:
If you suspect exposure, rotate your Dependency Proxy credentials and audit the project’s access logs for suspicious usage.

References

- GitLab Security Release: 17.4.1, 17.3.4, and 17.2.8
- Official CVE Notice - CVE-2024-4278
- GitLab Dependency Proxy Docs

Closing

CVE-2024-4278 is a classic example of privilege creep: where maintainers had accidental access to secrets they shouldn’t. If you’re running GitLab EE in production, check your versions, upgrade, and keep your proxy credentials safe.

Timeline

Published on: 09/26/2024 07:15:02 UTC
Last modified on: 09/26/2024 17:26:34 UTC