CVE-2024-8974 - GitLab Information Disclosure – Uncovering Private Project Paths

Published: July 2024
Affected Software: GitLab CE and EE, versions from 15.6 up to (but not including) 17.2.8, 17.3.4, and 17.4.1



GitLab is a go-to platform for source code management, widely used by businesses and open-source enthusiasts. But, from November 2022 through July 2024, a subtle bug CVE-2024-8974 exposed private information: it could leak the filesystem path of private projects to unauthorized users — a classic “information disclosure” scenario.

If you’re managing a self-hosted GitLab instance or using it at work, this post gives you the lowdown on the bug, how it works, its dangers, and what you can do about it.

What is CVE-2024-8974?

Simply put, CVE-2024-8974 is a security issue found in GitLab Enterprise Edition (EE) and Community Edition (CE), in versions spanning 15.6 up to (but not including):

17.4.1

GitLab noted (security advisory):

> "In specific conditions it was possible to disclose to an unauthorized user the path of a private project.”

Here, “path” refers to the unique identifier for a project in the repository — for example: my-group/my-private-project.

Why does it matter?

On the surface, leaking a project path may seem like a minor problem. But in the world of cybersecurity, even small info leaks can help attackers:

Can be used to target specific people, assets, or pipelines for later attacks.

- Sometimes, project paths include internal codes, codenames, or legacy naming patterns that shouldn’t get out.

Combined with other information, this could give attackers the info they need to phish users, try guessing private repo URLs, or enumerate internal organizations’ structures.

How did the leak happen?

GitLab relies on proper access control. But a logic bug in how certain requests were handled meant that unauthorized users could sometimes trigger an error message or endpoint that included the *real* path of a project in the response.

Suppose you hit this (non-working, simplified) API endpoint

GET /api/v4/projects/999999/files/README.md/raw?ref=main

If project 999999 is *private* and you’re not a member, normally you’d get

{
  "message": "404 Project Not Found"
}

But, in vulnerable versions, if you mess up the endpoint in certain ways, you might get a response like:

{
  "error": "Project with path 'acme-corp/secret-project' not found."
}

Here, the real path of the secret project — acme-corp/secret-project — gets disclosed to someone who should not see it.

Likely Trigger

The vulnerable code path was likely in error reporting logic, using unfiltered variables when generating messages:

# Example Ruby (not actual GitLab source)
begin
  project = find_project_by_id(params[:id])
rescue ProjectNotFound
  render json: { error: "Project with path '#{project.path}' not found." }
end

If the project.path isn’t checked for user permissions, it leaks info.

Guess or enumerate project IDs or endpoints using the GitLab API or web interface.

2. Send requests to endpoints (like /api/v4/projects/:id/... or web URLs) referencing *private* project IDs, even if you don’t have access.

Example request with curl

curl -s 'https://gitlab.example.com/api/v4/projects/999999/files/foo.txt/raw?ref=master';

If the returned error includes

{ "error": "Project with path 'internal/top-secret' not found." }

Mitigation

Patch Now:

The only real fix is to upgrade to the latest patched version

- 17.2.8
- 17.3.4
- 17.4.1

Workarounds:

- NVD CVE-2024-8974
- GitLab Security Advisory
- Full list of GitLab releases

Final Thoughts

*CVE-2024-8974* serves as a reminder: even small leaks can snowball in security. While this issue doesn’t let attackers fetch source code or data directly, it lowers the bar for more targeted attacks. As always, update early, update often. If your business relies on private project secrecy or internal codenames, treat this CVE as a real risk.

If you need more technical details, watch for GitLab's coming post-mortems and keep an eye on security news.

*By [Your Name]*

*Exclusive: This content was independently written based on public disclosures and is not copied from any other source.*

Timeline

Published on: 09/26/2024 23:15:03 UTC
Last modified on: 09/30/2024 12:46:20 UTC