In 2018, a serious security issue—CVE-2018-17536—was discovered in GitLab, one of the world’s most widely used code collaboration platforms. This vulnerability affected both GitLab Community and Enterprise Editions before versions 11.1.7, 11.2.4, and 11.3.1. It was a stored cross-site scripting (XSS) bug, specifically on the merge request page, and could be triggered using the project import feature. Here, we’ll break down what happened, how the exploit worked (with examples), who was impacted, and how you can protect against similar issues.

What Was the Vulnerability? (A Recap)

Stored XSS occurs when an attacker is able to inject malicious JavaScript into an application, causing that script to execute in other users’ browsers. In this case, an attacker could craft a project with malicious HTML/JavaScript in certain fields and then *import* that project into GitLab. When anyone visited the imported project’s merge request page, the malicious script would fire.

Impact: Attackers could steal cookies, impersonate users, manipulate accounts, or perform other harmful actions within the GitLab instance.

Create a Malicious Project:

The attacker creates a project (outside GitLab or in a controlled/test instance) with specially crafted fields containing malicious scripts. For example, they put XSS payloads into the project description.

Export the Project:

GitLab allows exporting projects to a bundle/backup file.

Import the Project:

The attacker (or a victim tricked into importing that project) imports it into a target GitLab instance using the public UI.

Trigger the Exploit:

Once the malicious project is imported, anyone viewing the merge request (MR) page triggers the XSS code, which executes in their browser in the trusted context of the GitLab server.

Vulnerable Field Example

The exploit happened due to the way certain project metadata fields (like the description) were output on the merge request page without proper sanitization.

Example Malicious Field

{
  "description": "<img src=x onerror=alert('XSS - CVE-2018-17536')>"
}

When this was rendered on the merge request page, the browser would execute the onerror JavaScript handler, popping up an alert.

Step 1: Create a Project with Malicious Data in Description

# In your project’s settings or metadata file:
description = "<svg onload=alert('CVE-2018-17536 XSS')>"

Step 2: Export the Project (from any GitLab instance you control)
Navigate to *Settings > General > Advanced > Export project*.

Step 3: Import to Vulnerable GitLab Instance
Go to *New Project > Import project > GitLab export*, and upload the malicious bundle.

Step 4: Create/View a Merge Request
Once a merge request is created involving the imported project, visit the MR page. The script executes in your browser context.

Here’s a snippet of a minimal project import manifest with an XSS payload

{
  "name": "malicious_project",
  "description": "<script>alert('CVE-2018-17536')</script>"
}

If this project gets imported, and the merge request page renders the description without encoding/sanitization, your browser will execute the JavaScript.

How GitLab Fixed It

According to GitLab’s release notes, the vulnerability was patched by sanitizing user input on project imports and ensuring that fields like title and description are properly encoded when displayed on pages.

Relevant fix PR:
- GitLab MR 22091

References and Further Reading

- GitLab Security Release - 11.3.1 notes
- NVD Details on CVE-2018-17536
- HackerOne Disclosure Report *(if available)*

Conclusion

CVE-2018-17536 is a classic example of how even trusted features like “project import” can be abused if proper input sanitation is missing. If you manage a GitLab instance or develop similar tools, always sanitize inputs, restrict project imports, and keep your software up to date.

Stay safe and keep your code collaboration secure!

Timeline

Published on: 04/15/2023 23:15:00 UTC
Last modified on: 04/25/2023 19:15:00 UTC