Insertion of Sensitive Information into Log File in GitLab
Description
An information disclosure issue in Gitlab CE/EE affecting all versions from 13.6 prior to 15.11.10, all versions from 16.0 prior to 16.0.6, all versions from 16.1 prior to 16.1.1, resulted in the Sidekiq log including webhook tokens when the log format was set to default.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
GitLab CE/EE leaks webhook tokens in Sidekiq logs when log format is 'default', affecting versions 13.6 through 16.1.1.
Vulnerability
An information disclosure vulnerability exists in GitLab CE/EE where webhook tokens (X-Gitlab-Token) are logged in cleartext in Sidekiq logs when the log format is set to default. The token appears in the arguments field of the WebHooks::LogExecutionWorker as part of the log_data JSON payload. This affects all versions from 13.6 prior to 15.11.10, all versions from 16.0 prior to 16.0.6, and all versions from 16.1 prior to 16.1.1 [1].
Exploitation
An attacker with access to the Sidekiq logs (e.g., through log aggregation, monitoring systems, or direct file access) can extract webhook tokens. The steps to reproduce include: setting the Sidekiq log format to default, creating a group or project webhook with a secret token, triggering a webhook event (e.g., a push), and then inspecting the Sidekiq logs for the cleartext token [1]. No special authentication beyond log access is required.
Impact
Successful exploitation leads to the disclosure of webhook secret tokens. An attacker can use these tokens to impersonate the legitimate webhook source, potentially triggering unauthorized actions on the receiving service (e.g., CI/CD pipeline execution, deployments, or other automated workflows). This constitutes a confidentiality breach with potential for further compromise depending on the webhook's purpose.
Mitigation
GitLab has released fixed versions: 15.11.10, 16.0.6, and 16.1.1. Users should upgrade to these versions or later. As a workaround, setting the Sidekiq log format to json filters the token from logs, preventing the leak. If the default log format is required, upgrading is the only complete mitigation [1].
AI Insight generated on May 26, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
3- Range: >=13.6 <15.11.10 || >=16.0 <16.0.6 || >=16.1 <16.1.1
- Range: 13.6
Patches
0No patches discovered yet.
Vulnerability mechanics
Root cause
"The `WebHooks::LogExecutionWorker` logs the full `log_data` payload, including the `X-Gitlab-Token` header, in cleartext when the Sidekiq log format is set to `default`."
Attack vector
An attacker with access to the Sidekiq log files (e.g., through log aggregation systems, file read access, or a separate information disclosure) can read the webhook secret token. The token is leaked because the `WebHooks::LogExecutionWorker` logs the full `log_data` payload, which contains the `X-Gitlab-Token` header value, when the Sidekiq log format is set to `default` [ref_id=1]. No network-level attack is required; the attacker must already have read access to the logs.
Affected code
The issue involves the `WebHooks::LogExecutionWorker` in GitLab. When the Sidekiq log format is set to `default`, the `log_data` JSON payload passed as an argument to this worker includes the `X-Gitlab-Token` in cleartext. In contrast, the `json` log format correctly filters the `args` field as `[FILTERED]` [ref_id=1].
What the fix does
The advisory does not include a published patch diff. The expected remediation is to redact the `X-Gitlab-Token` from the `log_data` payload before it is passed to `WebHooks::LogExecutionWorker`, ensuring the token is not written to Sidekiq logs regardless of the log format [ref_id=1]. The issue references a prior fix (issue #381895) that addressed a similar problem, suggesting the same filtering approach should be applied to the `default` log format path.
Preconditions
- configSidekiq log format must be set to 'default' (not 'json')
- authAttacker must have read access to the Sidekiq log files
Reproduction
1. Set the Sidekiq log format to `default`. 2. Create a Group with a Project. 3. Create a Group webhook with a secret token for `push` events. 4. Commit to the project. 5. Check Sidekiq logs for `X-Gitlab-Token` in cleartext [ref_id=1].
Generated on May 26, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
1- gitlab.com/gitlab-org/gitlab/-/issues/409034mitreissue-tracking
News mentions
1- GitLab Security Release: 16.1.1, 16.0.6, and 15.11.10GitLab Security Releases · Jun 29, 2023