CVE-2022-4365
Description
An issue has been discovered in GitLab CE/EE affecting all versions starting from 11.8 before 15.5.7, all versions starting from 15.6 before 15.6.4, all versions starting from 15.7 before 15.7.2. A malicious Maintainer can leak the sentry token by changing the configured URL in the Sentry error tracking settings page.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
A project Maintainer can leak the GitLab Sentry error tracking token by changing the configured URL and clicking the Connect button without saving.
Vulnerability
In GitLab CE/EE versions 11.8 through 15.5.6, 15.6.0 through 15.6.3, and 15.7.0 through 15.7.1, a vulnerability exists in the Sentry error tracking integration settings. A malicious user with the Maintainer role can modify the configured Sentry URL and then click the "Connect" button (which retrieves Sentry projects) without first saving the changes. This action causes GitLab to issue a request to the attacker-controlled URL along with the original, unchanged Sentry API token [1]. The token is thus transmitted to the attacker's server. A previous fix had reset the token field when the URL was changed and saved, but failed to cover the non-saving update pathway [1].
Exploitation
An attacker must have the Maintainer role on the target GitLab project. The attacker navigates to the project's Settings > Integrations > Error Tracking (Sentry) page. They change the Sentry URL field to point to a server they control (e.g., https://attacker.example.com/). Instead of clicking "Save changes," they click the "Connect" button to test the connection. GitLab's frontend sends a request to the new URL with the existing, unchanged Sentry API token as a header or parameter, effectively exfiltrating the token to the attacker's server [1].
Impact
A successful attack leads to the disclosure of the Sentry API token. Depending on the token's scopes (typically project:read, event:read, and event:write [1]), the attacker can gain read/write access to Sentry events, project metadata, and potentially modify or resolve events. This constitutes a high confidentiality and low integrity impact, as the attacker may also be able to delete or alter error tracking data within the connected Sentry instance [1].
Mitigation
The vulnerability is fixed in GitLab versions 15.5.7, 15.6.4, and 15.7.2 [1]. Organizations should upgrade their GitLab instance to a patched version. There is no known workaround short of upgrading. The issue was reported through HackerOne and the patch was incorporated into the referred security release [1].
AI Insight generated on May 25, 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, <15.5.7; >=15.6, <15.6.4; >=15.7, <15.7.2
- Range: >=11.8, <15.5.7
Patches
0No patches discovered yet.
Vulnerability mechanics
Root cause
"The old Sentry token is sent with a connect request even after the URL has been changed, because the token invalidation only triggers on "save" but not on "connect"."
Attack vector
A malicious Maintainer with access to a project's Operations settings can change the configured Sentry URL to an attacker-controlled server. Instead of clicking "save" (which would trigger the existing patch that resets the token field), the attacker clicks the "connect" button. This causes GitLab to issue a request to the new URL containing the original, unchanged Sentry token, leaking it to the attacker's server [ref_id=1]. The attacker can then use the leaked token to access the Sentry instance with the token's assigned scopes (project:read, event:read, event:write) [ref_id=1].
Affected code
The vulnerability is in the Sentry error tracking settings page within GitLab's Operations settings. The issue occurs when a user modifies the configured Sentry URL and clicks the "connect" button (to retrieve Sentry projects) without first clicking "save" — the old token is sent to the new URL [ref_id=1].
What the fix does
The advisory does not include a patch diff, but the referenced issue [ref_id=1] describes the expected correct behavior: changing the URL should require adding a new token even for connect requests. The previous fix (in GitLab 15.2.1) only reset the token when the user clicked "save" after changing the URL, but did not handle the "connect" button flow. The remediation should ensure that any modification to the Sentry URL invalidates the existing token before any network request is made, regardless of whether the user clicks "save" or "connect" first [ref_id=1].
Preconditions
- authAttacker must have Maintainer role on the target GitLab project
- configA Sentry integration must already be configured with a valid token
- networkAttacker must control a server that can receive the leaked token (e.g., Burp Collaborator)
Reproduction
1. Log in to GitLab.com and create a project. 2. Navigate to the project's Operations settings and expand "Error tracking", selecting Sentry. 3. Configure with a server URL (e.g., https://attacker-controlled-server.com) and a random token, click "connect", select a project from the response, and click "save". 4. As the attacker, change the URL to a catch server (e.g., Burp Collaborator). 5. Click "save" to observe the patch behavior (token field is reset and must be re-entered). 6. Instead, click "connect" without clicking "save" first. 7. Check the attacker's server — the request contains the original Sentry 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
3News mentions
1- GitLab Security Release: 16.3.1, 16.2.5, and 16.1.5GitLab Security Releases · Aug 31, 2023