CVE-2024-12292 - Sensitive Information Leakage via GraphQL Logs in GitLab CE/EE (11.–17.6.1)

On March 6, 2024, GitLab disclosed an information disclosure vulnerability (CVE-2024-12292) affecting its Community Edition (CE) and Enterprise Edition (EE). The flaw exists in all GitLab versions from 11. up to—but not including—17.4.6, 17.5.4, and 17.6.2. This post breaks down the issue, demonstrates how it can be exploited in practice, provides code snippets, and shows effective mitigation strategies. Whether you’re a sysadmin, developer, or security enthusiast, understanding this issue is critical.

In Plain English

Whenever someone used GitLab's GraphQL API to perform a “mutation” (like changing a password or updating a secret variable), the sensitive data that was sent to the server could be accidentally written in full to internal logs. This means an attacker with access to those GraphQL logs might find passwords, tokens, or other secrets.

17.6 > 17.6.2 (but not including 17.6.2)

> Reference:
> - GitLab Security Advisory - CVE-2024-12292

How Did the Leak Happen?

GitLab internally logs requests for troubleshooting and performance monitoring. Unfortunately, GraphQL mutations, which carry sensitive user-supplied data, were being stored insecurely with their full input in certain logs.

Suppose an admin automates their CI secrets injection using the API

mutation {
  ciVariableCreate(input: {
    projectPath: "example-group/example-project"
    key: "PRODUCTION_SECRET"
    value: "supersecretpassword123"
  }) {
    variable {
      key
      value
    }
  }
}

Result:
The above value field might end up in the GraphQL logs, potentially readable by GitLab admins, log collectors, or attackers with access to logs.

API tokens

- CI/CD secrets

On any affected GitLab version, run

curl -H "Authorization: Bearer <ACCESS_TOKEN>" \
     -H "Content-Type: application/json" \
     -d '{"query":"mutation { changeUserPassword(input: {userId: \"gid://gitlab/User/8\", password: \"hunter2\" }) { clientMutationId } }"}' \
     https://gitlab.example.com/api/graphql

Step 2: Access the Logs

Suppose you have access to the GitLab server file system.

You can read the GraphQL logs (the actual file path may differ, but typically)

grep "changeUserPassword" /var/log/gitlab/gitlab-rails/production_json.log

Example Output

{
  "method":"POST",
  "path":"/api/graphql",
  "params":{"query":"mutation { changeUserPassword(input: { userId: \"gid://gitlab/User/8\", password: \"hunter2\" }) { clientMutationId } }"},
  ...
}

Bingo! The password hunter2 is visible in the logs.
Anyone with access to these logs—admins, threat actors, or log aggregators—can read the secret!

Why is This a Big Deal?

Many companies forward their GitLab logs to central aggregators or SIEMs (like Splunk or Elastic). If those logs aren't protected as tightly as production secrets, attackers could later review logs long after the actual event and harvest secrets retroactively.

17.6.2 or higher

> Official Security Release:
> GitLab Security Release - 6 March 2024

Consider all those secrets compromised.

- Rotate and regenerate passwords, API tokens, deploy keys, and any other values potentially exposed.

Remove or restrict access to old logs on

- /var/log/gitlab/gitlab-rails/*.log

4. Restrict Log Access

Ensure only the minimum required personnel can access application logs.

Post-patch log example

{
  "method":"POST",
  "path":"/api/graphql",
  "params":{"query":"mutation { changeUserPassword(input: { userId: \"gid://gitlab/User/8\", password: \"[FILTERED]\" }) { clientMutationId } }"},
  ...
}

Conclusion

CVE-2024-12292 is a critical example of why sensitive data should never be directly logged, even during debugging or auditing. If you run GitLab, do not delay: update your server, rotate sensitive secrets, and sanitize old logs. Review your log retention, access, and forwarding policies.

Timeline

Published on: 12/12/2024 12:15:22 UTC

CVE-2024-12292 - Sensitive Information Leakage via GraphQL Logs in GitLab CE/EE (11.–17.6.1) — Details, Exploit, and Mitigation