CVE-2024-5655 - GitLab Pipeline Impersonation Vulnerability Explained

On June 26, 2024, GitLab released a critical security update addressing CVE-2024-5655. This vulnerability lets attackers trigger a CI/CD pipeline as another user under specific circumstances. The bug affects all GitLab CE/EE versions from 15.8 up to (but not including) 16.11.5, 17. up to 17..3, and 17.1 up to 17.1.1.

Let’s break down what happened, how it happens, and why you really should patch right now. This write-up contains a basic proof of concept, original references, and simple explanations. This is an exclusive deep dive to help everyone understand the impact.

What is CVE-2024-5655?

CVE-2024-5655 allows attackers to make GitLab run pipelines that look like they were triggered by someone else.

Normally, when you push code or trigger a pipeline, GitLab logs it with your user account. Due to a flaw in how GitLab handled pipeline triggers, under certain setups, an attacker could trick the system into running a pipeline as if it were initiated by another user (victim).

This could let the attacker

- Run code with the victim's permissions/credentials.

Make misleading audit logs.

- Potentially exfiltrate secrets/tools intended only for the victim.

17.1 before 17.1.1

Reference:
- Official GitLab Security Release Note
- GitLab CVE Entry

Vulnerability Details

The crux of the bug is improper validation on pipeline triggers via the API.

- When an attacker gains access to a trigger token or project, they can craft an API request to run a pipeline for any commit/branch.

GitLab failed to reliably verify “who” was actually making the request.

- Under the right conditions, such as shared runners or misconfigured triggers, the triggered pipeline gets attributed to a different user.

Step 1: Attacker obtains a trigger URL or token

This could happen if a token is leaked, or a project incorrectly exposes trigger URLs in the source code, CI variables, or documentation.

Step 2: Attacker crafts a pipeline trigger API request

The attacker can POST to the pipeline trigger endpoint using the token, but now pretends to be another user (the victim). This might involve specifying the victim’s details or simply abusing how GitLab connects the request to a user.

Step 3: Impersonation

The pipeline runs, and GitLab shows it as triggered by the victim, not the attacker.

Example Exploit (Proof of Concept)

DISCLAIMER: Do not attempt this on any live GitLab instance without proper authorization.

Suppose you (the attacker) obtained a trigger token

TRIGGER_TOKEN=AbcdEFG123456  # From a leaked .gitlab-ci.yml, for example
VICTIM_PROJECT_ID=123
GITLAB_URL=https://gitlab.example.com

# Craft API call to trigger the pipeline on the victim’s project
curl -X POST \
  -F token=$TRIGGER_TOKEN \
  -F ref=main \
  "$GITLAB_URL/api/v4/projects/$VICTIM_PROJECT_ID/trigger/pipeline"

Potential sign of this exploit:
The pipeline appears in GitLab’s UI and log as if *another user* (the victim) triggered it, even though the attacker did.

What’s the risk?

- Leaked secrets, because jobs run with another user’s context/access.

False audit trails: GitLab logs will NOT show the real attacker.

- Escalation of privilege if the victim user has higher permissions or access to sensitive runners and scripts.

Official Patch

The only real fix is to upgrade GitLab as soon as possible to 16.11.5, 17..3, or 17.1.1 (or any later version).

Look for pipelines “triggered by” users who should NOT be running those particular jobs.

2. Review trigger token usage in project settings ➔ CI/CD ➔ Pipeline triggers.

Conclusion

CVE-2024-5655 is a critical security issue. If you use GitLab, patch now. If you can’t patch, at least rotate all trigger tokens and audit your logs for strange pipeline triggers.

For those running CI/CD production workloads, take this as a wake-up call: review your token management, and never expose pipeline triggers publicly.

Timeline

Published on: 06/27/2024 00:15:12 UTC
Last modified on: 06/28/2024 13:16:40 UTC