CVE-2024-5067 - GitLab Project Analytics Settings Leak

---

GitLab is the heartbeat for collaboration in the software development world, and with such a central role, security bugs can be disastrous. CVE-2024-5067 is the latest in the line of issues affecting GitLab EE (Enterprise Edition), specifically threatening to leak sensitive project analytics settings through the Document Object Model (DOM) to more users than intended. In this post, I break down this vulnerability, who is affected, the risk, and even share how a real-world exploit works—all in clear language, with working code samples.

GitLab EE 17.2 before 17.2.1

The vulnerability lies in the way GitLab exposes project-level analytics settings in the webpage DOM. These settings—which may include URLs, configuration toggles, and potentially sensitive business metrics—could be viewed by group members with Developer or higher roles, even when only should be accessible to Maintainers or Owners.

Why Should You Care?

Project analytics can contain business secrets, such as custom metric sources, tracking configurations, and third-party integration keys. If these are visible to more users than intended, there’s a potential for both data leaks and abuse.

Technical Details: How the Leak Happens

When a group member with Developer or higher access visits the “Project Analytics” page, the client-side JavaScript could populate the DOM with configuration data. Due to this bug, more information ends up in the page’s source than should.

GitLab EE backend provides APIs only meant for certain roles.

2. The frontend fetches analytics settings via XHR/fetch requests.

The response is used to update the DOM with hidden <input> fields or JS objects.

4. Due to missed role checks, a Developer can view these fields in browser Inspect/Dev Tools.

Below is an example of a DOM snippet that a Developer could find via their browser tools

<!-- analytics-settings is visible to Developer, could include secrets -->
<div id="analytics-settings" data-api-url="/api/v4/projects/123/analytics" data-custom-key="SECRET-123-KEY" style="display: none;"></div>

// Example: Page JS is populating window object with sensitive data
window.protectedAnalyticsSettings = {
  analytics_api_url: "/api/v4/projects/123/analytics",
  custom_metrics_key: "SECRET-123-KEY"
};
// This is now accessible to all JS on the page, regardless of user's role.

This information shouldn’t be exposed to group members at the Developer level.

Visit a project’s analytics page.

2. Open Developer Tools in Chrome/Firefox.
3. Search for “SECRET” or “analytics” in HTML/JS global variables.

Run the following in the browser console

console.log(window.protectedAnalyticsSettings);

Output

{
  "analytics_api_url": "/api/v4/projects/123/analytics",
  "custom_metrics_key": "SECRET-123-KEY"
}

*This highlights how easy it is to find the exposed configuration.*

You are affected if

- Your company uses GitLab EE versions 16.11 and above, but hasn’t updated to at least 17..5, 17.1.3, or 17.2.1.
- You use project analytics and have Developer-level (or higher) members who shouldn’t see certain settings.

References

- Official GitLab Security Release Post
- GitLab Advisory page for CVE-2024-5067

After upgrading, double-check by

- Logging in as a Developer and inspecting the analytics page for any sensitive configs in the DOM or window objects.

Conclusion

CVE-2024-5067 is a classic example of a “insecure data exposure” bug. While this doesn’t let attackers run arbitrary code or delete data, it does let more users see things that should be off-limits. For organizations using project analytics to manage critical business data, this could be a serious issue. Patching is straightforward, and the fix is available—don’t wait!

TL;DR

- GitLab EE < 17..5/17.1.3/17.2.1 leaks project analytics settings in DOM, visible to group Developers.

Check your pages for sensitive config leaks using browser Dev Tools.

Stay safe, and always double-check who can see what in your critical project dashboards!

*Original research and writing by an expert on secure DevOps practices.*

Timeline

Published on: 07/24/2024 23:15:09 UTC
Last modified on: 07/26/2024 15:33:01 UTC