TL;DR:  
A dangerous security flaw—CVE-2022-3793—allowed attackers to read sensitive variables from .gitlab-ci.yml files in GitLab CI/CD pipelines, even if they weren’t supposed to have access. If you used GitLab between version 14.4 and 15.5.2, this vulnerability could impact your projects. This post breaks down what happened, how the exploit works, and what you should do.

What is CVE-2022-3793?

CVE-2022-3793 is an improper authorization vulnerability affecting GitLab CE/EE (Community Edition and Enterprise Edition). Attackers could potentially access CI/CD variables—even those marked secret—in projects where they should have no access.

15.5.2

GitLab official advisory  
NVD - CVE-2022-3793

Where’s the Danger?

.gitlab-ci.yml lets you define variables for CI/CD pipelines. These variables can include API keys, passwords, tokens, credentials, and more—sensitive stuff.

This vulnerability meant that, under certain circumstances, attackers without access to your repository or pipeline could read variables defined directly in the .gitlab-ci.yml file.

They couldn’t access variables set in the GitLab UI ("Project Settings > CI/CD > Variables"), but any variable you wrote directly into the YAML file was up for grabs.

Imagine CompanyA has a private GitLab project with this snippet in their .gitlab-ci.yml

variables:
  API_KEY: "super-secret-key"
  DB_PASS: "strong-password"

build-job:
  script:
    - echo "Running build"

Or abused a public pipeline schedule or API endpoint,

...they could *read* these variables, even if they couldn't see the repository.

3. Concrete Example

By crafting their own pipeline or viewing the pipeline logs or artifacts, an attacker could leak those values.

Example Malicious Job

malicious-job:
  script:
    - echo "Leaked API_KEY: $API_KEY"
    - echo "Leaked DB_PASS: $DB_PASS"

If this was merged (or a job was triggered even as a fork/guest), the logs or job output would show the values:

Leaked API_KEY: super-secret-key
Leaked DB_PASS: strong-password

4. Why Did This Happen?

GitLab’s pipeline system didn’t properly check permissions when jobs were triggered in certain ways or by certain users. That gap let attackers view CI variables in logs or outputs, side-stepping the expected access controls.


## How To Fix / Protect Yourself

1. Upgrade Immediately.

15.5.2

Or any newer version.

Download latest releases: GitLab Releases

2. Never Store Secrets in Code.  
Always store sensitive variables in the GitLab UI not in .gitlab-ci.yml.

3. Review Your Pipelines.  
Check logs and past jobs for leaked secrets. Rotate any credentials stored in CI files.

4. Limit Pipeline Triggers.  
Restrict who can trigger pipelines and review permissions for external collaborators.

References

- GitLab security release post
- National Vulnerability Database (NVD) entry
- GitLab Documentation - Variables
- Best practices for CI/CD secrets

Conclusion

CVE-2022-3793 shows why it’s critical to separate code and secrets, and to stay updated on your software. Always keep up with security advisories, and never trust that a private repo or pipeline fully protects sensitive information if bad configuration or bugs slip in.

Stay safe, keep those secrets secret, and patch your GitLab!

Timeline

Published on: 11/10/2022 00:15:00 UTC
Last modified on: 11/10/2022 20:02:00 UTC