If you’re responsible for securing GitLab, this story’s for you. In mid-2023, a severe vulnerability—CVE-2023-3993—was found in GitLab Enterprise Edition (EE). This bug made it possible for sensitive access tokens to be accidentally written to logs. This article explains what happened, how the bug works, how to check if you’re exposed, and what you should do now.

What is CVE-2023-3993? (In Plain English)

CVE-2023-3993 affects GitLab EE versions:

16.2 up to 16.2.2

The vulnerability was found in a backend endpoint where, under some circumstances, *access tokens* sent in request queries would be stored in GitLab’s internal logs. This could lead to developers’, admins’, or automation bots’ access tokens being leaked to anyone with access to those log files.

How Did This Vulnerability Work?

Many services log incoming requests for debugging. But some endpoints in GitLab, when supplied an access token as part of the query string, would log the full query—token included! Anyone able to read these logs could copy/paste the token and impersonate the user or take other actions.

Here’s a simple flow

1. A user or automation sends a request, e.g. to /api/v4/projects?access_token=TOKEN-HERE.

Example Exploit Scenario

Suppose an admin pulls server logs for troubleshooting and accidentally shares them. Or, a malicious insider combs through the log files specifically hunting for "access_token=" strings.

Log Snippet Example

2023-08-16T14:03:22.123Z GET "/api/v4/projects?access_token=glpat-fake_token_for_demo" 200

If the wrong person gets this file, the access token can be used to steal data or take over accounts.

Is This Easy to Exploit?

If you have access to GitLab’s logs, yes, it’s trivial. Unlike a remote code execution or SQL injection, the hard part is simply getting into the logs. The rest is just search and find.

Minimal Proof-of-Concept

Let’s say someone has shell access to the server. Here’s a Bash one-liner to hunt for exposed tokens:

grep -oP 'access_token=\K\S+' /var/log/gitlab/*.log

This will output any string that appears after access_token= in each log entry—possibly revealing live or historical tokens.

What If I’ve Been Exposed?

If your installations are in the affected version range, assume you may have been exposed.

16.2.2+

(Official Security Release Notes)

Relevant Patch Snippet

*(Pseudo-code for clarity)*

# Before
logger.info "Request params: #{params}"

# After (with filter)
sanitized_params = params.except(:access_token)
logger.info "Request params: #{sanitized_params}"

Is There a Public Exploit?

No automated exploit tools, but you don’t need one. Anyone with log file access can extract tokens with basic tools like grep, awk, or even Notepad.

References & Further Reading

- GitLab Security Release Blog (Aug 2023)
- Mitre CVE Database Entry
- GitLab Issue Tracker
- NIST NVD Details


## TL;DR / Final Words

CVE-2023-3993 is dangerously simple: if your GitLab logs were accessible, your access tokens might have leaked. Don’t delay—patch, audit, and rotate tokens where needed. Keep application logs free of secrets and review logging code in all critical paths.

Stay safe! 🚨

If you have questions or want a script to help you scan your logs, just reply below.

Timeline

Published on: 08/02/2023 01:15:00 UTC
Last modified on: 08/04/2023 19:23:00 UTC