Skip to main content
VulnerabilityPublished Updated

CVE-2023-47115: HumanSignal label-studio · Cross-site Scripting

Affects HumanSignal label-studioSource CVE Database V5

0

Not known to be exploited · public detection template (Nuclei) · CVSS 7.1 High : upgrade to 1.9.2 soon.

Data as of 26 Oct 2026, 17:16 UTC

CVSS 3.1 base score
7.1High
How severe the flaw is on the 0–10 CVSS scale.
EPSS
1.4% chance of exploitation in 30 days – higher than 73% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch
Available – fixed in 1.9.2
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:L

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 23 Jan 2024

  2. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  3. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  4. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

Upgrade HumanSignal label-studio to 1.9.2.

Affected software

ProductAffectedFixed in
PyPIlabel-studiopkg:pypi/label-studioOther threatsAffected
  • <1.9.2
Fixed in
  • 1.9.2

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

AI-suggested

  1. Upgrade Label Studio to version 1.9.2 or later immediately to apply the official patch addressing this vulnerability.
  2. Implement strict server-side validation of uploaded file extensions and MIME types, rejecting any files that do not conform to expected safe image formats (e.g., .png, .jpg, .jpeg, .gif).
  3. Replace Django's built-in 'serve' view with a secure, custom controller that explicitly sets Content-Type headers based on verified file content rather than file extension, preventing HTML rendering of uploaded files.
  4. Consider storing uploaded avatar images in a database or object storage with controlled access rather than directly on the filesystem to reduce file-related attack vectors.
  5. Conduct regular security audits of file upload functionalities and ensure client-side validations are complemented by robust server-side checks.
  6. Educate users and administrators about the risks of clicking on suspicious avatar images or links within the platform.
  7. Monitor logs for unusual avatar upload patterns or access to avatar URLs with unexpected file extensions.
  8. If upgrading immediately is not feasible, implement web application firewall (WAF) rules to detect and block requests serving avatar images with '.html' or other suspicious extensions.
  9. Review and harden Django configurations to avoid using development-only features like 'serve' in production environments.

Description

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 uploaded avatar images; saving file content in the database rather than on the filesystem to mitigate against other file related vulnerabilities; and avoiding trusting user controlled inputs.

References

Community reviews

Loading reviews…