CVE-2022-2243
Description
An access control vulnerability in GitLab EE/CE affecting all versions from 14.8 prior to 14.10.5, 15.0 prior to 15.0.4, and 15.1 prior to 15.1.1, allows authenticated users to enumerate issues in non-linked sentry projects.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
Authenticated users can enumerate sentry issues from other projects due to missing project check in error tracking endpoint.
Vulnerability
An access control vulnerability exists in GitLab EE/CE versions 14.8 prior to 14.10.5, 15.0 prior to 15.0.4, and 15.1 prior to 15.1.1. The error tracking feature, when configured with a connected Sentry server, makes a request to /api/0/issues/ID without verifying that the issue belongs to the configured Sentry project. This allows an authenticated user to enumerate error issues from any Sentry project that the user's auth token has access to [1].
Exploitation
An attacker must be an authenticated GitLab user with at least Maintainer role on a project that has Sentry error tracking enabled. The attacker can then craft a GET request to /-/error_tracking/ID/details with an arbitrary issue ID. The backend forwards the request to Sentry without checking project association, returning issue details if the authenticated Sentry token has access [1].
Impact
Successful exploitation allows an attacker to enumerate and view error issues from any Sentry project that the GitLab instance's Sentry auth token can access. This can lead to information disclosure of sensitive error details from projects not linked to the attacker's GitLab project, potentially exposing application errors, stack traces, or confidential data [1].
Mitigation
GitLab has released fixed versions: 14.10.5, 15.0.4, and 15.1.1. Users should upgrade to these versions or later. No workaround is available [1].
AI Insight generated on May 27, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
3- Range: >=14.8 <14.10.5, >=15.0 <15.0.4, >=15.1 <15.1.1
- Range: >=14.8, <14.10.5
Patches
0No patches discovered yet.
Vulnerability mechanics
Root cause
"Missing authorization check: the backend fetches Sentry issue details by ID without verifying the issue belongs to the configured Sentry project."
Attack vector
An authenticated attacker with at least Reporter access to a GitLab project that has Sentry error tracking enabled can enumerate issues from any Sentry project accessible by the maintainer's auth token. The attacker visits `/-/error_tracking/ID/details` and replaces the ID with an incrementing integer; the backend fetches `https://sentry.example.com/api/0/issues/ID` without checking project ownership, returning full issue details including stack traces [ref_id=1]. The attacker can also resolve or ignore the leaked issues via the UI, causing integrity impact [ref_id=1].
Affected code
The GitLab backend makes a request to `https://sentry.example.com/api/0/issues/ID` when a user visits `/-/error_tracking/ID/details`. This endpoint does not verify that the issue ID belongs to the Sentry project configured for the GitLab project [ref_id=1].
What the fix does
No patch is shown in the bundle. The advisory states that the expected correct behavior is "only issues from the configured sentry project should be shown" [ref_id=1]. The fix would require the GitLab backend to validate that the issue ID returned by the Sentry API belongs to the Sentry project linked to the GitLab project before displaying details or allowing resolve/ignore actions.
Preconditions
- authAttacker must be authenticated and have at least Reporter role on the GitLab project
- configThe GitLab project must have Sentry error tracking enabled with a valid auth token and project configured
- configThe Sentry auth token must have access to multiple Sentry projects
Reproduction
1. Create two Sentry projects (e.g., "private" and "public") and generate a sample event in each, noting the event IDs. 2. On GitLab, create a project, enable Sentry error tracking with the auth token, and select the "public" project. 3. Invite a second user as Reporter. 4. As the second user, navigate to `/-/error_tracking` and click an event to see its details. 5. Replace the ID in the URL with the event ID from the "private" project — the private issue details are displayed. 6. Click "resolve" or "ignore" to modify the private issue's state on Sentry [ref_id=1].
Generated on May 24, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
3- gitlab.com/gitlab-org/cves/-/blob/master/2022/CVE-2022-2243.jsonmitrex_refsource_CONFIRM
- gitlab.com/gitlab-org/gitlab/-/issues/360666mitrex_refsource_MISC
- hackerone.com/reports/1546138mitrex_refsource_MISC
News mentions
0No linked articles in our index yet.