Insertion of Sensitive Information Into Sent Data in GitLab
Description
An issue has been discovered in GitLab CE/EE affecting all versions starting from 15.1 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. A maintainer could modify a webhook URL to leak masked webhook secrets by manipulating other masked portions. This addresses an incomplete fix for CVE-2023-0838.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
A GitLab maintainer can bypass the webhook URL masking fix for CVE-2023-0838 and retrieve masked secrets by manipulating the URL.
Vulnerability
An incomplete fix for CVE-2023-0838 in GitLab CE/EE allows a maintainer to leak masked webhook secrets by manipulating other masked portions of the webhook URL. The vulnerability affects GitLab versions 15.1 to 15.11.10, 16.0 to 16.0.6, and 16.1 to 16.1.1. It resides in the validation logic that resets URL variables when the URL changes; an attacker can bypass the protection by crafting a URL that, when interpolated, differs from the original but shares no variable intersection, thus evading the reset that would clear the stored secrets [1].
Exploitation
An authenticated user with maintainer or higher role on a project, group, or instance can exploit this. The attacker must have configured masked webhook URL variables previously or have access to an existing webhook with masked variables. By editing the webhook URL to include a new variable that is not masked (or by changing the URL text in a way that avoids the intersection check), the interpolated URL changes without triggering the variable reset. The attacker can then read the full masked secret values from the webhook settings page or logs, because the masking logic fails to block viewing after the bypass [1].
Impact
Successful exploitation allows the attacker to retrieve sensitive masked secrets (e.g., authentication tokens, API keys) that were intended to be hidden from all users, including the original configurator. This results in a compromise of confidentiality of the secret data, potentially enabling further attacks against external services integrated via the webhook. No elevation of privileges on GitLab itself is required beyond maintainer level, but the secrets can be used for external lateral movement [1].
Mitigation
GitLab released fixed versions to address this bypass: upgrade to GitLab 15.11.10, 16.0.6, or 16.1.1 (all inclusive) depending on the major version in use. No workaround is available other than applying the patch. The issue was reported via HackerOne and tracked in GitLab issue #410433. This CVE is a bypass of CVE-2023-0838 fix [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: >=15.1 <15.11.10, >=16.0 <16.0.6, >=16.1 <16.1.1
- Range: 15.1
Patches
0No patches discovered yet.
Vulnerability mechanics
Root cause
"Incomplete validation in `reset_url_variables` allows a maintainer to preserve masked webhook secrets when swapping the underlying URL to an attacker-controlled destination."
Attack vector
An attacker who is a maintainer of a project can leak masked webhook secrets by manipulating the webhook URL in two steps. First, the attacker edits the victim's webhook and masks the entire victim URL (e.g., `https://victim-url?token={TOKEN}` becomes `{masked-url}?token={TOKEN}`) and saves — this does not reset `url_variables` because `url_changed?` returns false. Second, the attacker changes the URL to an attacker-controlled URL (e.g., `https://attacker-url?token={TOKEN}`) and masks the attacker URL with the same mask `{masked-url}`, then saves — the `interpolated_url_was == interpolated_url` condition is satisfied, so `url_variables` are preserved. The attacker can then click "Test" and the webhook request is sent to the attacker's server containing the original secret token [ref_id=1].
Affected code
The vulnerability lies in the `reset_url_variables` validation logic in GitLab's webhook URL masking feature. The fix introduced in response to CVE-2023-0838 (issue #391685) added a check that compares `interpolated_url_was` with `interpolated_url`, but this check can be bypassed when an attacker re-masks a different URL with the same mask token, causing the comparison to return true and preserving the original `url_variables` [ref_id=1].
What the fix does
The advisory does not include a published patch diff, but the issue references that the fix addresses an incomplete fix for CVE-2023-0838. The vulnerability bypasses the `reset_url_variables` validation logic that was intended to clear `url_variables` when the URL changes. The fix would need to ensure that when a user modifies the webhook URL and applies masking, the `url_variables` are properly reset or re-validated to prevent leaking previously masked secrets to a different destination URL [ref_id=1].
Preconditions
- authAttacker must have Maintainer role in the target project
- configA victim must have previously configured a webhook with masked secret values
- networkAttacker must have network access to the GitLab instance
Reproduction
1. As victim, configure a webhook URL like `https://example.com?token=secret-token` and mask `secret-token` with replacement `TOKEN`, then save. 2. As attacker (maintainer), edit the webhook and change the URL to `{masked-url}?token={TOKEN}` (masking the entire victim URL with the same mask name), then save. 3. As attacker, change the URL to `https://attacker-url?token={TOKEN}` and mask `https://attacker-url` with the same mask `{masked-url}`, then save. 4. As attacker, click "Test" — the webhook request is sent to the attacker's server containing the original secret token [ref_id=1].
Generated on May 26, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
2- hackerone.com/reports/1976206mitretechnical-descriptionexploit
- gitlab.com/gitlab-org/gitlab/-/issues/410433mitreissue-tracking
News mentions
1- GitLab Security Release: 16.1.1, 16.0.6, and 15.11.10GitLab Security Releases · Jun 29, 2023