CVE-2022-4365 - How GitLab Maintainers Could Leak Sentry Tokens (And What This Means For Your Data Security)

GitLab is a widely used platform for version control and DevOps, trusted by countless teams to build and ship code collaboratively. But like any powerful software, it’s not immune to security bugs. One such critical vulnerability—CVE-2022-4365—put sensitive project secrets at risk until it was patched in late 2022. In this post, we break down what happened, how the bug could be exploited, and what developers need to know to stay secure.

What is CVE-2022-4365?

CVE-2022-4365 is a vulnerability in GitLab Community Edition (CE) and Enterprise Edition (EE) that allowed project Maintainers to steal Sentry error tracking tokens. Sentry tokens are secret credentials used to integrate GitLab with Sentry, a popular error monitoring service.

All versions from 15.7 before 15.7.2

If you were running GitLab in one of these ranges, you were potentially vulnerable.

How Did the Bug Work?

Sentry supports integration with GitLab, making it easier to track errors from your projects. To set up this integration, you provide GitLab with your Sentry DSN (a kind of *token* or secret URL), and it uses this to report errors to your Sentry account.

Normally, only highly-trusted users can see or interact with these secrets. But in vulnerable versions of GitLab, there was a loophole: Maintainers (who are users with broad powers within a project, but not *all* powers) could change the Sentry integration's destination URL—tricking GitLab into sending the secret token to an attacker-controlled location.

Save the new settings.

5. The system sends the configured Sentry token (which it thinks is safe) to the new URL, where the attacker can snatch it.

This is basically a case of trusting users with changes they shouldn’t be able to make to sensitive secrets.

This stripped-down pseudo-code shows what went wrong

# Pseudo-code of the old vulnerable code
class SentryIntegrationSettings:
    def save(self, new_url):
        self.url = new_url
        # When saving, send a test event to the new URL using the secret token
        send_sentry_event(self.url, self.sentry_token)

def send_sentry_event(url, token):
    # May send the token as part of a sentry DSN or in the request header
    requests.post(url, headers={"Authorization": f"Bearer {token}"})

A malicious Maintainer could set url to anything, causing the token to be sent wherever they want.

What Could Attackers Do With The Stolen Token?

Sentry tokens allow access to error reports and sometimes sensitive logs from your running applications. With this token, an attacker could:

Sometimes, depending on your Sentry setup, escalate attacks if logs include PII or credentials.

While the attack is limited to Maintainers (not just any project user), it’s still a serious privilege escalation because not all Maintainers should be trusted with production secrets.

When Was It Fixed?

GitLab patched this issue in the following releases, which you should upgrade to *immediately* if you haven’t:

You can find GitLab’s advisory here

- GitLab Security Release: 15.7.2, 15.6.4, and 15.5.7

See the CVE details on NIST’s page as well.

Upgrade GitLab: Always use the latest patch releases, especially for major server software.

- Audit Maintainer Roles: Treat Maintainer as a trusted role—or reduce it to a safer role if possible.

Audit Integrations: Watch for changes to integrations with Sentry and other services.

- Rotate Sentry Tokens: If you’ve been affected, rotate your Sentry tokens and check for suspicious logs.

Conclusion

Security bugs in integrations are tricky—they often slip under the radar, especially when they seem like simple configuration management. CVE-2022-4365 is a classic example: by trusting maintainers with secret-handling powers, GitLab accidentally let them exfiltrate high-value tokens.

If you’re a GitLab administrator, check your version and upgrade as soon as you’re able. Set strong controls on who gets Maintainer-level access, and keep an eye on your error tracking settings.

For further reading

- Official CVE Entry
- GitLab Response
- GitLab Security Blog

Timeline

Published on: 01/12/2023 04:15:00 UTC
Last modified on: 01/20/2023 19:31:00 UTC