GitLab is one of the most widely used platforms for code hosting, CI/CD pipelines, and team collaboration. Security in such systems is critical, especially when it comes to secrets like access tokens. Recently, a new vulnerability has come to light under the ID CVE-2025-0194. This flaw affects multiple recent versions of GitLab Community Edition (CE) and Enterprise Edition (EE). In this post, we’ll break down the vulnerability, show a scenario of exploitation, include some code snippets demonstrating the issue and how it might be detected, and share references for further reading.

What is CVE-2025-0194?

CVE-2025-0194 details a sensitive data exposure flaw in GitLab. In certain conditions, access tokens might be written to application logs when specific API requests are made.

Security Impact

If log files (often world-readable or accessible by many admins and support personnel) contain access tokens, a malicious insider or anyone with log access could grab those tokens and use them to access or manipulate code/data in GitLab.

Let’s walk through what actually happens

1. A user/application makes a specially-crafted API request to GitLab, supplying their personal/protected access token as an authentication header or parameter.
2. Given certain conditions, GitLab’s backend logs the full request, including the token value, into log files such as production.log.
3. The token, now sitting unprotected in the log, could later be found and abused by someone with log access.

> Note: The token is not leaked to other users, but is written to the backend server log files. This is especially dangerous in companies where logs are aggregated and not always handled securely.

Let’s see how a log entry could end up

# Example log line in production.log
{
  "timestamp": "2024-06-15T12:00:15Z",
  "method": "POST",
  "path": "/api/v4/projects/1/issues",
  "headers": {
    "Authorization": "Bearer glpat-XXXXXXXXXXXXXXXXXX"
  },
  "params": {
    "title": "Bug report",
    "description": "Critical bug found!"
  }
}

Here, the "Authorization" header is not sanitized before being written to the log file. Anyone reviewing logs could find glpat-XXXXXXXXXXXXXXXXXX (a real token) and use it.

Here’s a simple *curl* command that mimics an API request

curl -X POST "https://gitlab.example.com/api/v4/projects/1/issues"; \
  --header "Authorization: Bearer glpat-XXXXXXXXXXXXXXXXXX" \
  --data "title=Security+issue&description=Simulated+API+request"

If you have log access, you can grep for your token in the logs

grep 'glpat-' /var/log/gitlab/gitlab-rails/production.log

If you see lines containing real tokens, you're affected.

Example Exploit Code (Python)

import requests

leaked_token = "glpat-XXXXXXXXXXXXXXXXXX"
gitlab_url = "https://gitlab.example.com/api/v4/user";

headers = {"Authorization": f"Bearer {leaked_token}"}
resp = requests.get(gitlab_url, headers=headers)

if resp.status_code == 200:
    print("Token is valid! User info:")
    print(resp.json())
else:
    print("Token not valid.")

References & More Reading

- GitLab Advisory - CVE-2025-0194
- CVE Details Page - CVE-2025-0194
- HackerOne Report (if released) *(search for “GitLab token leakage”)*

Summary

CVE-2025-0194 is a classic example of how secret leakage into logs can cause critical damage even if your application interfaces are strong. If you manage a GitLab instance, you must upgrade now and rotate any suspect tokens. Review your log handling policy and make sure you’re not leaking sensitive data.

Timeline

Published on: 01/08/2025 20:15:29 UTC
Last modified on: 01/09/2025 07:15:27 UTC