In September 2023, a severe security issue (CVE-2023-4532) was discovered in GitLab, the popular DevOps platform. This vulnerability allowed unauthorized users to link CI/CD jobs from private projects—even if they weren’t a member of those projects. In other words, sensitive build jobs that were supposed to stay private could unintentionally be connected in public pipelines, leaking information and relationships.

Let’s break it down with simple, clear explanations, some code examples, and pointers to original resources.

All versions starting from 16.4 before 16.4.1

This means, if you were running any release in these version ranges, your private project's CI/CD job artifacts could accidentally be linked into pipelines by folks who aren’t supposed to see them.

### What Is a CI/CD Job Link?

GitLab CI/CD jobs are automated tasks—like building, testing, or deploying code. When you set up dependencies or triggers between different jobs or pipelines, you might end up needing to reference them by their project and job ID. Normally, only authorized users should ever know about or use these links.

How Did the Exploit Work?

The vulnerability allowed users to force a relationship to a job in a private project. For instance, when using a needs: dependency in their .gitlab-ci.yml, an attacker could specify the job ID of a private project and the pipeline would accept it.

Code Snippet: Example of the Vulnerable Reference

Suppose there is a private project called secret-app, and it has a CI/CD job called private_build.

The attacker creates or edits their own public .gitlab-ci.yml

stages:
  - build

build_nonce:
  stage: build
  script:
    - echo "I'm building something evil"

include_private_job:
  stage: build
  needs: 
    - project: secret-group/secret-app
      job: private_build
      pipeline: latest
  script:
    - echo "Linked to private build job from another project!"

Even though the attacker is not a member of secret-app, the pipeline tries to resolve the needs: dependency and, in the process, might leak job metadata like job names, existence, pipeline numbers, or even partial logs depending on the exact version and privacy configuration.

Find the Private Project's Name or Path

This could be guessed based on naming conventions (secret-group/secret-app) or discovered through previous leaks.

Guess or Obtain Job Name

Many shops use CI/CD job names like build, deploy, test. An attacker can try common names.

Run Pipeline and Observe Results

If the pipeline is accepted and doesn’t return errors about permissions, the attacker can infer the existence of the job, see logs, or in some versions, get more details.

GitLab Security Advisory:

https://about.gitlab.com/releases/2023/10/23/security-release-gitlab-16-3-5-released/

CVE Page:

https://nvd.nist.gov/vuln/detail/CVE-2023-4532

.gitlab-ci.yml Documentation:

https://docs.gitlab.com/ee/ci/yaml/

16.4.1

The patch ensures that jobs in private projects cannot be referenced by users who aren’t *at least* project members.

Takeaways

- Private means private? Not always! Sometimes configuration oversights or vulnerabilities can expose what you think is hidden.
- Keep up on updates: Security fixes aren’t just about flashy hacks. Small issues like CI/CD job leaks can give attackers a map to the rest of your infrastructure.

Don't reuse job names mindlessly: Unique naming and proper access controls matter.

By understanding CVE-2023-4532, you can better secure your GitLab use from both simple and serious privacy breaches.

*Always check your perms—and your pipelines!*

*This exclusive writeup breaks down the key details and practical risks of CVE-2023-4532 in GitLab. Don’t forget to follow the references and update your systems today!*

Timeline

Published on: 09/29/2023 07:15:00 UTC
Last modified on: 10/03/2023 19:28:00 UTC