Insertion of Sensitive Information Into Sent Data in GitLab
Description
An issue has been discovered in GitLab CE/EE affecting all versions starting from 11.8 before 16.1.5, all versions starting from 16.2 before 16.2.5, all versions starting from 16.3 before 16.3.1. A malicious Maintainer can, under specific circumstances, leak the sentry token by changing the configured URL in the Sentry error tracking settings page. This was as a result of an incomplete fix for CVE-2022-4365.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
A GitLab security issue allows a Maintainer to leak the Sentry integration token by manipulating the error tracking API URL, bypassing a previous fix.
Vulnerability
An issue in GitLab CE/EE affects versions from 11.8 prior to 16.1.5, from 16.2 prior to 16.2.5, and from 16.3 prior to 16.3.1. A malicious project Maintainer can, under specific circumstances, leak the Sentry error tracking token by changing the configured API URL in the threat monitoring settings [1]. This is a bypass of the incomplete fix for CVE-2022-4365, which only checked whether the new URL starts with the original one [1]. For example, if the original server is https://example.com, an attacker who obtains example.co (or any shorter domain) can change the URL to https://example.co because https://example.com starts with https://example.co, causing the token to be sent to the attacker's server [1].
Exploitation
The attacker must have Maintainer permissions on the affected GitLab project. The sequence involves: first, configuring a legitimate Sentry server (or any server the attacker controls) with the Sentry token; then changing the API URL in the error tracking settings to a domain that is a prefix of the original URL (e.g., https://attacker-controlled.co if the original was https://example.com). The attacker's server receives the token, which can then be used to access the Sentry data [1].
Impact
Successful exploitation results in the disclosure of the Sentry integration token to the attacker. This token could allow the attacker to view or tamper with error tracking data on the real Sentry server, potentially exposing sensitive application errors or altering the configuration [1]. The privilege level required is Maintainer, which is already a trusted role in GitLab.
Mitigation
GitLab has released fixed versions: 16.1.5, 16.2.5, and 16.3.1 [1]. Users should upgrade to the latest available versions for their release line. If upgrading is not immediately possible, restrict Maintainer permissions for projects that integrate with Sentry and monitor for unexpected changes to the error tracking URL. No workarounds are listed in the reference.
AI Insight generated on May 24, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
3- Range: >=11.8, <16.1.5 || >=16.2, <16.2.5 || >=16.3, <16.3.1
Patches
0No patches discovered yet.
Vulnerability mechanics
Root cause
"Incomplete fix for CVE-2022-4365: the URL-change check uses `start_with?` which only verifies the new URL is a prefix of the old URL, allowing an attacker to register a domain that is a prefix of the legitimate Sentry server and bypass the token-reset requirement."
Attack vector
A malicious Maintainer can leak the Sentry token by changing the configured Sentry API URL to an attacker-controlled domain that is a prefix of the original URL (e.g., `https://example.co` when the original was `https://example.com`). The flawed check `setting.api_url&.start_with?(params[:api_host])` [ref_id=1] considers the URL unchanged because the old URL starts with the new one, so the existing token is reused and sent to the attacker's server when the "Connect" button is clicked. The attacker must first be invited as a Maintainer of the project and the original project owner must have configured a Sentry integration with a valid token.
Affected code
The vulnerable logic is in `app/services/error_tracking/list_projects_service.rb` [ref_id=1], where the URL-change check `setting.api_url&.start_with?(params[:api_host])` only verifies prefix matching rather than exact host equality.
What the fix does
The advisory [ref_id=1] identifies that the fix for CVE-2022-4365 in `app/services/error_tracking/list_projects_service.rb` used `start_with?` to compare the old and new API URLs, which is insufficient. The correct fix must ensure that when the URL is changed to a different host (even one that is a prefix of the original), the token is reset and a new one must be provided. No patch diff is included in the bundle, but the issue report states that "changing the URL should require adding a new token even for connect requests" [ref_id=1].
Preconditions
- authThe attacker must be a Maintainer of the GitLab project
- configThe project must have Sentry error tracking configured with a valid token and a legitimate Sentry server URL
- inputThe attacker must control a domain that is a prefix of the legitimate Sentry server's domain (e.g., example.co when the real server is example.com)
Reproduction
1. As UserA (project owner), create a project and configure Sentry error tracking at `https://yourburpcolaburl.computer` with a random token. 2. Invite UserB as a Maintainer. 3. As UserB, go to the project's Operations settings and change the Sentry server URL to `https://yourburpcolaburl.com` (a domain you control that is a prefix of the original). 4. Click "Connect" (not "Save"). 5. Observe the Sentry token in the request received at your controlled server [ref_id=1].
Generated on May 27, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
2- hackerone.com/reports/2104591mitretechnical-descriptionexploit
- gitlab.com/gitlab-org/gitlab/-/issues/422134mitreissue-trackingpermissions-required
News mentions
1- GitLab Security Release: 16.3.1, 16.2.5, and 16.1.5GitLab Security Releases · Aug 31, 2023