Full Report
In GitLab, you can specify a server for Sentry to generate function buttons for error tracking lists. By configuring the error information, you can modify the routing of subsequent requests to GitLab. This is a vulnerability known as Cross-Site Path Traversal (CSPT). By using the ../../ in the error message, we can traverse up the path for other requests. In this case, it's possible to create arbitrary PUT requests on GitLab. The impact of this is immense! Trick users into adding admins, elevating membership, and approving membership. I assume that the contents of the PUT request are controlled via JSON with this. The comments on the bug are interesting. One of them claims that an attacker could do this by tricking GitLab support with this issue. They also find other sinks that they decide to fix. They ended up adding enforce_path_traversal_check to an internal library, making this default to true. Great bug and great report!
Analysis Summary
# Vulnerability: Cross-Site Path Traversal (CSPT) leading to Arbitrary PUT Requests in GitLab Error Tracking
## CVE Details
- CVE ID: Not explicitly provided in the source text, but this is a known vulnerability addressed by GitLab. (Research often assigns this post-disclosure).
- CVSS Score: Not explicitly provided, but the potential for **privilege escalation (admin creation)** suggests a **High** severity score (likely 8.0+).
- CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
## Affected Systems
- Products: GitLab (Self-managed and GitLab.com instances)
- Versions: Specific versions are not listed in the summary, but the advisory following this report details the fix. (The fix involved adding `enforce_path_traversal_check` to an internal library).
- Configurations: Instances where the "Error Tracking" feature is configured with a malicious Sentry server URL that returns error IDs containing path traversal sequences (`../../..`).
## Vulnerability Description
The vulnerability lies in how GitLab constructs URLs for action buttons (like 'Ignore' or 'Resolve') on the Error Tracking list page, which are based on the `errorId` received from the configured Sentry server. By setting up a spoofed Sentry server, an attacker can inject arbitrary path traversal sequences (e.g., `../../../../api/v4/`) into the error ID.
When a victim user (even a standard user or maintainer) clicks one of these action buttons, an unsanitized `axios.put` request is sent from the victim's browser to the crafted endpoint. Because the request is sent with the victim's valid CSRF token, the attacker can force the victim to execute arbitrary **PUT** requests against the GitLab instance's API, potentially reaching endpoints for user management or group approval.
## Exploitation
- Status: PoC available (Detailed reproduction steps provided, including setting up a mock server). The attack requires tricking a victim (Maintainer or Admin) into clicking the poisoned button.
- Complexity: Low (Initial setup requires Maintainer role to configure the malicious Sentry URL; execution relies on social engineering or tricking an existing user into clicking).
- Attack Vector: Network (User interaction required).
## Impact
- Confidentiality: Moderate (Depending on the specific PUT request chosen, an attacker could potentially read sensitive configuration data if access to the relevant endpoint exists).
- Integrity: **High** (Arbitrary PUT requests allow for actions like creating new administrators, elevating membership privileges, or approving pending group access requests).
- Availability: Low to Moderate (Impact is focused on configuration changes rather than denial of service).
## Remediation
### Patches
Patches were deployed to address path traversal issues, notably by enforcing path traversal checks in an internal library (`enforce_path_traversal_check` set to default `true`). Users should update to the versions where this advisory was resolved. (Specific version numbers are not in the summary but are critical for users to check the official CVE/Advisory).
### Workarounds
1. **Disable Error Tracking:** Temporarily disable the Error Tracking feature in projects until patched versions are deployed.
2. **Restrict Sentry Configuration:** Limit which users can successfully configure external Sentry servers if possible, although the successful exploitation relies on the victim triggering the request, not just the configuration.
## Detection
- Indicators of Compromise: Unexpected administrative user creation, sudden membership elevations in groups, or unusual PUT requests targeting administrative or member management APIs originating from internal web requests (traceable in web server logs).
- Detection methods and tools: Monitoring API audit logs for unexpected `PUT` requests to user or group member endpoints, especially those triggered via the front-end application layer associated with error tracking endpoints (if logging is granular enough).
## References
- Vendor Advisory: Referenced HackerOne report #1600343.
- Issue Tracker: GitLab Issue #365427.
- Defanged Link to Report: `h_tt_ps://hackerone.com/reports/1600343`