Sensitive Information Disclosure via resource_group API Despite Repository and CI/CD Features Being Disabled

⚠️ Please read the process on how to fix security issues before starting to work on the issue. Vulnerabilities must be fixed in a security mirror.

HackerOne report #3223993 by iamgk808 on 2025-06-26, assigned to @katwu:

Report | Attachments | How To Reproduce

Report

Summary

A Developer-level user is able to access CI/CD resource group Details via the GitLab API, even when:

  • Once the Repository option is disabled in a project, no one can view the project’s code, branches, merge requests, or CI/CD configuration details.
  • As a result, the .gitlab-ci.yml file is not accessible because it resides within the repository itself.

This leads to information disclosure, as resource_group names often contain sensitive identifiers such as:

  • Internal environment names (prod, uat, internal-staging)
  • Branch names (release-2025, fix-critical-bug)
  • Client/project identifiers (client-bankofamerica, huawei-deploy)
  • Infrastructure or host names (db-replica-1, aws-ap-south-1)

image.png

Despite the repository and CI/CD being turned off, these names remain visible via the API and can be retrieved by users with Developer-level access, who normally shouldn't have access to CI/CD internals in this configuration.

Steps to reproduce

Two users - victim, attacker

Victim steps:

  1. Create a new public group called group-1 & apply GitLab Ultimate trial to it
  2. In the group, create a private project called project-1
  3. In project-1, create a .gitlab-ci.yml file with the below content, a pipeline will run
deploy_prod:  
  stage: deploy  
  script: echo "Deploying"  
  resource_group: $CI_COMMIT_REF_NAME

deploy_client:  
  stage: deploy  
  script: echo "Deploying"  
  resource_group: client-bankofamerica

image.png
image.png

  1. Then go to project-1 settings > project permissions & turn off the Repository option & save it
    image.png
  2. Now go to the project-1 >members section & invite the attacker user with the Developer role
    image.png

Attacker steps:

  1. go to project-1 & note the project id

image.png

  1. In this URL, change the 70445683 - with your project ID

https://gitlab.com/api/v4/projects/70445683/resource_groups

  1. The attacker can see the resource group details like id, key names, process mode, created & updated dates

<redacted>

Impact
  • Information Disclosure: Internal naming patterns, such as branch names, environment names, project structures, client identifiers, and deployment targets, are exposed.
  • Bypassing Intentional Restrictions: The GitLab UI clearly disables Repository and CI/CD features, implying that all CI/CD-related metadata should be hidden, yet this API allows leakage of part of the CI/CD configuration.
Examples
What is the current bug behavior?

Sensitive Information Disclosure via resource_group API Despite Repository and CI/CD Features Being Disabled

What is the expected correct behavior?

When Repository and CI/CD features are disabled:
The resource_group API should be inaccessible

Relevant logs and/or screenshots
Output of checks

This bug happens on GitLab.com

Results of GitLab environment info

Impact

  • Information Disclosure: Internal naming patterns, such as branch names, environment names, project structures, client identifiers, and deployment targets, are exposed.
  • Bypassing Intentional Restrictions: The GitLab UI clearly disables Repository and CI/CD features, implying that all CI/CD-related metadata should be hidden, yet this API allows leakage of part of the CI/CD configuration.

Attachments

Warning: Attachments received through HackerOne, please exercise caution!

How To Reproduce

Please add reproducibility information to this section:

Edited by ADandy