A serious security vulnerability, CVE-2024-6678, has been discovered in GitLab Community Edition (CE) and Enterprise Edition (EE). This issue affects multiple GitLab versions, letting attackers trigger CI/CD pipelines *as if they were any user they choose*. This vulnerability can result in unauthorized actions, data leakage, and even privilege escalation.

17.3 up to (but not including) 17.3.2

Let's break down the CVE, see how it works, and talk about what you can do about it.

The vulnerability

At its core, CVE-2024-6678 is an improper authorization flaw. Under "certain circumstances," an attacker can use GitLab’s web interface or API to start a CI/CD pipeline as another user.

Bypass security controls and audit trails

GitLab's official advisory:
GitLab Security Release: 17.3.2, 17.2.5, and 17.1.7 — Critical security fixes

You are affected if you are running any of these versions

- GitLab CE/EE 8.14 and all versions before 17.1.7

Run this in your GitLab server shell

gitlab-rake gitlab:env:info

Look for the GitLab version number in the output. If it matches any of the above, you must update.

How does the exploit work?

When a user triggers a pipeline in GitLab, the pipeline usually runs with the privileges and context of that user. However, due to a logic error in certain GitLab versions, an attacker can supply arbitrarily crafted requests to impersonate any user in a project.

The attacker identifies a user with high privileges in a project (like a Maintainer or Owner).

2. By carefully crafting a web or API request, the attacker includes that user's ID or username in the pipeline trigger.
3. The vulnerable GitLab instance fails to verify if the actual requester matches the user being impersonated.

The pipeline initiates as if the targeted user had started it.

5. If the pipeline has access to sensitive secrets, environments, or deploy keys reserved for that user, the attacker now has access.

Example Code Snippet – Simulating the Exploit (for Education Only!)

Below is a simplified proof of concept using GitLab's REST API and curl. This assumes the attacker already has API access (for example, by obtaining a project access token or an access token for a less privileged user).

Note: This is for educational purposes. *Do not use this on systems you do not own!*

# Attacker sets the user_id to a privileged user in the trigger API call

curl -X POST "https://gitlab.example.com/api/v4/projects/<project_id>/trigger/pipeline"; \
-H "Content-Type: application/json" \
-H "PRIVATE-TOKEN: <attacker_personal_access_token>" \
-d '{
  "ref": "main",
  "variables": [{"key": "CI_USER_ID", "value": "<target_user_id>"}]
}'

The trick

- In some versions, a carefully forged POST request can force the pipeline to run as <target_user_id>.
- If the pipeline is configured to use secrets, protected variables, or environments limited to certain users, this could give the attacker much greater power than intended.

#### *Real-world attacks could be more sophisticated and may exploit more complex branch or trigger setups.*

How to mitigate and patch

Successful exploitation requires a vulnerable version. The official fix is to *upgrade* your GitLab instance.

Upgrade now!

- CE/EE 17.1.7
- CE/EE 17.2.5
- CE/EE 17.3.2

Consider rotating exposed secrets and tokens.

GitLab's Patch & Advisory:
- GitLab Release and Patch Notice
- CVE Record at NVD

Conclusion

CVE-2024-6678 is a critical escalation flaw affecting GitLab installations across the globe.
Pipelines, when misused, give attackers "hands-on-the-keyboard" access to your CI/CD world. Left unpatched, this flaw lets them assume your identity, steal secrets, and possibly harm your codebase and infrastructure.

If you run GitLab, patch now. Monitor your pipeline logs, review secrets, and follow updates from GitLab’s advisory page.

Security is everybody's responsibility. Stay vigilant!

References & Further Reading

- GitLab's Official Security Release for CVE-2024-6678
- CVE-2024-6678 at NVD
- GitLab Security Blog
- How to upgrade GitLab


*Keep your production safe: patch, audit, and review your security practices regularly!*

Timeline

Published on: 09/12/2024 19:15:04 UTC
Last modified on: 09/12/2024 21:34:55 UTC