GitLab is one of the most popular platforms for source code management and CI/CD pipelines, used by teams and companies big and small. On May 31, 2024, a newly disclosed vulnerability—tracked as CVE-2024-5318—throws light on how even restricted Guest users can peek at sensitive information in private projects, simply by exploiting GitLab’s job artifact system. This post dives deep into what went wrong, how the exploit works, and how you can secure your own GitLab instance.

The Scope of CVE-2024-5318

Vulnerability Identifier: CVE-2024-5318
Affected Products:

From 17. *prior to* 17..1

Patched: Yes, in 16.10.6, 16.11.3, and 17..1
Discovered: May 2024
GitLab Advisory: GHSA-p92g-436v-hwgr

Understanding the Bug: The Artifact Blindspot

GitLab’s CI/CD system creates “artifacts”—files, logs, or data generated during jobs, often including dependency reports (dependency_list.json). Normally, only authorized users should be able to fetch or view these artifacts for private projects.

The Bug:
Due to a flaw in access checks, a Guest user—who should have very limited rights—can access and view the dependency list artifacts of private projects if they can reach the job artifact URL.

Reveal internal package naming conventions.

In short: attackers or curious users with “Guest” access (often given out for limited audit/observation duties or bug bounty programs) can get sensitive clues about your stack.

The attacker gets (or social engineers) Guest access to a private GitLab project.

- *Typical Guest permissions:* View issues, comments, view some project metadata; should not see CI/CD artifacts.

### 2. Locate Pipeline/Job Artifacts

- The Guest navigates to the project’s CI/CD pipelines.
- Even if detailed pipeline results are restricted, some URLs may be guessable or discoverable, especially if pipeline/job IDs are incremented or referenced elsewhere.

3. Find Dependency List Artifacts

- Most dependency scanning jobs uploaded files named /artifacts/12345/raw/dependency_list.json, where 12345 is the job ID.

- Using their login, the Guest can successfully fetch the artifact

curl -O -H "PRIVATE-TOKEN: <guest_user_token>" \
  "https://gitlab.example.com/<namespace>/<project>/-/jobs/12345/artifacts/raw/dependency_list.json";

- The dependency_list.json file will look like this

[
  {
    "name": "rails",
    "version": "7..7",
    "package_manager": "bundler"
  },
  {
    "name": "nokogiri",
    "version": "1.14.5",
    "package_manager": "bundler"
  }
  // and many more...
]

5. Compile the Full Dependency List

- By fetching all such artifact files across various jobs or even different private projects (if given Guest roles), the attacker gets a full insight into the internal dependencies.

How the Patch Fixes It

After the patch (upgrade!) these endpoints now appropriately check user permissions before granting access to artifacts like dependency lists. Guest users will encounter a 403 Forbidden error.

Restrict Guest Access: Audit projects and ensure Guests are *really* needed.

3. Review Artifact Exposure: Use CI/CD job settings like expire_in and review who can see artifacts:

`

4. Monitor Artifact Downloads: Use GitLab’s Audit Events or logs to watch for suspiciously high artifact downloads.

5. Rotate Sensitive Packages: If you believe dependency names exposed attack surfaces, consider renaming or updating them.

Final Thoughts

CVE-2024-5318 is a perfect example of “minor” access misconfigurations leading to real-world data leaks. If your organization doles out Guest access casually, you may be exposing far more than you think. Update, audit, and restrict—your pipeline safety depends on it.

More References and Reading

- Official GitLab Security Advisory - GHSA-p92g-436v-hwgr
- NVD Entry for CVE-2024-5318
- How to Use Artifacts in GitLab CI/CD

Timeline

Published on: 05/24/2024 13:15:09 UTC
Last modified on: 05/24/2024 18:09:20 UTC