In late 2018, a serious vulnerability—CVE-2018-17453—was found in GitLab Community and Enterprise Editions. This bug put some access tokens at risk, potentially allowing attackers to access sensitive user and admin data. It allows an attacker to leak access-token information through the Sentry logging service, all because of an error with the gRPC module in GitLab.

Let’s break down how this happened, see the kind of code impacted, and understand how this problem could be exploited step by step.

Where Did CVE-2018-17453 Happen?

This vulnerability affects GitLab Community Edition (CE) and Enterprise Edition (EE) before these versions:

11.3.x before 11.3.1

GitLab is a widely-used platform for shared code repositories and CI/CD, which makes this flaw extra serious.

The gRPC & Sentry Interaction

GitLab uses Sentry for error logging—basically, if something crashes or goes wrong, the details end up in Sentry so engineers can fix it later.

Meanwhile, parts of GitLab use gRPC (a network protocol) to talk between services, including when authenticating users via tokens.

If an exception (error) was thrown by gRPC, especially the GRPC::Unknown exception, the error detail—complete with sensitive access-token info!—would be sent raw to the Sentry logs.

Why Is This Bad?

Access tokens are like keys to your account—they let users, scripts, and sometimes admins interact with the system. If these tokens are exposed, attackers could:

The Code Path: How Did Tokens Leak?

Whenever a request failed at the gRPC layer, the error would include all the request details. In GitLab’s code, that sometimes meant access tokens in plain text within the thrown exception.

Here is a simplified code sample to demonstrate how this leak could happen

# EXAMPLE: Vulnerable Ruby worker
def authenticate_with_token(token)
  begin
    grpc_client.authenticate(token)
  rescue GRPC::Unknown => e
    # Error! This logs sensitive info into Sentry!
    Raven.capture_exception(e)
  end
end

If the token parameter here was something like 'glpat-abc123' (a real user token), and gRPC failed, then e could include the raw token—and the entire error, including the token, would be uploaded to Sentry.

Here’s what might end up in Sentry

GRPC::Unknown: Authentication failed for token: glpat-abc123
...
backtrace:
...

Exploiting CVE-2018-17453 (Step by Step)

*This section is for educational, responsible security research only!*

Prerequisites

- You must be able to trigger a gRPC authentication error (malformed request, expired/invalid token)

Search for tokens in exception data

Real exploiters would automate this by probing lots of endpoints with random or stolen tokens, then scanning the logs for any valid access tokens to reuse.

How Did GitLab Fix This?

The official fix was to sanitize error reports sent to Sentry, making sure that access tokens (and similar secrets) are never included in logs—even on errors.

See the official GitLab patch discussion:  
- GitLab issue tracker
- GitLab Security Release Post

The fixed code ensures only generic error messages are sent to Sentry, removing all sensitive context:

rescue GRPC::Unknown => e
  clean_message = sanitize(e.message) # removed tokens & secrets
  Raven.capture_exception(clean_message)
end

Recommendations

- Upgrade GitLab: If you’re running an affected version, update to at least 11.3.1 (or newer) ASAP.

- CVE-2018-17453 at NVD
- GitLab Security Advisory – October 2018
- gRPC Ruby documentation
- How to avoid leaking secrets in Sentry

Conclusion

CVE-2018-17453 is a classic example of how logging sensitive errors can leak valuable secrets. If you use GitLab, check your version and always sanitize what goes to external error-reporting tools like Sentry. Regularly review your error logs for any accidental exposures—because sometimes, the biggest security holes are the easiest to miss!

Timeline

Published on: 04/15/2023 23:15:00 UTC
Last modified on: 04/25/2023 20:04:00 UTC