CVE-2022-3060
Description
Improper control of a resource identifier in Error Tracking in GitLab CE/EE affecting all versions from 12.7 allows an authenticated attacker to generate content which could cause a victim to make unintended arbitrary requests
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
Authenticated attacker can inject path traversal in GitLab Error Tracking to cause victims to send arbitrary PUT requests, potentially leading to privilege escalation.
Vulnerability
An improper control of a resource identifier vulnerability exists in GitLab CE/EE from version 12.7 through 15.1.4, 15.2.3, and 15.3.1 in the Error Tracking feature. When a project maintainer configures a Sentry server, the error ID returned by the server is used to construct URLs for action buttons (ignore and resolve) without sanitization. An attacker who can spoof the Sentry server can inject a path traversal sequence (e.g., ../../../../api/v4/) into the error ID, causing the generated URLs to point to arbitrary endpoints on the GitLab instance [1].
Exploitation
To exploit this, the attacker must be a project maintainer with permission to enable Error Tracking and configure a malicious Sentry server. The attacker then creates errors with crafted IDs containing path traversal. When a victim user (any user with access to the error list) clicks one of the action buttons, the UI issues a PUT request to the attacker-chosen endpoint. The request includes the victim's valid CSRF token, so it is authenticated as the victim. The victim must click the button, but the action appears legitimate (e.g., ignoring an error) [1].
Impact
A successful attack allows the attacker to force a victim to perform arbitrary PUT requests to the GitLab API. This can be abused to modify project settings, change user roles, or escalate privileges to administrator if the victim has sufficient permissions. The attack requires user interaction but can lead to full compromise of the GitLab instance [1].
Mitigation
GitLab has released fixed versions: 15.3.2, 15.2.4, and 15.1.5 on 2022-08-30. Users should upgrade to these or later versions. No workaround is available. The vulnerability is not listed in CISA's Known Exploited Vulnerabilities catalog as of this writing [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: >=12.7
- Range: >=15.4, <15.4.1
Patches
0No patches discovered yet.
Vulnerability mechanics
Root cause
"Missing input validation and sanitization of error IDs from Sentry allows path traversal in URL construction, enabling arbitrary PUT requests."
Attack vector
An authenticated attacker with maintainer access configures a spoofed Sentry server URL in a project's Error Tracking settings [ref_id=1]. The spoofed server returns error IDs containing path traversal sequences such as `../../../../api/v4/users/4?admin=true#` [ref_id=1]. When a victim user (ideally an administrator) visits the error tracking list page and clicks an action button (ignore/resolve), the frontend constructs a PUT request to the attacker-controlled endpoint path [ref_id=1]. Because the request includes a valid CSRF token and the victim's session cookies, the attacker can force arbitrary authenticated PUT requests to the GitLab API, enabling privilege escalation to administrator, membership changes, or visibility modifications [ref_id=1].
Affected code
The vulnerability exists in the Error Tracking feature's frontend and backend. The frontend file `app/assets/javascripts/error_tracking/components/error_tracking_list.vue` constructs the endpoint URL by concatenating the error ID without sanitization: `getIssueUpdatePath(errorId) { return \`/${this.projectPath}/-/error_tracking/${errorId}.json\`; }`. The backend library `lib/gitlab/error_tracking` also lacks validation of error data input [ref_id=1]. The PUT request is sent via `app/assets/javascripts/error_tracking/services/index.js` using `axios.put(endpoint, { status })` [ref_id=1].
What the fix does
The issue report states that the fix should restrict, sanitize, or validate the error ID value [ref_id=1]. No patch diff is included in the bundle, but the expected correct behavior is that error IDs should not be accepted if they contain path traversal sequences or other arbitrary values [ref_id=1]. The remediation would involve adding validation in the backend (`lib/gitlab/error_tracking`) to reject malformed error IDs, and sanitizing the error ID in the frontend URL construction to prevent path traversal [ref_id=1].
Preconditions
- authAttacker must have maintainer access to a GitLab project to configure a spoofed Sentry server URL
- inputVictim must be logged into GitLab and visit the error tracking list page of the attacker's project
- inputVictim must click one of the action buttons (ignore/resolve) on the error list
- networkAttacker must control a server that returns malicious error IDs in the Sentry API response
Reproduction
1. Create two users: `attacker` (normal user) and `victim` (admin user). 2. As `attacker`, create a new project and configure Error Tracking with a spoofed Sentry server URL (e.g., `https://joaxcar.com`) and any token. 3. Connect the server, select the spoofed project, and save. 4. Invite `victim` to the project as Developer (if not admin). 5. As `victim`, navigate to the project's error tracking page (`/-/error_tracking`). 6. Click any action button (ignore/resolve) on the listed errors. 7. The PUT request executes the attacker's desired API action (e.g., elevating user ID 4 to admin) [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
0No linked articles in our index yet.