Label Studio is an a popular open source data labeling tool. Versions prior to 1.9.2 have a cross-site scripting (XSS) vulnerability that could be exploited when an authenticated user uploads a crafted image file for their avatar that gets rendered as a HTML file on the website. Executing arbitrary JavaScript could result in an attacker performing malicious actions on Label Studio users if they visit the crafted avatar image. For an example, an attacker can craft a JavaScript payload that adds a new Django Super Administrator user if a Django administrator visits the image.

The file `users/functions.py` lines 18-49 show that the only verification check is that the file is an image by extracting the dimensions from the file. Label Studio serves avatar images using Django's built-in `serve` view, which is not secure for production use according to Django's documentation. The issue with the Django `serve` view is that it determines the `Content-Type` of the response by the file extension in the URL path. Therefore, an attacker can upload an image that contains malicious HTML code and name the file with a `.html` extension to be rendered as a HTML page. The only file extension validation is performed on the client-side, which can be easily bypassed.

Version 1.9.2 fixes this issue. Other remediation strategies include validating the file extension on the server side, not in client-side code; removing the use of Django's `serve` view and implement a secure controller for viewing…

Affected: PyPI: label-studio

# Introduction

This write-up describes a vulnerability found in [Label Studio](https://github.com/HumanSignal/label-studio), a popular open source data labeling tool. The vulnerability affects all versions of Label Studio prior to `1.9.2` and was tested on version `1.8.2`.

# Overview

[Label Studio](https://github.com/HumanSignal/label-studio) has a cross-site scripting (XSS) vulnerability that could be exploited when an authenticated user uploads a crafted image file for their avatar that gets rendered as a HTML file on the website.

# Description

The following [code snippet in Label Studio](https://github.com/HumanSignal/label-studio/blob/1.8.2/label_studio/users/functions.py#L18-L49) shows that the only verification check is that the file is an image by extracting the dimensions from the file.

```python

def hash_upload(instance, filename): filename = str(uuid.uuid4())[0:8] + '-' + filename return settings.AVATAR_PATH + '/' + filename <3>

def check_avatar(files): images = list(files.items()) if not images: return None

filename, avatar = list(files.items())[0] # get first file w, h = get_image_dimensions(avatar) <1> if not w or not h: raise forms.ValidationError("Can't read image, try another one")

# validate dimensions max_width = max_height = 1200 if w > max_width or h > max_height: raise forms.ValidationError('Please use an image that is %s x %s pixels or smaller.'…

Affected: PyPI: label-studio

Label Studio is an a popular open source data labeling tool. Versions prior to 1.9.2 have a cross-site scripting (XSS) vulnerability that could be exploited when an authenticated user uploads a crafted image file for their avatar that gets rendered as a HTML file on the website. Executing arbitrary JavaScript could result in an attacker performing malicious actions on Label Studio users if they visit the crafted avatar image. For an example, an attacker can craft a JavaScript payload that adds a new Django Super Administrator user if a Django administrator visits the image.

The file `users/functions.py` lines 18-49 show that the only verification check is that the file is an image by extracting the dimensions from the file. Label Studio serves avatar images using Django's built-in `serve` view, which is not secure for production use according to Django's documentation. The issue with the Django `serve` view is that it determines the `Content-Type` of the response by the file extension in the URL path. Therefore, an attacker can upload an image that contains malicious HTML code and name the file with a `.html` extension to be rendered as a HTML page. The only file extension validation is performed on the client-side, which can be easily bypassed.

Version 1.9.2 fixes this issue. Other remediation strategies include validating the file extension on the server side, not in client-side code; removing the use of Django's `serve` view and implement a secure controller for viewing…