In June 2024, a serious security vulnerability was identified in GitLab Community Edition (CE) and Enterprise Edition (EE). Known as CVE-2024-7554, this flaw affects a wide range of GitLab versions and puts API access tokens at risk of being exposed in log files.

from 17.2 before 17.2.2

your instance might be vulnerable and your secrets could be at risk.

This post will explain the vulnerability, show you a practical code example, and provide official references for patching. If you manage GitLab, read on and update ASAP.

In Simple Terms

CVE-2024-7554 is a vulnerability where GitLab’s API access tokens could end up in server logs under certain conditions. Tokens are sensitive. If exposed, they could let attackers access or control your GitLab projects, potentially leading to source code leaks, deployment compromise, or even full takeover of your continuous integration system.

Scope

- Affects: ALL deployments of GitLab CE/EE fitting the version ranges above.
- Exposure: When API requests are made in a specific way, the full access token might be written to log files.
- Impact: Any admin, developer, or even third party with log access could retrieve these tokens and escalate their privileges.

Let’s simplify how this could actually occur

1. Making an API Request: A user (or script) makes an API call to the GitLab server using a personal access token.
2. Improper Logging: If the API call is structured in a certain way, the access token used could be recorded in the server’s log files.
3. Accessing the Logs: Anyone with access to these logs can now extract the token and use it to impersonate the user.

Suppose you have an automation script that interacts with the GitLab API.

import requests

# DO NOT use tokens in URLs for GET/POST requests
GITLAB_URL = "https://gitlab.example.com/api/v4/projects";
TOKEN = "glpat-TokenExample123456"

# Vulnerable way (for illustration only): Token in query parameters
params = {'private_token': TOKEN}  # <-- This is where trouble starts!

response = requests.get(GITLAB_URL, params=params)

print(response.json())

Why is this a problem?

When the token is included as a query parameter (like ?private_token=...), the full URL (with your token) may be written to the server’s log files!

Typical log line

[info] GET /api/v4/projects?private_token=glpat-TokenExample123456 HTTP/1.1

Any admin or log reader who can access the logs can steal your token.

Use the Authorization header, so the token doesn’t appear in logs

headers = {'PRIVATE-TOKEN': TOKEN}
response = requests.get(GITLAB_URL, headers=headers)

This way, only the word PRIVATE-TOKEN appears in logs, not the actual token value.

Attacker uses the exposed token to impersonate the user or escalate privileges.

This is why it’s so dangerous. Even if your API token is strong, it’s worthless if it's exposed in plain text in your logs.

Upgrade to 17..6, 17.1.4, or 17.2.2 (or any newer versions).

- Official Release Post
- GitLab Issue Tracker (Internal, requires login)

Audit Your Logs:

- Check your logs (production_json.log, access.log, etc.) for any private_token or similar patterns.

References

- GitLab 17.2.2 Security Release Notes (Official)
- CVE-2024-7554 at CVE.org
- GitLab Issue 427225 (Requires login)

Final Thoughts

CVE-2024-7554 is a clear reminder that “where you put your tokens matters.” Always use headers, keep your GitLab up to date, and audit your logs for secrets.

If you’re responsible for security or DevOps at your organization, take immediate action—your source code and pipelines could be exposed right now.

Timeline

Published on: 08/08/2024 11:15:13 UTC
Last modified on: 08/08/2024 13:04:18 UTC